recover必须在defer函数体内调用且不能提前求值，仅对同goroutine panic有效，http handler需显式recover并检查响应头是否已写。
Go 里 recover 不起作用，90% 是因为没在 defer 函数里调用，或者调用了但不在 panic 发生的同一 goroutine 中。
recover 必须在 defer 函数体内调用
recover 是个“一次性开关”，只在 defer 执行期间有效。如果写成 defer func() { r := recover(); ... }()，没问题；但如果提前把 recover() 结果赋给变量再用，比如 r := recover(); defer func() { if r != nil { ... } }()，那 r 一定是 nil —— 因为此时 panic 还没发生，recover() 被提前执行了。
- 正确写法：必须把
recover()放在 defer 函数体内部，且不能被提前求值 - 常见错误：在 defer 外调用
recover()，或把它塞进闭包参数里（参数在 defer 声明时就求值） - 验证方式：打印
recover()返回值，非nil才说明捕获成功
panic 只能被同 goroutine 的 recover 捕获
Go 的 recover 是 goroutine 局部的。你在 HTTP handler 里 defer 了 recover，只能拦住这个 handler 自己 goroutine 里发生的 panic；如果里面起了 go func() { panic("x") }()，那个 panic 就永远漏掉了。
OpenClaw 基础设施心跳监控与自动恢复：部署/卸载心跳守护进程，配置主机监控（Gateway、磁盘、内存、CPU、进程），设置飞书告警，自动重启故障Gateway。适用关键词：心跳监控、heartbeat daemon、服务器告警、自动重启、健康检查、auto recovery。
- 典型翻车点：异步日志、后台清理、goroutine 内部出错，主 handler 的 recover 完全无效
- 解决方案：每个可能 panic 的 goroutine 都要单独配
defer func() { recover() }() - 注意：不要试图在主 goroutine 里“代管”子 goroutine 的 panic，它们彼此隔离
HTTP handler 中 panic 默认不返回 500
http.Server 根本不干预 panic —— 它只是默默关闭连接、打印堆栈到 stderr，然后继续收下一个请求。前端看到的是空响应或 connection reset，不是 500 Internal Server Error。
- 必须显式包装：每个 handler 或中间件入口加
defer+recover，且defer要在next.ServeHTTP()之前注册 - 安全检查：调用
http.Error()前先用w.Header().WasWritten()判断是否已写响应头，否则会二次 panic - 日志建议：用
debug.Stack()拿完整栈，别用debug.PrintStack()（直接打到 stderr，不可控）
defer 参数求值时机容易引发状态误判
defer 语句的参数在声明那一刻就求值，不是执行那一刻。这在循环或闭包中特别危险：
for i := 0; i
- 资源释放场景更隐蔽：比如
defer file.Close()没问题，但defer log.Println(file.Name())可能因file已被提前 close 而 panic - panic 恢复时若依赖外部变量状态，要注意该变量是否已被后续逻辑覆盖
- 简单原则：所有 defer 的参数，都当作“快照”处理，别指望它反映执行时的真实值
真正难的不是写对 recover，而是判断哪里该 panic、哪里该 return error、哪里该起 goroutine 并配独立 recover —— 这些边界模糊的地方，才是容错设计最容易出问题的环节。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
