go 程序在发生内存溢出（out of memory）时会直接终止，无法通过 defer + recover 捕获 panic，也无法向用户返回“资源暂时不可用”等友好提示——这是 go 运行时的固有行为，而非编程疏漏。
go 程序在发生内存溢出（out of memory）时会直接终止，无法通过 defer + recover 捕获 panic，也无法向用户返回“资源暂时不可用”等友好提示——这是 go 运行时的固有行为，而非编程疏漏。
在 Go 中，append() 等内置操作触发内存分配失败时，运行时（runtime）会立即引发致命的 OOM panic，并强制终止程序。关键在于：这不是一个可被 recover() 捕获的普通 panic，而是一次不可恢复的运行时崩溃。 原因在于，当系统内存耗尽时，Go 的垃圾回收器（GC）、调度器（scheduler）甚至 recover 本身的执行路径都可能依赖额外内存分配——此时已无安全的“逃生通道”。
例如，以下代码看似尝试兜底，实则无效：
func safeAppend(slice []int, elems ...int) ([]int, error) {
defer func() {
if r := recover(); r != nil {
// ⚠️ 此处永远不会执行：OOM panic 不可 recover
log.Println("Recovered from panic:", r)
}
}()
return append(slice, elems...), nil // 若此处 OOM，进程立即退出
}✅ 正确应对策略不是“捕获 OOM”，而是主动预防 OOM：
- 限制输入规模：对用户输入、文件读取、网络请求体等设置严格上限（如 http.MaxBytesReader）；
- 流式处理大数据：避免一次性加载整个数据集，改用 bufio.Scanner、io.Copy 或分块迭代；
- 监控内存指标：通过 runtime.ReadMemStats 定期采样，结合 GOGC 调优或在 RSS 接近阈值时主动拒绝新请求；
- 使用 sync.Pool 复用临时对象，降低高频小对象分配压力；
- 在容器/服务部署层配置内存 limit（如 Docker --memory），使 OOM 由 OS OOM Killer 触发并留下可观测日志，而非静默崩溃。
需要强调的是：Go 明确不支持 OOM 的应用层错误处理。官方文档与运行时源码均表明，所有 OOM 场景均导致 exit(2) 终止。试图绕过该限制（如信号拦截、cgo 分配钩子）不仅违反 Go 内存模型，还极易引发未定义行为。
总结：与其试图 recover OOM，不如将防御前移——以资源限额为边界、以流式处理为原则、以可观测性为保障，构建真正健壮的内存敏感型服务。
