recover 无法拦截数组越界 panic，因其发生在无 defer 的函数内并立即传播；唯一可行方式是在同一函数内用 defer+recover 包裹越界操作，但显式边界检查才是正确做法。
recover 不能拦截数组越界 panic
Go 的 recover 只能捕获由 panic 主动触发的异常，而数组（或切片）越界访问（如 a[10] 访问长度为 5 的数组）会触发运行时 panic，**类型是 runtime error: index out of range**。这个 panic 理论上可以被 recover 捕获——但前提是它发生在 defer + recover 的有效作用域内，且**没有被编译器提前优化掉或在非 defer 上下文中发生**。
关键问题在于：越界访问通常直接崩溃，根本没机会进 defer。因为 panic 发生在当前函数栈帧中，若该函数没设 defer，panic 会立即向上传播，直到遇到 recover 或程序终止。
必须用 defer + recover 包裹越界操作
想用 recover 拦截，唯一办法是把可能越界的代码放在一个**独立函数里，并在该函数开头用 defer 注册 recover**。不能在顶层或调用方加 defer——panic 发生在被调函数内部，只有它自己能 catch。
- 越界操作必须和
defer recover在同一个函数内（且 defer 必须在 panic 前注册） - 不能对全局数组或外层变量直接索引并指望外层 defer 生效
- 切片越界（
s[i]）和数组越界行为一致，同样适用
<pre class="brush:php;toolbar:false;">func safeIndex(arr []int, i int) (int, bool) {
recovered := false
result := 0
defer func() {
if r := recover(); r != nil {
recovered = true
}
}()
result = arr[i] // 这里越界会 panic，但 defer 已注册，可 recover
return result, recovered == false
}
// 使用：
v, ok := safeIndex([]int{1,2,3}, 10)
if !ok {
fmt.Println("越界了")
}
注意编译器优化和边界检查开关
Go 默认开启边界检查（bounds check），所以越界会 panic。但如果你用 go build -gcflags="-B" 关闭它，越界访问将变成未定义行为（可能读到垃圾值、段错误、静默失败），此时 <code>recover 完全无效——因为根本不会 panic。
三层自动备份：每日时间戳快照、次级硬盘镜像、紧急对话导出。
立即学习“go语言免费学习笔记（深入）”；
- 生产环境不要关
-B；开发/测试阶段保持默认即可 - 交叉编译或 CGO 环境下，某些越界可能绕过检查（极少见），
recover也不起作用 - 使用
unsafe.Slice或指针算术越界，同样不触发 panic，recover无能为力
更推荐的做法：别依赖 recover 拦截越界
靠 recover 处理越界是反模式。它开销大、掩盖逻辑缺陷、且无法覆盖所有场景（比如 goroutine 中 panic 未被 recover 就会终止整个程序）。
- 优先用
len(arr) > i显式判断，零成本又清晰 - 对用户输入或外部数据索引，必须校验；对确定范围的循环，用
for i := range arr - 真要封装容错访问，写个带检查的辅助函数，而不是靠 panic/recover
- 如果业务确实需要“尝试索引”，那 safeIndex 函数里 recover 是可行的，但仅限明确受控的小范围
recover 的合理位置是顶层 goroutine 恢复（比如 HTTP handler）、或封装不可信插件调用。把它当成数组下标检查的替代方案，就像用锤子拧螺丝——能动，但不该这么用。
