Go编译器在静态证明索引一定合法时会消除边界检查，如常量索引、range循环变量、经区间传播可证安全的算术索引；可通过go tool compile -S查看汇编确认是否消除，或用-d=ssa/check_bce查看BCE日志。
为什么 slice 访问有时不报 panic，但编译后却没有边界检查指令？
go 编译器（gc）在多数情况下会插入运行时边界检查，比如 a[i] 会生成类似 if i >= len(a) { panic(...) } 的代码。但如果你用 go tool compile -s 查看汇编，会发现某些访问根本没有对应检查——不是漏了，是被消除了。关键在于：编译器能**静态证明索引一定合法**时，才会删掉检查。
常见可消除场景包括：
- 索引是常量且落在
[0, len(s))内，如s[0]、s[len(s)-1]（前提是len(s)可推导） - 索引来自
range循环变量，如for i := range s { _ = s[i] } - 索引由已知范围的变量经简单算术得出，且编译器能完成区间传播，例如
for i := 0; i
boundsCheckElimination 在什么条件下失效？
消除不是万能的。一旦编译器无法在编译期确认索引安全，检查就会保留。典型失效点：
- 索引含不可内联的函数调用，如
s[f()]，即使f()总返回 0，gc 也不会追踪其行为 - 索引依赖运行时输入，如
flag.Int或os.Args，哪怕你手动写了if i ，编译器仍会在 <code>s[i]处插入检查 - 切片本身长度不可静态确定，比如参数传入的
[]int，除非配合go:noinline等标记让编译器放弃分析，否则很难消除 - 使用了
unsafe.Slice或指针运算绕过类型系统，此时边界检查本就不参与，谈不上“消除”
如何验证某个访问是否被消除了？
最直接的方式是看汇编输出中有没有 CALL runtime.panicslice 或类似比较跳转。操作步骤：
- 写一个最小函数，例如
func f(s []int) int { return s[0] } - 执行
go tool compile -S main.go 2>&1 | grep -A5 -B5 "s\[0\]" - 若输出里没有
cmp、jl（x86）或blt（arm64）跳转到 panic，基本可判定已消除 - 对比加了
//go:nobounds的版本（不推荐生产使用），能反向印证原版是否本就无检查
注意：go build -gcflags="-d=ssa/check_bce" 会打印 BCE（Bounds Check Elimination）决策日志，但输出较晦涩，适合调试编译器行为而非日常验证。
手写循环时怎么帮编译器做消除？
不是所有写法都能被识别。比如这些等价逻辑，效果不同：
for i := 0; i < len(s); i++ { x = s[i] } // ✅ 消除成功
for i := range s { x = s[i] } // ✅ 消除成功
for i := 0; i <= len(s)-1; i++ { x = s[i] } // ❌ 可能失败：len(s)-1 在空 slice 时为负，编译器不敢假设非负
更稳妥的做法：
- 优先用
range，它被专门优化过 - 避免在条件中混用有符号/无符号运算，比如
uint(len(s))会中断分析流 - 如果必须用下标，把长度缓存为局部变量：
n := len(s); for i := 0; i ，有助于 SSA 阶段传播 - 不要为了“看起来高效”而提前写
if i —— 这不会减少检查，反而可能增加分支
边界检查消除是静态分析的结果，不是启发式猜测。它依赖于代码结构的可预测性，而不是程序员的注释或直觉。
