顺序访问对CPU预取器重要，因其仅对连续、固定步长的内存访问等可预测地址模式有效；Go中随机跳转、非对齐访问或字段跨缓存行会致预取失效，引发LLC_MISS和停顿。
为什么顺序访问对CPU预取器重要
CPU预取器（如Intel的硬件流预取器）只对可预测的地址模式有效，典型就是连续、固定步长的内存访问。Go中若热路径里出现随机跳转、非对齐访问、或结构体字段跨缓存行分布，预取器会失效，导致大量LLC_MISS和停顿。这不是Go语言特有问题，但Go的内存布局规则（字段按大小排序+填充）容易无意破坏空间局部性。
struct字段排列要按访问频率从高到低排
Go编译器按字段类型大小重排struct，但不考虑访问顺序。热路径频繁读id和status，却把它们夹在大字段中间，会导致一次cache line加载进来的数据里，真正需要的只占一小部分。
- 手动把高频访问字段（如
id、state、version）放在struct开头 - 避免在热字段之间插入
[64]byte这类大数组——它会把后续字段推到下一个cache line - 用
go tool compile -S检查实际偏移，确认关键字段是否落在同一64字节cache line内
示例：
type HotItem struct {
ID uint64 // 热字段，放最前
State uint8 // 热字段
Version uint32 // 热字段
_ [4]byte // 填充，对齐到16字节边界
Payload [128]byte // 冷字段，放后面
}
遍历slice时避免边界检查干扰预取节奏
Go的slice边界检查本身开销不大，但若编译器无法证明循环索引不越界（比如索引来自外部输入、或有复杂条件），会插入分支预测失败点，打断硬件预取的连续性。更糟的是，某些情况下边界检查会阻止向量化或循环展开。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 对已知长度的热slice，用
for i := 0; i 而非<code>for i := range s——后者在某些版本Go中可能引入额外的隐式检查 - 若确定不会越界，可用
unsafe.Slice绕过检查（仅限极热路径且经过充分测试） - 确保slice底层数组是连续分配的（不要用
append反复扩容后的slice，碎片化会破坏预取效果）
避免指针间接跳转破坏预取流
热路径里写items[i].next.ptr.Data这种多级解引用，会让预取器无法追踪目标地址。CPU只能预取items[i]本身，而next.ptr指向的内存页可能是随机分布的。
立即学习“go语言免费学习笔记（深入）”；
- 把关联数据尽量扁平化：用索引代替指针，例如
nextIdx int代替next *Node - 批量处理时，优先用
[]HotItem而非[]*HotItem——前者数据连续，后者指针连续但目标数据分散 - 如果必须用指针，确保目标对象也按访问顺序连续分配（如用
make([]HotItem, n)预分配后取地址）
预取友好不是靠加prefetcht0指令，而是让代码自然符合硬件预期。最容易被忽略的是：struct字段顺序和slice分配方式，在开发期几乎不影响功能，但在百万QPS下，差的是几十个cycle的L3延迟。
