数组字面量初始化时别用 make，那是切片的活
Go 里数组和切片语义完全不同，但新手常把 make([]int, 5) 当成“创建5个元素的数组”，结果后续操作全按切片逻辑走，一不留神就掉进越界陷阱。数组长度是类型的一部分，比如 [3]int 和 [4]int 是两个不兼容类型；而切片没有固定长度，底层依赖底层数组和 len/cap 控制访问边界。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 要固定长度、栈上分配、值语义——直接写
[5]int{0}或var a [5]int - 需要动态扩容、传参共享底层数据、函数间传递灵活——才用
make([]int, 5) - 初始化后立刻检查长度：打印
len(a)确认是不是你预期的数，尤其从 JSON 解析或外部输入构造时
slice[i:j:k] 三参数切片表达式不是炫技，是防越界的保险栓
默认 s[i:j] 的 cap 是原切片从 i 开始到底层数组末尾的长度，容易让后续 append 意外覆盖不该碰的内存，或者在判断 len(s) 时误以为还能安全追加——其实底层数组早被其他变量持有并修改了。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对外暴露子切片时，强制限制容量：
s = s[i:j:j]，这样append(s, x)超出j-i就会新建底层数组，不会污染原数据 - 解析协议包、处理 buffer 时，从大 buffer 中切出 header、body 等字段，必须用三参数形式，否则一个
append可能改写相邻字段 - 注意：三参数中
k不能大于原切片的cap，否则 panic，运行时校验比手动算下标更可靠
用 unsafe.Slice 前先问自己：是否真绕不开 bounds check？
Go 1.17+ 提供 unsafe.Slice(ptr, len) 可绕过编译器对切片边界的检查，性能敏感场景（如序列化库、零拷贝网络包解析）确实有用，但它把越界风险完全甩给程序员——一旦 len 算错，就是静默内存破坏，不是 panic。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 仅在 hot path 且已用 pprof 确认 bounds check 是瓶颈时才考虑，日常业务代码禁止使用
- 所有
unsafe.Slice调用点必须配注释，写明底层数组真实长度、len来源、为何可信（比如来自可信 header 字段，且已校验 - CI 中开启
go test -gcflags="-d=checkptr"，它能在运行时捕获多数非法指针操作，包括部分unsafe.Slice越界
panic 不是 bug，是没做前置校验的信号
遇到 panic: runtime error: index out of range 别急着加 recover——90% 的情况说明你在某个分支漏掉了 if len(s) > i 或 if i 。recover 是兜底，不是替代条件判断的捷径。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有从用户输入、网络、文件读取的索引值，必须在使用前校验范围，哪怕看起来“不可能越界”
- 循环用
for i := range s而非for i := 0; i ，前者由编译器保证不越界 - 单元测试里故意喂超长/空切片/负索引，看关键路径是否提前返回错误而不是等 panic
越界 panic 表面是运行时问题，根子在控制流里缺少明确的边界契约。写清楚“这个变量在此处必须满足什么条件”，比事后 recover 更省力。
