Go types.SizesFor 为什么会返回 nil

在做 Go 源码分析、交叉编译检查或自定义类型布局工具时，types.SizesFor 返回 nil 往往不是“类型没有大小”，而是传入的编译器与架构组合没有被 go/types 识别。最常见的误用是把 GOOS（例如 linux）当成 arch，或者把运行环境中的自定义编译器字符串直接传进去。

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

SizesFor(compiler, arch) 查的是一个已知的“编译器 + 架构”尺寸组合。组合未知就返回 nil；因此调用方应该先诊断目标参数，再决定报错、跳过布局分析，或使用明确记录过的默认目标。

先把 nil 和“大小算不出来”分开

go/types.Sizes 是一组布局计算函数，包含 Alignof、Offsetsof 和 Sizeof。SizesFor 只负责根据编译器和架构找到一份实现，不负责给任意字符串猜一个布局。

package main

import (
    "fmt"
    "go/types"
)

func main() {
    sizes := types.SizesFor("gc", "amd64")
    if sizes == nil {
        // nil 表示目标组合未知；不要继续调用 Sizeof。
        fmt.Println("unknown compiler/architecture pair")
        return
    }

    // 只有拿到有效的 Sizes 后，布局查询才有目标语义。
    fmt.Println(sizes.Sizeof(types.Typ[types.Int]))
}

这里要特别注意：sizes == nil 与 sizes.Sizeof(t) 是两条完全不同的故障线。前者说明查表没有命中编译器/架构；后者表示某个类型或结构布局太大，不能用非负的 int64 表示。

检查 compiler 和 arch 的来源

第二个容易忽略的点是参数命名。compiler 不是 Go 版本，也不是操作系统；arch 也不是 GOOS。在当前 go/types 文档中，gc 支持的架构包括 386、amd64、arm64、riscv64、wasm 等。实现源码还会单独处理 gccgo 的架构表，命中与否仍以该组合是否已知为准。

package main

import (
    "fmt"
    "go/types"
)

func lookupSizes(compiler, arch string) (types.Sizes, error) {
    sizes := types.SizesFor(compiler, arch)
    if sizes == nil {
        // 把原始参数带回错误，方便定位 GOOS/GOARCH 映射错误。
        return nil, fmt.Errorf("unknown sizes target: compiler=%q arch=%q", compiler, arch)
    }
    return sizes, nil
}

func main() {
    // GOOS=linux 只描述系统；这里真正传给 arch 的是 GOARCH=amd64。
    sizes, err := lookupSizes("gc", "amd64")
    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Println(sizes != nil)
}

如果你的工具读取的是构建配置，建议把 GOOS、GOARCH 和 compiler 分成三个字段保存，再在适配层把真正的 compiler + arch 交给 SizesFor。这样日志能同时保留“运行在哪个系统”和“按哪个架构计算布局”，不会因为字段复用而混淆。

在类型检查入口显式处理 nil

对静态分析器来说，nil 最危险的地方不是它本身，而是错误被延迟到更深层才暴露。可以在创建 types.Config 时先解析目标尺寸，命中后再开始检查文件。

func configForTarget(compiler, arch string) (*types.Config, error) {
    sizes := types.SizesFor(compiler, arch)
    if sizes == nil {
        // 未知目标不应悄悄使用另一个平台的布局。
        return nil, fmt.Errorf("unsupported target compiler=%q arch=%q", compiler, arch)
    }

    return &types.Config{
        Sizes: sizes,
    }, nil
}

这种写法的取舍很明确：目标未知时尽早失败，调用者能看见具体参数；它不会把错误伪装成某个“看起来可用”的默认布局。对于必须继续生成索引的工具，也可以把这个条目标记为“尺寸未知”，跳过依赖偏移量的分析，但不要把它写成 amd64 的结果。

理解 Config.Sizes 的默认路径

types.Config 的文档说明：当 Sizes 为空时，类型检查器使用 SizesFor("gc", "amd64")。这对普通本机分析很方便，但对交叉编译工具是一个重要陷阱：你可能分析的是 arm64 源码，却因为没有设置 Config.Sizes，得到的是默认 amd64 布局。

因此有两种合理策略：

• 工具知道目标：显式设置 Config.Sizes = types.SizesFor("gc", targetArch)，并对 nil 立即返回错误。
• 工具只做与布局无关的语法和类型分析：接受默认值，但在文档和输出中明确写出使用的是 gc/amd64，不要宣称结果代表真实目标。

不要把“Config.Sizes 没设置”理解成“自动跟随当前进程的 GOARCH”。它是一个固定、可预测的默认配置；目标信息仍然要由你的工具输入和传递。

最后区分三类尺寸问题

排查时可以按这个顺序记录：原始 compiler、原始 GOOS、原始 GOARCH、最终传给 SizesFor 的两个参数、是否显式设置了 Config.Sizes。只要这几项完整，nil 通常很快就能定位到参数映射或目标支持范围，而不是继续追查无关的类型定义。

相关问题

types.SizesFor("gc", "linux") 为什么不行？

因为 linux 是 GOOS，不是架构。应将系统和架构分开保存，再把例如 "gc" 与 "amd64" 这样的组合传给 SizesFor。

可以把 nil 自动替换成 amd64 吗？

只有在工具明确接受“近似或默认布局”时才可以，而且必须在结果中标明回退目标。对交叉编译、字段偏移或 ABI 相关分析，静默回退会制造更难发现的错误。

types.StdSizes 能解决所有 nil 吗？

它可以让调用者自己提供一组尺寸假设，但不等价于自动获得某个未知编译器/架构的真实布局。使用自定义 StdSizes 时，应把 WordSize、MaxAlign 和适用目标写入配置说明。

一句话总结：SizesFor 返回 nil 是“目标组合未知”，不是“类型大小为空”。先校正 compiler + arch 的来源，再决定显式失败、受控跳过或记录默认布局，排查会比盯着 Sizeof 的结果更直接。