recover对数组越界无效，因越界是运行时强制中止的致命错误；必须在访问前用len()显式校验索引合法性，range遍历后若操作相邻元素仍需单独边界检查。
Go语言数组越界触发的 panic: runtime error: index out of range 不能靠 recover “兜底修复”，而必须提前预防——因为越界是运行时不可恢复的致命错误，recover 只对主动 panic() 或部分可捕获场景有效，对索引越界这类底层内存安全检查失败，行为不可靠。
为什么 recover 对数组越界基本无效
Go 运行时在检测到切片或数组索引超出长度（如访问 a[5] 但 len(a) == 3）时，会直接终止当前 goroutine 并打印堆栈。这种 panic 属于“运行时强制中止”，recover() 在 defer 中调用可能返回 nil 或行为不稳定，尤其在 Go 1.20+ 版本中明确不保证可捕获。
-
recover()仅对当前 goroutine 的、由panic()显式触发的 panic 可靠生效 - 数组/切片越界、nil 指针解引用、并发写 map 等属于运行时保护机制，不是“异常抛出”，无法被常规
recover拦截 - 即使某次看似捕获成功，也属未定义行为，不应作为容错手段
如何安全访问数组/切片元素（避免触发 panic）
核心原则：所有索引访问前，必须显式校验合法性。不要依赖“用户不会输错”或“循环变量天然安全”。
- 用
len(s)判断边界：if i >= 0 && i - 遍历时限制上界：若需访问
s[j+1]，循环条件应为j ，而非 <code>j - 用
range代替手动索引：它只提供合法索引，但注意range s给出的是0到len(s)-1，仍不能直接用于s[i+1] - 对空切片做前置判断：
if len(s) == 0 { return }，避免后续逻辑误判
命令行参数解析中最常见的越界陷阱
os.Args 是高频越界源头：它的第 0 个元素永远是程序名，用户参数从 os.Args[1] 开始。直接取 os.Args[1] 而不检查长度，必然 panic。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
filename := os.Args[1]—— 当用户运行./app无参数时，len(os.Args) == 1，索引 1 越界 - 正确写法：
if len(os.Args) ，再取 <code>os.Args[1] - 同理，批量处理参数时，循环上限应为
len(os.Args)，但取值索引要从 1 开始，并确保i
归并排序等递归算法中的边界误用
算法实现常把“数组长度”和“末尾索引”混淆，例如将 mergesort(arr, 0, len(arr)) 传入，但函数签名期望的是闭区间 [low, high]，此时 high = len(arr) 已越界（合法最大索引是 len(arr)-1）。
- 确认函数文档：明确参数是“长度”还是“末尾索引”，Go 标准库如
sort.Slice用的是长度，而手写分治常按索引区间设计 - 在递归入口加防护：
if low >= high || high >= len(arr) { return } - 优先使用切片传参（如
arr[low:high+1]），让运行时自动校验边界，比手动算索引更安全
越界 panic 的本质是代码逻辑漏洞，不是运行环境问题。修复重点永远在访问前的条件判断，而不是事后 recover。最易被忽略的一点：哪怕用了 range，只要后续做了 s[i+1] 或 s[i-1] 类操作，就必须单独校验相邻索引是否存在——这一步，90% 的越界 panic 都源于此漏判。
