Go编译器对string的边界检查消除（BCE）规则与[]byte基本一致，因字符串只读而更稳定：只要索引能静态证明在[0, len(s))内即删除检查；s[i]不panic且无检查，是编译期已确定不会越界。
Go 编译器对 string 的边界检查消除（BCE）规则和 []byte 基本一致，但字符串是只读的，所以部分优化更稳定——只要索引能被静态证明在 [0, len(s)) 内，检查就会被删掉；否则保留。
为什么 s[i] 有时没 panic 却也没边界检查？
不是编译器漏了，是它在编译期就“算死了”你不会越界。常见可消除场景：
-
s[0]或s[len(s)-1]：前提是len(s)可静态推导（比如字面量字符串、常量表达式、或函数内固定长度的局部string） -
for i := range s { _ = s[i] }：编译器知道i必然合法，整个循环体内的s[i]都不插检查 -
s[i:j]中，若i和j都是常量或来自已知范围的变量（如range循环中的i），且j 可证，则切片操作本身也不检查 - 反向访问如
s[len(s)-1]、s[len(s)-2]：只要前面某次访问已触发检查并证明len(s) >= N，后续更小索引会复用该信息（例如先s[2]检查，后s[1]、s[0]就省了）
for i := 0; i 为啥不如 <code>for i := range s？
编译器对 range 有特殊处理：它把 len(s) 当作循环不变量，且绑定 i 到 [0, len(s)) 区间；而手写 for 中，i 是普通变量，一旦循环体里出现分支、函数调用（哪怕只是 fmt.Print(i)）、或 s 被传入其他函数，编译器就可能放弃区间推理，保留每次 s[i] 的检查。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先用
for i := range s，安全且零开销 - 必须用索引递增/递减时，提前提取
n := len(s)，再写for i := 0; i —— 这比直接写 <code>len(s)在条件中更易被识别 - 避免在循环中调用任何非内联函数（尤其是接受
string参数的），否则 BCE 很可能失效
如何验证某处 string 访问是否真消除了边界检查？
别靠猜，看编译器输出：
- 加
-gcflags="-d=ssa/check_bce/debug=1"构建：如果某行没打印Found IsInBounds，说明已消除 - 看汇编：
go tool compile -S main.go | grep -A3 -B3 "s\[.*\]"，若没出现cmp+jae（x86）或cmpl+blt（arm64）跳转到runtime.panicslice，基本确认消除 - 注意：
string的底层是只读结构体，&s[0]是合法的，但用unsafe.String构造新字符串后，对其下标访问仍需 BCE —— 它不改变后续访问的安全性判定逻辑
哪些写法会让 BCE 失效？
编译器对字符串的推理能力其实比 slice 更强（因为不可变），但仍有明确雷区：
- 索引来自运行时输入：
idx := flag.Int("pos", 0); _ = s[idx]→ 必插检查 - 用
uint类型做索引：for i := uint(0); i → 类型切换打断整数范围传播 - 切片后再次下标访问：
sub := s[1:]; _ = sub[0]→sub的长度无法静态关联到原始s，除非s是字面量或局部常量 - 跨函数传递：
func f(t string) { _ = t[0] }→ 入参长度未知，必查；若想消除，得在调用方提前截断：f(s[:min(len(s), 1)])
最易被忽略的一点：字符串虽不可变，但它的长度仍可能逃逸（比如作为接口值传入），此时编译器无法假设其恒定 —— 所以高频路径上，宁可用 for range，也别信“我传进去的肯定够长”。
