应将业务逻辑移入独立函数（如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() 模式天然支持的。