Go编译器在静态可证明索引i满足0≤i
Go 编译器在什么条件下会省略 slice 边界检查
Go 运行时默认对每次 slice[i]、slice[i:j] 访问做边界检查，但编译器（gc）会在**静态可证明安全**时主动删掉这些检查。关键不是“是否用了常量索引”，而是“编译器能否在 SSA 阶段证明 i ≤ len(slice) 且 i ≥ 0”。
常见可优化场景包括：
- 循环变量由
for i := 0; i 控制，且体内只用 <code>s[i]—— 编译器能推导出i始终在 [0, len(s)) 范围内 -
s[0]这类固定下标访问，且len(s) > 0可被常量传播推导（如s := make([]int, 5)） - 切片截取后立即使用，如
t := s[2:4]; x = t[1]，编译器会合并边界逻辑
一旦引入任何可能破坏范围信息的操作（比如把 i 传给另一个函数、或用 unsafe.Slice 绕过类型系统），优化就会失效。
如何验证某处边界检查是否被优化掉
最直接的方式是看编译生成的汇编，搜索 boundscheck 调用：
go tool compile -S main.go | grep boundscheck
如果对应行没出现，说明该访问被优化了。注意要关掉内联干扰：go tool compile -l -S main.go（-l 禁用内联）。
更实用的判断依据是运行时 panic 行为：如果某段代码在开启 -gcflags="-d=ssa/check_bce/debug=1" 后不打印 BCE（Bounds Check Elimination）日志，基本说明没优化；反之若看到 bce: found bounds check to remove 就是成功了。
哪些写法会意外阻止边界检查优化
看似等价的写法，可能因控制流或类型信息丢失导致 BCE 失效：
- 用
for i := range s是安全的，但改成for i := 0; i 就不行——因为 <code>len(s)-1在空 slice 时是 -1，编译器无法保证非负 - 把索引提前算好再用：
idx := i * 2; s[idx]，即使i本身受循环保护，乘法也会让范围推理中断 - 从接口或 map 中取 slice 再访问：
m["key"].[0]，编译器无法跟踪 map value 的长度信息 - 调用非内联函数返回索引，例如
s[getIndex()]，哪怕getIndex()总返回 0，BCE 也不会生效
性能差异有多大？要不要手动绕过
一次边界检查开销约 2–3 纳秒，在 tight loop 里累积起来确实可观。但手动用 unsafe.Slice 或 reflect.SliceHeader 绕过检查是高危操作：
- Go 1.22+ 中
unsafe.Slice(ptr, len)仍需确保ptr指向合法底层数组，否则 UB（未定义行为） - 任何 slice header 手动构造都可能被 GC 误判为无效指针，引发内存错误
- 编译器优化足够智能时，手动干预反而阻碍后续优化（比如妨碍向量化）
真正需要极致性能的场景（如解析器 inner loop），优先靠重构让 BCE 生效，而不是跳过检查。边界检查本身不是瓶颈，失控的越界访问才是。
最容易被忽略的是：BCE 依赖整个函数体的上下文，局部改一行可能让整段循环失去优化资格。查不到 boundscheck 指令时，别急着加 //go:nobounds，先看是不是上游数据来源破坏了范围信息。
