defer 在内存溢出时完全失效，因为 oom 触发 runtime fatal error，调度器崩溃，goroutine 无法执行任何 go 代码，包括 defer 和 recover；recover 仅捕获 panic，oom 不 panic 而是直接 abort。
Go 语言中 defer 无法捕获内存溢出（OOM），运行时栈信息也拿不到——因为 OOM 发生时，调度器已崩溃，goroutine 无法执行任何 Go 代码，包括 defer。
为什么 defer 在内存溢出时完全失效
Go 的 defer 依赖于当前 goroutine 的正常执行上下文：它把函数注册到当前 goroutine 的 defer 链表，等函数返回前统一调用。但内存耗尽时，runtime 会直接触发 fatal error（如 runtime: out of memory），强制终止程序，不给任何 Go 层代码执行机会。
-
defer不是 signal handler，也不挂钩系统级异常 - 即使在
main函数最开头加defer fmt.Println("cleanup")，OOM 下也不会打印 -
runtime.Stack()、debug.Stack()等全依赖 runtime 正常运转，OOM 前往往已无法分配新栈帧
能做的有限替代方案：提前预警 + 降级
真正可行的思路不是“捕获 OOM”，而是监控内存增长趋势，在触发 OS kill（如 Linux 的 OOM killer）前主动干预。
- 用
runtime.ReadMemStats()定期采样，关注MemStats.Alloc和MemStats.Sys，而非仅看HeapAlloc - 结合
/sys/fs/cgroup/memory/memory.usage_in_bytes（容器环境）或ps -o rss= -p $PID（宿主机）做双校验 - 当
Alloc在 10 秒内增长 >200MB 且持续超过阈值（如 80% of limit），触发os.Exit(1)或关闭非关键 goroutine - 避免在告警路径里分配新对象——用预分配的 byte buffer 记录日志，或直接 write 到 fd
常见误用：recover + defer 组合幻想兜底
有人试图用 defer + recover() 拦截 OOM，这是无效的。因为 recover() 只对 panic 生效，而 OOM 不 panic，它直接 abort。
- 写
defer func() { recover(); log.Fatal("oom?") }()—— 日志不会输出，进程已终止 - 在 init 函数里注册
runtime.SetFinalizer也无用：finalizer 需要 GC 触发，OOM 下 GC 根本跑不起来 - CGO 调用 malloc 失败时可能返回 NULL，但 Go 原生分配（make/slice/map）失败即 fatal，不返回错误
真正的防线不在 defer，而在内存预算控制：限制 channel 缓冲区大小、用 sync.Pool 复用对象、对大 payload 做 streaming 解析、设置 GOMEMLIMIT（Go 1.19+）让 runtime 主动 GC——这些比幻想 runtime 给你留个 defer 执行窗口实在得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
