先说一个很多开发者容易忽略的事实：内联函数本身并不直接对缓存行命中率产生什么影响。
它影响的，是指令缓存局部性与分支预测，而不是数据缓存那一套。真正决定数据缓存效率的，其实是数据结构怎么排布、访问模式怎么设计、内存怎么分配——这几个才是关键。
内联函数如何间接影响数据缓存行为
编译器把小函数内联后，原本分散在不同代码段的逻辑会被展开到调用点，这确实有可能改变数据访问的时空局部性：
- 减少了函数调用跳转，CPU更容易预取后续指令和相邻数据
- 如果内联后触发了更紧凑的循环展开（比如
for里展开了updatePrice()），可能让数组或结构体字段的访问更连续，空间局部性自然就提升了 - 但也要小心副作用：如果内联导致函数体膨胀、超出了L1指令缓存的容量（通常是32–64 KiB），反而会引发指令缓存抖动，结果拖慢了数据加载的节奏
实操层面，可以试试 go build -gcflags="-l" 禁用内联，然后用 perf record -e instructions,icache_misses 做个对比，看看是不是指令缓存未命中拖累了数据处理吞吐。
struct字段顺序比函数内联更直接影响缓存行命中
Go不会自动帮你重排struct的字段顺序。声明字段时怎么写的，内存布局就是怎样的。假设一个 User 实例，高频读写 ID 和 IsActive，但两者相隔了40字节，那必然跨缓存行：
- 错误写法：
type User struct { Name string; ID int64; CreatedAt time.Time; IsActive bool }→ID偏移约16字节，IsActive偏移约56字节，分属两个缓存行 - 优化写法：
type User struct { ID int64; IsActive bool; Version uint32; Name string; CreatedAt time.Time }→ID、IsActive、Version加起来才12字节，稳稳地待在前一个缓存行里 - 怎么验证：直接用
unsafe.Offsetof(u.ID)和unsafe.Offsetof(u.IsActive)检查是否 ≤ 63 并且同模64
伪共享才是并发场景下缓存行命中的真实杀手
在高频交易系统里，多个goroutine同时更新计数器，如果它们落在同一个缓存行上，MESI协议就会反复让这个缓存行失效——这还不是命中率低的问题，而是命中了立刻被踢出去。
- 典型的坑：
type Stats struct { Total, Failed, LatencyNs int64 }→ 三个int64连续排布，一共24字节，必然在同一缓存行 - 解决办法：填充分隔。比如
type PaddedCounter struct { Value uint64; _ [56]byte }，确保每个实例独占64字节 - 注意别依赖
runtime.CacheLineSize：部分ARM平台会返回0；在x86-64和ARM64上，直接硬编码64更可靠 - 更好的方案：直接用独立变量加上
sync/atomic，避免结构体内聚带来的对齐负担
说到底，真正卡住高频交易延迟的，往往不是函数要不要内联，而是 ID 和 IsActive 是否挤在同一缓存行、Total 和 Failed 有没有被填充隔开、以及底层数组是 [128]float64 还是 []float64。这些细节肉眼难察觉，但 perf 一抓一个准。