Go types.SizesFor 怎样按目标架构计算类型尺寸

做 Go 源码分析、静态检查或代码生成时，如果要回答“这个类型在 amd64 还是 arm64 下占多少字节”，不要把当前机器的运行时结果当成通用答案。正确做法是把 compiler 和 arch 交给 types.SizesFor，拿到对应的 types.Sizes，再调用 Alignof、Offsetsof 和 Sizeof。未知的编译器与架构组合会返回 nil，应先处理这个边界。

官方文档地址：https://pkg.go.dev/go/types#SizesFor

先理解 SizesFor 的返回值与目标环境

types.SizesFor(compiler, arch) 返回一个实现了 types.Sizes 的布局计算器。官方文档说明，结果来自指定编译器对指定架构的尺寸规则；如果组合未知，返回值就是 nil。当前 gc 支持的架构包含 386、amd64、arm64、riscv64、wasm 等。

这里的 arch 不是 GOOS，也不是一台机器的实时探测结果。比如报告目标是 Linux arm64 时，尺寸选择仍然应表达为编译器与架构的布局组合；操作系统、交叉编译环境和报告元数据可以另行保存。图1只表达这些静态边界，不是运行截图。

用 compiler 和 arch 获取可用的 types.Sizes

把选择逻辑收口成一个函数，调用方就不会在不同模块里散落字符串。最重要的是保留 nil 检查：未知组合不应继续调用尺寸方法，也不应静默回退到当前机器。

package main

import (
    "fmt"
    "go/types"
)

func sizesForTarget(compiler, arch string) (types.Sizes, error) {
    sizes := types.SizesFor(compiler, arch)
    if sizes == nil {
        // 未知组合不能生成看似正常的布局数字。
        return nil, fmt.Errorf("unknown layout model: %s/%s", compiler, arch)
    }
    return sizes, nil
}

如果工具需要支持多个目标，建议把 compiler、arch 放进报告结构，而不是只保存一个 sizes 接口。这样同一份源码在 amd64 和 arm64 上重算时，差异能被识别为目标环境变化。

按声明顺序准备类型和字段

types.Sizes 的方法接收 types.Type 或字段变量切片。源码分析器通常已有 *types.Struct；通过 Field(i) 按声明顺序取出字段，再交给 Offsetsof，不要为了方便改成 map。字段顺序一旦丢失，偏移报告也就失去意义。

type FieldLayout struct {
    // 保存名称和类型，避免报告只剩一串不可解释的数字。
    Name   string
    Type   string
    Offset int64
}

func fieldLayouts(st *types.Struct, sizes types.Sizes) []FieldLayout {
    fields := make([]*types.Var, st.NumFields())
    for i := 0; i 

示例把字段名和类型一并保存，便于后续输出 JSON、表格或编辑器提示。Offsetsof 的负值表示布局结果过大，不能当成有效偏移；生产工具应把它转成明确错误。

组合 Alignof、Offsetsof 和 Sizeof 形成报告

只记录字段偏移仍然不完整。Alignof 说明类型整体的对齐要求，Sizeof 给出类型占用的总大小；二者和字段偏移一起，才能解释字段之间的 padding，以及结构体作为数组元素时的步长边界。

type LayoutReport struct {
    // 这两个字段决定报告数字适用的目标环境。
    Compiler string
    Arch     string
    Align    int64
    Size     int64
    Fields   []FieldLayout
}

func makeReport(st *types.Struct, compiler, arch string) (LayoutReport, error) {
    sizes, err := sizesForTarget(compiler, arch)
    if err != nil {
        // 不输出半份报告，调用方可把错误交给命令行或 CI。
        return LayoutReport{}, err
    }
    return LayoutReport{
        Compiler: compiler,
        Arch:     arch,
        Align:    sizes.Alignof(st),
        Size:     sizes.Sizeof(st),
        Fields:   fieldLayouts(st, sizes),
    }, nil
}

StdSizes 的官方说明还给出了常见模型的假设：字符串和接口按两个 word 计算，切片按三个 word 计算，结构体大小取最后字段结束位置并结合对齐规则处理。这里的数字属于布局模型，不应写成所有编译器、架构和版本都完全相同。

跨架构比较时保留哪些边界

不要把 types.Sizes 和 reflect.Type 混为一谈：前者适合尚未构造成运行时对象的源码类型模型，后者面向运行时 Go 类型。也不要把 Offsetsof 当成地址，它只是相对于结构体起点的布局信息。

常见问题

SizesFor 只传 arch 可以吗？

不可以。函数同时接收 compiler 和 arch；应把二者作为同一布局选择保存，未知组合先检查返回的 nil。

换成 arm64 只改报告里的字符串可以吗？

不可以。应重新调用 types.SizesFor("gc", "arm64")，并用新的 Sizes 重新计算字段偏移、对齐和总大小。

这能替代运行时反射吗？

不能简单替代。它解决的是源码类型与目标架构布局的静态报告；运行时对象、指针地址和反射场景仍应使用相应的运行时 API。

采用建议是：先固定报告的 compiler 与 arch，再用同一份 types.Sizes 完成所有字段和类型计算，最后把 nil、负结果、padding 和架构差异写进输出。这样生成的尺寸才有可解释的适用边界。