log.Fatal 的正确用法与使用场景

log.Fatal 应仅用于不可恢复的致命错误，且严格限定在程序初始化阶段或主入口点（如 main 或 init 函数）中；库代码中禁止使用，应改用错误返回机制。

`log.Fatal` 应仅用于不可恢复的致命错误，且严格限定在程序初始化阶段或主入口点（如 `main` 或 `init` 函数）中；库代码中禁止使用，应改用错误返回机制。

在 Go 开发中，log.Fatal 是一个强语义操作：它先输出日志，再调用 os.Exit(1) 强制终止进程，跳过所有 defer、资源清理和 panic 恢复逻辑。这种“一击毙命”的行为虽简洁，却极易破坏程序健壮性——尤其当它出现在被复用的库代码中时，会剥夺调用方的错误处理权，违背 Go “显式错误传递” 的核心哲学。

✅ 推荐使用场景（仅限以下三类）

1. init() 函数中的不可逆失败
   例如：关键配置解析失败、环境变量缺失、全局 logger 初始化异常等。此时程序尚未进入 main，无上下文可恢复，必须立即退出：

   func init() {
       cfg, err := loadConfig("config.yaml")
       if err != nil {
           log.Fatalf("failed to load config: %v", err) // 合理：无法继续启动
       }
       globalConfig = cfg
   }

2. main() 函数中明确的、不可恢复的启动失败
   如命令行参数校验失败、必需服务端口被占用、依赖文件不存在且无法生成：

   func main() {
       flag.Parse()
       if len(flag.Args()) == 0 {
           log.Fatal("usage: app ") // 合理：用户输入错误，无后续逻辑
       }
       file, err := os.Open(flag.Arg(0))
       if err != nil {
           log.Fatalf("cannot open input file: %v", err) // 合理：核心输入缺失，无法执行业务
       }
       defer file.Close()
       // ... 后续处理
   }

3. 短生命周期工具型程序中的确定性失败
   例如 cp、grep 等类 UNIX 工具：当遇到违反语义约束的冲突（如强制覆盖受保护文件失败），且程序设计为非交互式时，log.Fatal 符合 POSIX 退出约定（非零码 + 明确错误信息）。

❌ 绝对禁止的场景

• 任何导出的库函数中（如 net/http.Transport.putIdleConn 中的 log.Fatal 实属反模式）
  ✅ 正确做法：返回 error，由调用方决定是否退出

  func (t *Transport) putIdleConn(pconn *persistConn) error {
      for _, exist := range t.idleConn[key] {
          if exist == pconn {
              return fmt.Errorf("duplicate idle pconn %p in freelist", pconn) // 而非 log.Fatal
          }
      }
      // ...
      return nil
  }

• goroutine 内部或异步流程中
  log.Fatal 会终止整个进程，而非仅当前 goroutine，极易引发资源泄漏和状态不一致。

• 可恢复或需自定义处理的错误
  即使是“严重错误”，只要调用方可能重试、降级或记录后继续运行，就必须返回 error。log.Panic 亦不推荐——它仍需 recover()，而 Go 鼓励显式错误流，而非 panic-driven 控制流。

⚠️ 关键注意事项

• 测试友好性：log.Fatal 会导致测试进程直接退出，难以覆盖分支。单元测试中应通过 log.SetOutput(ioutil.Discard) + 检查返回值验证错误路径。
• 替代方案优先级：
  return error > log.Panic > log.Fatal
  log.Panic 仅在极少数需中断当前 goroutine 但允许上层 recover 的场景下谨慎使用（如某些 CLI 子命令的内部逻辑）。
• 标准库的警示意义：net/http 中的 log.Fatal 是历史遗留问题，并非最佳实践范本。Go 社区已明确建议库作者避免此类用法（参见 Go Wiki: Error Handling）。

总之，log.Fatal 不是“快速退出”的捷径，而是程序生命周期终结的正式声明。恪守“仅限 main/init + 不可恢复”两大铁律，才能写出符合 Go 哲学、易于测试、安全可控的代码。