struct字段顺序影响unsafe.sizeof结果，因决定padding位置与总量；unsafe.offsetof更可信，因其返回真实偏移且满足对齐约束；64位go中int64、指针、string等类型默认8字节对齐。
struct字段顺序怎么影响unsafe.Sizeof结果
字段声明顺序直接决定编译器插入padding的位置和总量，unsafe.Sizeof返回值不是字段字节之和，而是对齐规则强制补齐后的结果。人脑手算几乎必错，必须实测。
-
struct{a int8; b int64}在64位平台占24字节：a占偏移0，b要求%8==0，中间补7字节，b从偏移8开始；结构体总大小必须是8的倍数，末尾再补6字节到24 -
struct{b int64; a int8}只占16字节：b天然从0开始，a紧接其后（偏移8），末尾补7字节对齐到16——没有前置padding，“开头税”被消除 - 字段越多、类型越杂，错误预估越危险。比如
struct{a int8; b int64; c int32}中，c的实际偏移是16（不是9），因为b结束于偏移15，下一个能被4整除的位置才是16
为什么unsafe.Offsetof比类型大小更可信
unsafe.Offsetof返回的是字段真实起始地址，它不依赖你对“前面字段加起来多长”的假设，而是受对齐约束的铁证。所有字段偏移都必须满足uintptr(unsafe.Pointer(&s.field)) % unsafe.Alignof(s.field) == 0。
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
-
struct{a uint8; b uint32}里，unsafe.Offsetof(s.b)返回4，不是1——因为uint32对齐值为4，编译器在a后插了3字节padding - string字段在struct中对齐值为8（因含uintptr），
struct{a byte; s string}中s的offset一定是8，不是1 - 嵌套struct的offset由其自身最大字段对齐值决定，不是它包含多少字段。一个只含bool的嵌入struct偏移仍是1；含int64的则强制从8的倍数开始
哪些类型在64位Go中默认8字节对齐
对齐值不等于类型长度，也不等于“看起来很大”。它由底层实现决定，且直接影响padding分布。误判对齐值会导致整个字段排序策略失效。
- 明确8字节对齐的：
int64、uint64、float64、complex128、uintptr、所有指针（*T、func()、map[K]V、chan T）、string、interface{} - 注意陷阱：
[8]byte对齐值是1（元素是byte），但[8]int64整体对齐值仍是8；time.Time因含int64字段，也按8对齐 - 别靠名字猜：
bool、int8、byte对齐值都是1，可塞进任意空隙；int32、float32对齐值是4，不是8
cgo场景下对齐不一致会直接崩溃
Go和C默认对齐策略不同，跨语言传递struct时若未显式同步，字段错位、读写越界、静默数据损坏或随机panic都会发生。这不是概率问题，是必然行为。
- C侧需加
#pragma pack(1)或__attribute__((packed))，Go侧在// #include "xxx.h"前也要加对应#pragma pack(1)（顺序不能错） - 必须用
unsafe.Sizeof(C.struct_xxx{})和C.sizeof_struct_xxx对比验证，不等就一定有问题 - 避免直接传未声明对齐的struct，宁可拆成字段逐个传，或用
unsafe.Pointer手动拷贝内存
unsafe.Alignof值分组降序，且要实测验证。最容易被忽略的是：嵌套struct的对齐会“传染”，子结构体末尾padding会成为父结构体的瓶颈；而数组场景下，单个元素多1字节padding，10万条就是100KB。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
