是，go编译器仅在类型相同的字段间重排，混用值类型和int时按声明顺序布局并插入填充字节满足对齐；int与int对齐均为8字节，前置可减少padding。
struct 里混用值类型和 *int 时，内存真按声明顺序排吗？
不按。Go 编译器会重排字段顺序以优化对齐，但仅限于「同一组可交换字段」——也就是类型完全相同的字段之间才可能调换。一旦出现 *int（指针）和 int（值类型）混排，它们属于不同底层类型，编译器不会为省空间把 int 插到两个 *int 中间。实际布局优先服从字段声明顺序，再补填充字节满足各字段的对齐要求。
-
int在 64 位系统上通常需 8 字节对齐；*int是指针，同样需 8 字节对齐 - 如果前面是
byte（1 字节），后面紧跟*int，编译器会在中间塞 7 字节 padding - 用
unsafe.Offsetof验证最可靠，别靠肉眼数字段顺序猜偏移
为什么 struct{a byte; b *int} 比 struct{b *int; a byte} 多占 7 字节？
因为对齐规则从 struct 起始地址开始强制生效。b *int 必须落在 8 字节边界上，所以当它在前时，起始地址 0 就满足；但当它在后、前面是 a byte 时，a 占位置 0，b 的地址必须是 8 的倍数，因此得跳过位置 1–7，从位置 8 开始存放。
- 前者：
a占 0，padding 无（b可直接放 1–8），总大小 = 1 + 8 = 9 → 实际向上对齐到 16（整个 struct 对齐值取最大字段对齐，即 8，但总大小需是其倍数） - 后者：
a占 0，padding 1–7，b占 8–15，总大小 = 16，无需额外填充 - 用
unsafe.Sizeof一试便知：前者返回 16，后者也是 16 —— 但内部 layout 不同，影响的是字段访问开销和 cache line 利用率
嵌套 *T 字段会不会让 struct 的对齐值变成 16 或更大？
不会。struct 的对齐值（alignment）只取决于其所有字段中「最大对齐需求」，而 Go 中绝大多数指针（*T）、整数（int/int64）、浮点（float64）在 64 位平台都是 8 字节对齐。unsafe.Alignof 可验证：
fmt.Println(unsafe.Alignof(struct{ x *int }{})) // 输出 8
fmt.Println(unsafe.Alignof(struct{ x [16]byte }{})) // 输出 16 —— 数组长度影响对齐
- 只有数组、某些 SIMD 类型或手动用
//go:align才可能突破 8 -
*T无论 T 多大，指针本身仍是固定宽度，对齐值不变 - 真正拉高对齐的是大数组字段，比如
[24]byte在部分版本中会让 struct 对齐升到 16
想压缩内存，该把 *int 放前面还是后面？
看相邻字段类型。目标是减少 padding，不是机械地“指针放前”。关键策略是：把对齐要求高的字段（如 *int, int64）集中放在开头，小字段（bool, byte, int16）往后堆。
立即学习“go语言免费学习笔记（深入）”；
- 错误示范：
struct{ a byte; b bool; c *int; d int32 }→a和b后要 pad 到 8 才能放c，浪费 6 字节 - 推荐写法：
struct{ c *int; d int32; a byte; b bool }→c占 0–7，d占 8–11，a和b紧跟在 12–13，总大小 16，无冗余 padding - 工具辅助：
go run golang.org/x/tools/cmd/goimports -local yourdomain.com不管这个；但go run github.com/alexkohler/structlayout@latest能可视化并建议重排
对齐和填充不是黑箱，但依赖平台和编译器版本。别假设 64 位 Linux 上的 layout 在 macOS ARM64 上一样——尤其是涉及 uintptr 或 unsafe.Pointer 时，差一个字节就可能 panic。
