应将退出逻辑抽离为可测试函数（如run() error），测试其返回值；必要时用os/exec启子进程捕获ExitCode；注意os.Exit参数仅低8位有效，约定0成功、1通用错误、2命令行解析失败。
Go 测试中 os.Exit 会直接终止进程，没法测
直接调用 main() 或在测试里触发 os.Exit(1)，测试进程自己就退出了，后续断言根本跑不到。这不是你代码写错了，是 Go 测试框架和 os.Exit 的行为冲突——它不抛异常、不返回，就是杀掉当前 goroutine 所在的整个 OS 进程。
真正能测的，是「逻辑分支是否走到 os.Exit」，而不是「它有没有退出」。所以得把退出行为抽出来，让测试能拦截或替换。
- 别在
main()里直接写业务逻辑 +os.Exit，拆成一个可导出、带返回值的函数（比如run() error） - 在
main()里只做最薄一层：调用run()，根据 error 决定调os.Exit(0)还是os.Exit(1) - 测试时只测
run()，它的返回值就能代表本该退出的码（比如返回fmt.Errorf("bad arg")→ 应该os.Exit(1)）
用 os/exec 启子进程测真实退出码
如果非得验证最终二进制的行为（比如 CI 里跑构建后的可执行文件），就得绕过 Go 测试进程本身，用 os/exec 启一个新进程跑你的程序，再捕获它的 ExitCode。
注意：这测的是集成行为，启动慢、依赖编译产物、不能 debug 单步，只适合关键路径兜底。
立即学习“go语言免费学习笔记（深入）”；
- 确保测试前已
go build -o ./myapp .，路径写对，./myapp要有执行权限 - 用
cmd.CombinedOutput()拿输出，用cmd.ProcessState.ExitCode()拿退出码 - 别用
cmd.Run()—— 它只返回 error，而exec.ExitError的ExitCode()方法才暴露真实码
cmd := exec.Command("./myapp", "--invalid-flag")
err := cmd.Run()
if exitErr, ok := err.(*exec.ExitError); ok {
code := exitErr.ExitCode() // 这才是你要的 1、2、255...
}
os.Exit 的参数范围和跨平台差异
os.Exit(n) 的 n 是 int 类型，但实际生效的只有低 8 位（0–255）。超出部分会被截断，比如 os.Exit(300) 在 Linux/macOS 上等价于 os.Exit(44)（300 % 256），Windows 行为一致，但某些旧 shell 可能只识别 0–127。
- 约定俗成：0 表示成功，1 表示通用错误，2 通常留给命令行解析失败（如
flag.Parse()出错） - 避免用负数——Go 允许传，但 shell 层面可能转成大正数（如 -1 → 255），语义混乱
- 如果要用自定义码（如 10 表示配置缺失），确保文档写清楚，且测试覆盖对应分支
测试中临时替换 os.Exit 需谨慎
有人会想用全局变量存一个 exitFunc = os.Exit，测试时替换成空函数或记录器。这看似简单，但容易漏掉并发场景或被其他包提前调用（比如 log.Fatal 内部也调 os.Exit）。
更稳的方式是：只在你自己控制的入口函数里用这个 hook，且确保它不会被意外重入。
- 声明
var exit = os.Exit（小写变量，包内可见即可） -
main()和run()都调用exit(code)，而非硬编码os.Exit - 测试里用
defer func() { exit = os.Exit }()恢复，再exit = func(int) {}替换 - 别在
init()或 goroutine 里改它——时机不可控
os.Exit 是不是真有必要？能不能先返回 error，由上层统一决策？很多所谓“必须退出”的地方，其实是历史习惯。 
