应将业务逻辑移入独立函数（如run）并用defer清理资源，main仅负责调用、打印错误和退出；os.Exit会跳过defer导致资源泄漏，log.Fatal同理；需按语义区分退出码并用常量定义。
直接调用 os.Exit 会跳过 defer，别这么干
这是 Go 新手最常踩的坑：在 main 函数里一出错就立刻 os.Exit(1)，结果发现文件没关、连接没断、日志没刷盘。因为 os.Exit 是硬终止，所有已注册的 defer 全部失效——哪怕你前面写了 defer f.Close()，它根本不会执行。
-
log.Fatal、log.Fatalf同样危险，它们内部就是调用os.Exit(1) - 资源泄漏不是“可能”，而是“必然”：数据库连接池耗尽、临时文件堆积、goroutine 永久阻塞都由此而来
- 测试时不容易暴露，但上线后遇到高并发或异常中断，问题会集中爆发
把业务逻辑塞进 run() 函数，让 defer 正常跑完
Go 社区公认的解法是把所有实际工作挪到一个独立函数里，比如叫 run()，它返回 error；main() 只负责调用它、打印错误、最后退出。这样，run() 内部的所有 defer 都会在函数返回前按 LIFO 顺序执行，清理动作完全可控。
package main
import (
"fmt"
"os"
)
func run() error {
f, err := os.Open("config.json")
if err != nil {
return fmt.Errorf("打开配置文件失败: %w", err)
}
defer f.Close() // ✅ 这里一定会执行
// 其他业务逻辑...
return nil
}
func main() {
if err := run(); err != nil {
fmt.Fprintln(os.Stderr, "错误:", err)
os.Exit(1) // ✅ 此时 run 已返回，所有 defer 完成
}
}
错误码不止是 0 和 1：按场景区分退出状态
os.Exit 接收任意整数，Linux 约定非零即失败，但不同错误类型值得用不同码区分，方便上层脚本或监控系统判断。比如：2 表示参数解析失败，3 表示网络不可达，4 表示权限不足。
- 不要全用
os.Exit(1)—— 它掩盖了错误语义 - 定义常量比裸写数字更安全：
const ErrInvalidArgs = 2 - 注意 shell 中
$?只保留低 8 位，所以避免用大于 255 的码 - 若需兼容 POSIX，优先复用标准码（如
sysexits包里的定义）
信号退出也要走 run() 流程：用 os/signal 捕获 SIGTERM
命令行程序不只是靠出错退出，更多时候是被 kill 或 Ctrl+C 终止。这些是信号，不是 panic，必须手动监听并触发优雅关闭。关键点是：信号处理函数里不能直接 os.Exit，而应让 run() 主循环感知退出信号并自然返回。
- 用
signal.Notify监听os.Interrupt（Ctrl+C）和syscall.SIGTERM（kill默认） - 把信号接收逻辑和业务主循环耦合进同一个上下文，例如通过
context.WithCancel传递取消信号 - 确保所有长期运行的 goroutine 都响应
ctx.Done()，并在退出前完成自己的defer
真正难的不是写几行 signal 代码，而是把整个程序结构设计成可中断、可清理的状态机——这恰恰是 run() 模式天然支持的。
