Log.Fatal不能用于服务因其调用os.Exit(1)跳过defer、资源清理和HTTP关闭，导致连接硬中断、数据库未释放；仅适用于单次脚本，服务应改用log.Error+显式shutdown+os.Exit或context统一错误处理。
Log.Fatal 为什么不能用在服务里
Log.Fatal 会直接调用 os.Exit(1)，跳过 defer、资源清理、HTTP server 关闭逻辑，导致连接被硬中断、数据库连接未释放、临时文件残留。它适合命令行工具出错即停，但不适合 Web 服务、gRPC 服务或任何需要可控生命周期的长期运行程序。
常见错误现象：Log.Fatal("db connect failed") 后，服务瞬间消失，K8s 认为 Pod 崩溃反复重启；监控看不到 graceful shutdown 日志；Prometheus 指标突降无过渡。
- 使用场景：仅限单次执行脚本（如 migration 工具、配置校验 CLI）
- 替代方案：用
log.Printf+ 显式退出控制，或封装自己的 error handler - 性能影响：无额外开销，但破坏了程序可控性 —— 这比 CPU 或内存成本更致命
用 log.Error + os.Exit 替代时的关键细节
很多人以为换成 log.Error 再手动 os.Exit 就“优雅”了，其实只是把问题延后了一步。真正的关键在于：退出前必须完成清理。
典型错误写法：log.Error("failed to bind port"); os.Exit(1) —— HTTP server 根本没机会调用 srv.Shutdown()。
立即学习“go语言免费学习笔记（深入）”；
- 必须先触发 shutdown 流程（如
srv.Shutdown(context.WithTimeout(...))） -
os.Exit要放在所有 defer、channel close、wg.Wait 之后 - 别依赖
defer在os.Exit前执行 —— 它不会运行 - 示例片段：
if err != nil {<br> log.Printf("startup failed: %v", err)<br> if srv != nil {<br> srv.Shutdown(context.Background())<br> }<br> os.Exit(1)<br>}
更稳妥的做法：统一错误出口 + context 控制
把启动失败、运行时致命错误、信号中断都收口到一个地方处理，避免多处 os.Exit 散落。
核心思路：用 context.Context 传递取消信号，主 goroutine 监听 ctx.Done()，再统一做清理和退出。
- 不要在任意 goroutine 里直接调用
os.Exit，改用cancel()通知主循环 - HTTP server 启动后应运行在单独 goroutine，并用
srv.Serve(lis)的 error 判断是否因 shutdown 结束（不是所有 error 都该退出） - 监听
os.Interrupt和syscall.SIGTERM时，只调cancel()，不立刻 exit - 参数差异：
log.Fatal是 “log then exit”，而 context 方案是 “log → signal → cleanup → exit”，顺序不可颠倒
日志级别和错误分类的实际取舍
不是所有错误都要“退出”。很多 Log.Fatal 的滥用，本质是没区分 transient error 和 fatal error。
比如数据库连接失败：如果是启动阶段连不上，确实该停；但如果运行中偶发超时，应该重试 + 告警，而不是 kill 进程。
-
log.Fatal只用于：配置加载失败、端口已被占用、证书文件不存在等启动期不可恢复错误 - 运行时错误优先走
log.Error+ metrics 上报 + 重试/降级，而非退出 - 兼容性注意：某些老代码用
log.Fatal处理 panic 恢复后的错误，这会导致 recover 失效 —— 应改用log.Panic或显式 panic - 真正容易被忽略的点：日志输出本身可能阻塞（比如写入满载磁盘），所以
log.Fatal的“快速退出”反而掩盖了 I/O 问题
