Go 交叉编译分析为什么不能直接使用宿主机字长

在 Go 交叉编译或静态分析工具里，类型大小不能简单取分析程序所在机器的字长。宿主机是 amd64、目标却是 386 时，如果直接把宿主机的 8 字节字长塞给 go/types.StdSizes，结构体字段偏移、int 大小和对齐结果都会偏向宿主环境。

更稳妥的做法是把目标架构当成分析输入：优先用 types.SizesFor("gc", targetArch) 获取目标尺寸实现；只有确实需要自定义模型时，才构造 StdSizes{WordSize, MaxAlign}。这两个参数描述的是目标类型布局规则，不是当前进程的运行环境。

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

语言规范：https://go.dev/ref/spec#Size_and_alignment_guarantees

宿主机和目标机不是同一个尺寸上下文

交叉编译命令中的 GOOS 与 GOARCH 指向目标环境，Go 官方文档也明确区分了 GOARCH 和 GOHOSTARCH。分析工具本身运行在宿主机上，因此 runtime.GOARCH 反映的是工具进程的架构；它并不知道你准备为哪个目标生成二进制文件。

这个差异在 int、uint、uintptr、指针、切片、接口和结构体上都会留下结果。显式宽度的 int32、uint64 等有固定尺寸，但它们嵌入结构体后，仍然会受到字段顺序和对齐规则影响。

先用 SizesFor 选择目标架构

go/types.Sizes 是一组尺寸计算能力，包含 Alignof、Offsetsof 和 Sizeof。types.SizesFor 按编译器和架构返回实现；对未知的编译器/架构组合，它会返回 nil。

package main

import (
    "fmt"
    "go/types"
)

func sizesForTarget(targetArch string) (types.Sizes, error) {
    // targetArch 是待分析的目标架构，不读取宿主机 runtime.GOARCH。
    sizes := types.SizesFor("gc", targetArch)
    if sizes == nil {
        // 未知组合不能静默回退到宿主机，否则结果会悄悄偏离目标。
        return nil, fmt.Errorf("不支持的目标架构: %s", targetArch)
    }
    return sizes, nil
}

func main() {
    // 这里明确分析 386 目标，示例不代表当前机器架构。
    sizes, err := sizesForTarget("386")
    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Println(sizes.Sizeof(types.Typ[types.Int]))
}

这段写法的关键不是打印某个固定数字，而是让目标架构贯穿尺寸模型。工具如果同时分析多个目标，就为每个目标分别调用一次 SizesFor，不要在进程启动时缓存一份宿主机默认值供所有目标共用。

StdSizes 的 WordSize 到底表示什么

StdSizes 是一个便于构造常用 Sizes 的类型。它的 WordSize 是字节数，最小为 4；MaxAlign 是最大对齐字节数，最小为 1。常见模型下，字符串和接口大小按 2*WordSize 计算，切片按 3*WordSize 计算，其它没有显式宽度的类型通常按 WordSize 处理。

这里的“字长”是目标布局模型里的抽象参数。它不是“这段 Go 代码在什么 CPU 上运行”，更不是把宿主机的 strconv.IntSize 原样复制过去。

为什么直接复用宿主机字长会得到错的偏移

假设分析工具运行在 amd64 宿主机，却要判断一个 386 目标结构体的布局。错误方案通常把宿主机的 8 字节字长当成目标配置：

// 错误示例：把分析进程所在环境当成了待分析目标。
sizes := &types.StdSizes{
    WordSize: int64(strconv.IntSize / 8), // 宿主机可能是 8，目标未必是 8
    MaxAlign: int64(strconv.IntSize / 8), // 对齐也被错误地绑定到宿主机
}
_ = sizes

这段代码的问题不在于 StdSizes 不能用，而在于输入来源错了。目标是 386 时，int 和指针相关布局不应沿用 amd64 的模型；结构体中字段之间可能插入不同数量的 padding，尾部大小也可能改变。

如果确实需要显式模型，应把目标架构映射写成配置，而不是从宿主机探测：

func customSizes(targetArch string) (*types.StdSizes, error) {
    // 只有在项目明确维护自定义模型时，才走这条分支。
    switch targetArch {
    case "386":
        return &types.StdSizes{WordSize: 4, MaxAlign: 4}, nil
    case "amd64", "arm64":
        return &types.StdSizes{WordSize: 8, MaxAlign: 8}, nil
    default:
        return nil, fmt.Errorf("没有配置目标尺寸模型: %s", targetArch)
    }
}

不过，能使用官方 SizesFor("gc", targetArch) 时，优先使用它。自定义模型适合有明确兼容边界的分析器，不适合作为所有架构的通用兜底。

把目标尺寸接到类型分析代码

拿到 Sizes 后，分析器应把它传给真正计算布局的函数。这样同一份源码可以在目标矩阵中重复分析，而不会把分析结果和运行工具的机器绑定。

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

Offsetsof 返回结构体字段的字节偏移，Sizeof 返回类型大小；官方接口约定负值表示尺寸过大。分析器可以把目标架构、字段名、偏移和大小一起输出，形成后续诊断所需的可追踪记录。

一张表记住选择规则

采用前再检查三个边界

1. 目标架构来自构建参数、分析配置或导入的构建上下文，而不是分析程序的运行架构。
2. 目标架构改变后，至少重新计算 int、指针、字符串、接口、切片和结构体的尺寸。
3. 自定义 StdSizes 只覆盖你明确理解的模型；遇到未知目标，宁可停止并提示配置缺失，也不要假装与宿主机相同。

相关问题：

• 为什么显式宽度的 int64 也可能影响结构体结果？ 因为字段的最终偏移和结构体尾部大小仍受对齐规则影响，不能只看字段自身宽度。
• SizesFor 返回 nil 时能否直接使用 StdSizes？ 可以，但前提是你有明确的目标尺寸模型；未知组合不应自动套用宿主机参数。
• 交叉编译一定要在目标机器上运行分析器吗？ 不需要，关键是让分析器接收正确的目标架构并使用对应的尺寸模型。