Go types.Sizes.Alignof 怎样解释字段对齐要求

types.Sizes.Alignof(T) 返回所选尺寸模型中，T 类型变量的对齐要求。解释结构体字段时，可查询字段类型的 Alignof，但它不等于该字段的偏移，更不是前面必须填充多少字节；实际位置应读取 Offsetsof。

我更愿意把字段布局报告分成“对齐、偏移、大小”三列，因为只写一个“占多少字节”，很容易把这三个问题混在一起。下面以静态分析器生成布局说明为场景，不涉及浏览器特性，也没有性能实测或本机运行记录。

官方文档：https://pkg.go.dev/go/types#Sizes；目标尺寸实现：https://go.dev/src/go/types/sizes.go。

先分清对齐要求、字段偏移和类型大小

对齐要求描述变量地址需要满足的倍数条件。字段偏移是字段相对结构体起点的位置。类型大小则是模型为该类型变量计算的字节数。字段本身需要的对齐，不会告诉你前一个字段结束在哪里，因此不能单独计算填充。

在常见布局中，前面字段结束的位置如果尚未满足后面字段的对齐要求，中间就需要空隙。已经满足时，可以没有这段空隙。因此“对齐为8”不能读成“这里填8字节”。整块结构体还可能有尾部填充，字段大小之和也不一定等于结构体大小。

为目标架构选择 Sizes 实现

types.SizesFor(compiler, arch) 用编译器名和架构名选择模型。若目标组合没有已知模型，会返回 nil，应明确停止该项计算或报告“不支持”，不要悄悄换成本机模型。分析交叉编译项目时，本机架构不能代替目标架构。

我倾向于把模型标识直接写在报告标题旁，例如 gc/amd64；这样读者不会将一次目标计算误认为所有平台的共同保证。如果类型检查阶段也依赖尺寸，比如计算 unsafe 相关常量，应把同一模型传给 types.Config.Sizes，避免检查与报告各用一套假设。

用一个小结构体读取字段布局

以下独立示例直接构造三个字段，依次为 Flag、Count、Tail，再读取其对齐、偏移和大小。它不需要解析源码，也不通过反射或 unsafe 获取当前进程的地址。代码为原创说明示例，本文没有执行它。

package main

import (
 "fmt"
 "go/token"
 "go/types"
)

func main() {
 // 显式指定被分析的目标，不依赖分析器运行机器的架构。
 sizes := types.SizesFor("gc", "amd64")
 if sizes == nil {
  fmt.Println("目标编译器与架构组合没有尺寸模型")
  return
 }
 fields := []*types.Var{
  types.NewField(token.NoPos, nil, "Flag", types.Typ[types.Uint8], false),
  types.NewField(token.NoPos, nil, "Count", types.Typ[types.Int64], false),
  types.NewField(token.NoPos, nil, "Tail", types.Typ[types.Uint8], false),
 }
 st := types.NewStruct(fields, nil)
 offsets := sizes.Offsetsof(fields)
 for i, field := range fields {
  // 负偏移表示无法表示该布局，不能继续当成正常字节位置。
  if offsets[i] 

在选定的 gc/amd64 模型下，普通 uint8 字段按1字节对齐，普通 int64 字段按8字节对齐。按此模型推导，Count 不能紧贴 Flag 的第一个字节后开始；Tail 后面也可能存在结构体整体需要的空隙。这是目标布局规则的推导，不是运行输出截图。

把架构差异带回分析报告

需要支持另一目标时，重新选择模型并重新计算所有列；不要只替换 int 或指针的大小，其他字段的偏移与整体大小可能随之变化。也不要把 SizesFor 返回值强制断言为 *types.StdSizes，调用方需要的是 Sizes 接口，不应依赖具体实现类型。

StdSizes 是带有简化假设的便利实现。自定义 WordSize 与 MaxAlign 适合明确采用这些假设的分析，但不能把任意参数组合当成某个真实编译器的完整 ABI。面向常规 gc 目标时，优先选择对应 SizesFor 模型。

输入也需要限定为可计算布局的具体类型。未实例化类型参数并没有一个固定的实际布局，不应直接把所有 types.Type 都当成普通字段传入尺寸计算。另一个实际边界是溢出：Offsetsof 的负值及 Sizeof 的负值分别表示相关结果太大，报告层不能把负数展示成有效偏移或占用。

常见问题：Alignof 能代表字段间填充吗？不能，要结合偏移和前一字段大小解释。重排字段一定更快吗？不能这样推断，布局大小与缓存访问、实际工作负载不是同一结论。它能决定文件或网络协议布局吗？不应直接用内存布局定义跨平台格式，应明确编码规则。