go编译器默认插入边界检查保障安全，但高频遍历中冗余检查会成性能瓶颈；应通过预分配+range、手动提升检查或unsafe.slice等手段让编译器“信得过”索引安全。
Go 编译器默认对每次 s[i] 或 s[a:b] 操作插入运行时边界检查，防止 panic；但高频遍历中它会成为性能热点——关键不是关掉它，而是让编译器“信得过”你。
如何确认代码里有没有冗余边界检查
用 go build -gcflags="-d=ssa/check_bce/debug=1" 构建，看输出里是否出现 Found IsInBounds。如果某处循环内反复出现，说明编译器没能在编译期证明索引安全，每次迭代都得查一次 len(s) 和 i 的关系。
- 常见触发点：用
for i := 0; i 且 <code>s在循环外被修改（哪怕只是传给另一个函数），编译器就无法假设len(s)不变 -
for i := range s是更优选择——编译器知道i必然在[0, len(s))内，通常能完全消除循环内的检查 - 如果用了
unsafe.Slice(&s[0], len(s))，则彻底跳过检查，但前提是s非 nil、len(s)准确、且底层数组生命周期可控
手动提升边界检查到循环外的写法
当编译器无法静态推导安全范围（比如多个 slice 长度需对齐），可以显式“抬升”检查到循环前，避免重复开销。典型模式是先验证长度，再用下标访问：
func copyBits(dst, src BitVec) {
if len(src.B) == 0 {
return
}
// 手动提前检查，告诉编译器 dst.B 和 src2.B 至少有 len(src.B) 长
_, _ = dst.B[len(src.B)-1], src.B[len(src.B)-1]
for i, x := range src.B {
dst.B[i] = x & src.B[i]
}
}
- 第 4 行的
_, _ = dst.B[len(src.B)-1], src.B[len(src.B)-1]看似无用，实则是向编译器声明“我保证这两个 slice 长度 ≥len(src.B)” - 之后循环里
dst.B[i]和src.B[i]就不再插入检查 - 注意：这个技巧只在确定长度关系绝对成立时才安全；误用会导致静默越界或 crash
预分配 + range 组合是最实用的优化路径
多数场景下，与其纠结手动 hoist 或 unsafe，不如从源头减少检查需求：预分配容量 + 使用 for range 能覆盖 90% 的 slice 遍历性能问题。
- 用
make([]int, 0, n)预分配，避免append过程中扩容导致的底层数组复制和长度突变 -
for i := range s让编译器直接认定i合法，不查；for _, v := range s更进一步，连取地址都省了，v是值拷贝 - 避免在循环中混用
s[i] = ...和s = append(s, ...)—— 后者可能重分配底层数组，使后续s[i]访问指向已释放内存（不 panic，但逻辑错乱）
边界检查本身不是敌人，它是 Go 安全性的基石；真正要警惕的是那些“本可避免却没被编译器识别”的重复检查——它们藏在看似无害的 len(s) 调用、隐式逃逸或未对齐的 slice 操作里。
