slice[i]访问时运行时检查i是否≥len(slice)，越界即panic；常见于循环i
为什么 slice[i] 会 panic：越界检查的实际触发时机
Go 在每次通过索引访问切片元素（如 slice[i]）时，都会在运行时做边界检查：如果 i 或 <code>i >= len(slice)，立即触发 panic: runtime error: index out of range。这不是编译期错误，所以容易漏测——尤其在循环、用户输入或第三方数据解析场景下。
关键点在于：这个检查只针对「单个索引访问」，不覆盖切片截取（s[a:b]）的全部逻辑；后者有自己的一套规则，稍后会讲。
- 常见诱因：
for i := 0; i （用了 <code> 而非 <code>） - 隐式越界：
strings.Split("a,b", ",")[2]—— 返回切片长度为 2，但索引 2 不存在 - 零值切片误用：
var s []int; _ = s[0]直接 panic，因为len(s) == 0
如何安全访问 slice[i]：先检查再访问是唯一可靠方式
Go 没有类似 Python 的 try/except 或内置的 get() 安全访问函数。必须显式判断索引合法性。
- 最简模式：
if i >= 0 && i - 封装成工具函数（适合高频使用）：
func SafeGet[T any](s []T, i int) (T, bool) { var zero T if i < 0 || i >= len(s) { return zero, false } return s[i], true } - 注意：不要用
recover()拦截这种 panic —— 它成本高、掩盖逻辑缺陷，且无法在 goroutine 外有效捕获
s[a:b] 截取越界的三种情况与对应 panic 条件
切片截取比单索引更易出错，因为涉及三个边界：a（起始）、b（结束）、cap(s)（容量上限）。越界 panic 的条件如下：
立即学习“go语言免费学习笔记（深入）”；
a → panic-
b > len(s)→ panic（注意：不是cap(s)！） -
a > b→ panic（例如s[3:1]）
但 b > cap(s) 不 panic，而是被静默截断到 cap(s) —— 这是合法行为，但可能引发后续写入越界。例如：
s := make([]int, 3, 5) t := s[1:4] // ✅ 合法：b=4 ≤ cap(s)=5，t 长度为 3，容量为 4 t[3] = 99 // ? panic：t 长度为 3，索引 3 越界
调试时快速定位越界位置的实操技巧
panic 信息通常只显示 index out of range [x] with length y，但没说哪行代码。提升排查效率的关键是：
- 开启完整调用栈：
GOTRACEBACK=all go run main.go，能打出 goroutine 和完整帧 - 在可疑循环前加防御性日志：
log.Printf("accessing slice[%d], len=%d, cap=%d", i, len(s), cap(s)) - 对用户输入或外部数据，强制校验后才转切片：
if n > len(data) { n = len(data) }，而不是假设“数据一定合规” - 静态检查辅助：
go vet对部分明显越界（如常量索引超长）会报警，但覆盖率有限，不能依赖
越界 panic 看似简单，但根源往往不在那一行代码，而在上游数据构造逻辑里——比如一个本该返回非空切片的函数，却因条件分支遗漏返回了 nil，下游直接索引就崩了。
