go编译器不对string索引做运行时边界检查，因其索引操作在编译期即判定合法性：合法则直接生成内存访问指令，非法则编译报错或插入无条件panic跳转；真正支持bce的是[]byte和[]t，string转[]byte后才进入标准bce流程。
Go 编译器不会对 string 做索引边界检查（BCE）——它根本**不支持**字符串索引的运行时越界 panic，而是直接在编译期报错或生成不可达代码。你看到的“字符串边界检查”现象，几乎全是误判或混淆：实际触发检查的是 []byte、slice 或底层 unsafe.StringHeader 操作，而非 string 本身。
为什么 string[s[i]] 不会触发运行时边界检查
Go 规范明确要求 string 是只读字节序列，其索引操作 s[i] 在编译期就被视为等价于 (*[len(s)]byte)(unsafe.Pointer(&s)))[i] 的 unsafe 转换。编译器只要能静态确认 i 在 [0, len(s)) 内，就直接生成内存访问指令；否则——不是加运行时检查，而是报错 index out of range（编译失败）或生成未定义行为（如用变量索引且无法证明合法时，可能 panic 或 crash）。
-
string的长度是常量（字面量）或已知固定值时，如s := "hello"; _ = s[10]→ 编译报错，不生成任何运行时检查 -
s := someString(); _ = s[5]→ 若someString()返回长度未知的string，该行会触发 panic，但**不是通过 runtime.boundsCheck 调用，而是由编译器插入的无条件 panic 跳转**（汇编里看不到cmp+jae，只有直接call runtime.panicslice） - 真正被 BCE 优化的对象是
[]byte和[]T，不是string；把string转成[]byte后再索引，才进入标准 BCE 流程
哪些写法会让 string 索引变成 slice 边界检查
一旦你把 string 显式转为 []byte，就完全进入 slice 的 BCE 规则体系——所有原本针对 slice 的边界检查触发点都会生效：
-
b := []byte(s); b[i]→ 编译器按[]byte处理，i若来自变量或复杂表达式，大概率保留检查 for i := 0; i → 安全，不触发运行时检查（因为 <code>len(s)是编译期常量或已知上限）for i := 0; i ，其中 <code>n := len(s) + 1→ 危险！即使s非空，i可能等于len(s)，此时s[i]会 panic，且 panic 发生在 runtime 层，不是 BCE 问题，而是逻辑错误-
unsafe.String(unsafe.Slice(unsafe.StringData(s), len(s)), len(s))[i]→ 手动绕过类型系统，但没解决根本问题：越界仍是 panic，且失去编译期提示
验证是否真有运行时边界检查的可靠方法
别信直觉，用编译器输出说话。对疑似有检查的代码，必须跑：
go tool compile -S -l=0 your_file.go | grep -E "(bounds|panicindex|panicslice)"
如果输出里出现 runtime.panicindex 或 runtime.panicslice 的调用，说明有运行时检查；若只有 runtime.panicslice 且无条件跳转（没伴随 cmp），那大概率是 string 索引越界导致的早期 panic，不是 BCE 未消除。
- 用
-gcflags="-d=ssa/check_bce"只对[]T有效，对string索引基本不输出任何IsInBounds—— 因为它压根不走那条路径 -
string的越界 panic 发生在更低层，通常在 SSA 优化前就固化为不可删减的 panic 调用 - 真正要调优的，永远是
[]byte(s)这类转换后的操作，而不是string原生索引
最易被忽略的点：很多人以为给 string 加 //go:nobounds 能起作用，但它只对 slice 和数组有效，对 string 索引完全无效——注释会被忽略，编译器甚至不解析它。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
