recover无法彻底避免崩溃，因其仅捕获当前goroutine的panic，对os.exit、sigkill、oom、goroutine泄漏等无效，且无法拦截下游依赖内部panic；需从输入校验、错误传播、资源隔离三处入手。
不能靠 recover 拦住所有崩溃，必须从输入校验、错误传播、资源隔离三处下手。
为什么 recover 无法“彻底”避免崩溃
recover 只能捕获当前 goroutine 的 panic，对以下情况完全无效：os.Exit 调用、SIGKILL 信号、内存耗尽（OOM）、goroutine 泄漏导致的资源枯竭。更关键的是：如果脏数据触发的是 nil pointer dereference 或 slice bounds out of range，recover 能兜住；但若脏数据导致下游依赖（如数据库驱动、第三方 SDK）内部 panic 且未暴露 error 接口，recover 就无能为力。
常见错误现象：panic: runtime error: invalid memory address or nil pointer dereference 被 recover 捕获后，服务看似没挂，但后续请求持续失败——因为状态已损坏（比如全局连接池被污染）。
- recover 必须放在最外层入口（如 HTTP handler、goroutine 启动函数），不能只包一层业务函数
- recover 后不要继续复用可能已损坏的对象（如未重置的 struct 字段、已 close 的 channel）
- 日志里打印
fmt.Sprintf("%+v", err)，否则堆栈信息丢失，无法定位脏数据来源
输入校验必须前置且带上下文
脏数据问题本质是“不该进来的进了”，靠事后 recover 是被动防御。真正有效的做法是在数据进入核心逻辑前就拦截。
使用场景：HTTP 请求体解析、文件逐行读取、消息队列消费。
- 对 JSON 输入，不用
json.Unmarshal直接解到结构体，改用json.NewDecoder+DisallowUnknownFields()防止字段错位引发 panic - 读取 CSV 或日志行时，先检查
len(line) > 0和strings.TrimSpace(line) != ""，再做strings.Split，避免空切片索引越界 - 关键字段（如 ID、时间戳）校验失败时，返回明确 error（如
errors.New("invalid timestamp format")），而不是log.Fatal或直接 panic
goroutine 与 channel 的资源隔离必须显式控制
一个 goroutine 因脏数据 panic，不该拖垮整个清洗流水线。核心是让每个阶段独立生命周期，不共享状态。
参数差异：make(chan T, 0)（无缓冲）会让上游卡死，make(chan T, 100)（有缓冲）能吸收瞬时脏数据冲击，但缓冲太大（如 10000）会掩盖问题。
- 每个清洗 stage 启动独立 goroutine，并接收一个
done chan struct{}参数，监听退出信号 - channel 发送前加判断：
select { case out - 绝不把原始脏数据存入全局变量或 long-lived struct；处理完立即丢弃
[]byte引用，防止内存钉住
模块级崩溃防护的最后防线
即使前面都做了，仍可能因不可控依赖崩溃。这时需进程级兜底，而非单个模块内挣扎。
性能影响：额外启动 watchdog goroutine 几乎无开销，但 syscall.SIGKILL 无法捕获，所以不能依赖它保命。
- 主 goroutine 启动时注册
signal.Notify(sigChan, os.Interrupt, syscall.SIGTERM)，收到信号后触发清理，再os.Exit(0) - 关键模块（如 DB 连接池、文件句柄）初始化失败时，用
log.Error+srv.Shutdown+os.Exit(1)，而不是log.Fatal - 线上环境强制启用
GODEBUG=madvdontneed=1，缓解大[]byte分配后内存不归还 OS 的问题
复杂点在于：脏数据可能不会立刻 crash，而是缓慢腐蚀状态（比如时间字段解析错导致后续计算漂移）。这种问题 recover 看不见，只能靠输入校验 + 单元测试覆盖边界值 + 生产环境采样日志比对。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
