Go语言中recover可捕获同goroutine内defer注册的数组/切片越界panic，但必须在越界操作前注册defer；跨goroutine无效，且应优先用len预检而非recover。
Go 语言没有“数组越界异常”这种运行时异常，recover 捕获不到数组或切片越界访问 —— 因为它直接 panic，且 panic 不是“可被 recover 的常规错误”，而是程序崩溃信号；但你确实可以用 recover 拦住它，前提是 panic 发生在 defer + recover 的有效作用域内。
为什么 recover 看似“无效”：panic 触发时机与 goroutine 边界
Go 中对 slice（如 arr[100]）越界访问会立即触发 runtime error: index out of range panic，这个 panic 默认终止当前 goroutine。如果你没在同一个 goroutine 中、在 panic 发生前设置好 defer func() { recover() }()，recover 就完全不起作用。
- 常见错误：在主函数外另起 goroutine 做越界操作，却在 main 中 defer recover → 无效，goroutine 独立 panic
- 必须确保：越界操作和
recover在同一个 goroutine，且defer写在越界调用之前 -
recover只能捕获当前 goroutine 的 panic，不能跨 goroutine 传递或拦截
正确写法：用 defer + recover 包裹越界风险代码块
不是“处理越界”，而是“兜底捕获 panic”，避免进程退出。你需要主动把可能越界的逻辑放进受控函数中，并在其入口加 recover。
func safeGet(s []int, i int) (int, bool) {
recovered := false
result := 0
defer func() {
if r := recover(); r != nil {
recovered = true
}
}()
result = s[i] // 这里若越界，panic 被 defer 捕获
return result, !recovered
}
// 使用：
s := []int{1, 2, 3}
v, ok := safeGet(s, 10)
if !ok {
fmt.Println("越界了")
} else {
fmt.Println("值：", v)
}
- 注意：
recover()必须在defer函数内部调用，且该defer必须在越界语句之前注册 - 返回
bool是为了区分“取到值”和“因 panic 被 recover 导致无返回值” - 不推荐在生产代码中靠 recover 处理越界 —— 应该用
len(s) > i预检
数组 vs 切片：越界行为一致，但声明方式影响 panic 时机
Go 中固定长度数组（如 [3]int）和切片（[]int）在越界访问时都触发相同 panic，但编译期检查能力不同：
文件删除恢复功能 v0.8.0：删除前自动备份文件（存至 `delete_backup/YYYYMMDDHHMM/` 目录），支持从备份中恢复、通过清单（manifest）搜索。具备 SHA256 完整性校验、路径遍历防护及工作区根目录（workspace-root）访问限制。支持自动清理 7 天 / 30 天前的备份。 **v0.8.0：新增 `workspace_cleaner` —— 支持定时清理临时文件，并在删除前自动执行备份。** **v0.7.0：`allowed_roots` 默认值
立即学习“go语言免费学习笔记（深入）”；
- 数组索引若为常量（如
arr[5]，而arr是[3]int），部分情况会被编译器提前报错（非全部，取决于上下文） - 切片索引永远是运行时检查，无论是否常量
- 所以实际开发中几乎只用切片，而它的越界 panic 完全无法被编译器拦截，只能靠运行时防护
更合理的做法：不用 recover，改用边界预检 + 错误返回
依赖 recover 处理越界属于反模式。Go 的哲学是“显式错误优于隐式 panic”。真实项目中应该：
- 用
if i = len(s)显式判断，返回0, errors.New("index out of bounds") - 封装成带检查的工具函数，比如
SafeAt(s []T, i int) (T, error) - 只有在极少数场景（如插件系统、REPL 解释器、Fuzz 测试沙箱）才用
recover做隔离防护 -
recover成本略高，且掩盖了本应修复的逻辑缺陷
真正容易被忽略的是：recover 只在 panic 正在发生、尚未退出当前 goroutine 时有效 —— 一旦 panic 开始传播并跨越函数调用栈，再 defer 也来不及。所以它不是“异常处理机制”，而是“panic 中断机制”，用错地方就等于没用。
