数组比切片更快当且仅当长度固定、生命周期短且不逃逸时：栈上分配、无指针解引用、无扩容分支、可作map键、传参开销小，但需避免取地址、大数组及JSON解码等逃逸场景。
热路径里用数组替代切片能省掉指针解引用、避免逃逸、消除扩容分支，但只在长度固定且生命周期短时才真正有效。
什么时候数组比切片更快
数组在栈上分配（只要不逃逸），没有指针间接访问，也没有 append 的扩容判断逻辑。比如网络包解析中固定 16 字节的 header、哈希计算用的 [64]byte 缓冲、SIMD 向量操作的 [8]float64 —— 这些场景下，var buf [64]byte 比 make([]byte, 64) 少一次堆分配 + GC 压力，也绕开了切片结构体的 24 字节胖指针开销。
- 编译器能内联数组访问，汇编里直接是
movq 8(SP), AX这类栈偏移指令；切片则至少多一层movq (AX), BX解指针 - 函数传参时，小数组（如
[16]int）仍走寄存器或栈拷贝，而切片传参永远复制 24 字节结构体 + 底层数组仍共享 - 数组可作为 map 键（
map[[16]byte]int），切片不行 —— 热路径中做快速查表时这很关键
怎么避免数组意外逃逸到堆
Go 编译器对局部数组是否逃逸有严格判定：若取地址并返回、或传给可能逃逸的函数（如 fmt.Printf）、或大小超过约 2KB（具体阈值随 Go 版本微调），就会强制分配到堆。常见踩坑点：
-
return &buf—— 直接逃逸，改用传入指针参数或返回值结构体 -
fmt.Sprintf("%x", buf[:])——buf[:]转成切片后，底层数组可能被逃逸分析标记为需堆分配 -
var huge [4096]byte在函数内声明 —— 很可能触发栈分裂，反而更慢；此时应考虑sync.Pool复用切片，而非硬上大数组
JSON 解码到数组会失败但切片不会
如果字段数量不匹配，json.Unmarshal 解码到 [3]int 会直接报错 json: cannot unmarshal array into Go value of type [3]int；而解码到 []int 会自动适配长度。热路径中若 JSON 结构完全可控（例如 RPC 协议固定字段数），可定义 type Header [12]byte 并实现 UnmarshalJSON 方法手动解析，跳过反射和动态切片构造 —— 这比标准库解码快 3–5 倍。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 别依赖
json:"-"忽略字段来“凑”数组长度；字段少一个就 panic - 用
unsafe.Slice(unsafe.StringData(s), len(s))（Go 1.20+）可零拷贝将字符串转为[]byte视图，再按偏移读数组字段，适合协议解析
数组不能直接 append，但可以封装成带索引的结构体
热路径中常需要「固定容量 + 当前长度」语义，比如收集最多 8 个错误码。这时不要写 append(slice, x)，而是定义：
type Fixed8[T any] struct {
data [8]T
len int
}
func (f *Fixed8[T]) Push(x T) bool {
if f.len >= 8 { return false }
f.data[f.len] = x
f.len++
return true
}
这样既保留数组的栈分配优势，又避免切片扩容的分支预测失败开销；len 字段还能做边界检查内联，比每次调用 len(slice) 更轻量。注意：别把 Fixed8 作为返回值直接传出去 —— 若含大量数据，值拷贝成本会上升。
真正容易被忽略的是：数组性能收益高度依赖编译器逃逸分析结果，而不是“用了数组”本身；跑 go build -gcflags="-m -l" 看一眼变量是否逃逸，比盲目替换更管用。
