os.Exit() 跳过 defer 且不触发 panic 恢复，log.Fatal() 等价于 stderr 输出后 os.Exit(1)，但会执行已注册 defer；错误须输出到 stderr，exit code 应遵循 unix 习惯（如参数解析失败用 2，业务错误用 1）。
go程序退出时，os.Exit() 和 log.Fatal() 有什么实质区别
本质区别在于：前者跳过 defer 执行、不触发 panic 恢复机制；后者等价于 fmt.Fprintln(os.Stderr, ...); os.Exit(1)，但会先执行已注册的 defer（除非被 os.Exit() 自身打断）。命令行工具里误用 log.Fatal() 可能掩盖本该由上层处理的错误，比如在子命令函数中直接 fatal，导致主函数的资源清理逻辑失效。
实操建议：
- 只在
main()函数最外层、确定无法继续且无需清理时用log.Fatal() - 子命令或库函数中一律返回
Error，由调用方决定是否退出 - 需要确保清理逻辑（如关闭文件、释放锁）时，绝不能在清理代码前调用
os.Exit()
命令行程序该把错误信息写到 stderr 还是 stdout
错误信息必须写入 stderr，这是 POSIX 规范和 shell 管道行为的基础。如果把错误输出到 stdout，用户执行 mycli args > out.txt 时，错误消息会混进文件，而真正想捕获的正常结果反而丢失。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 用
fmt.Println("error: ...")输出错误 → 默认走stdout - 用
fmt.printf("%vn", err)但没指定输出目标 → 同样走stdout - 第三方库默认日志输出到
stdout，未重定向
正确做法：
- 所有用户可见的错误提示统一用
fmt.Fprintln(os.Stderr, "error:", err) - 使用
log.New(os.Stderr, "", 0)构造专用错误日志器，避免污染stdout - 测试时可临时替换
os.Stderr为bytes.Buffer验证输出流向
exit code 该返回多少才符合 Unix 习惯
非零即错，但具体数值有约定：1 是通用错误；2 通常留给命令行解析失败（如 flag.Parse() 出错）；127 表示命令未找到；128 + N 表示被信号 N 终止。随意返回 42 或 99 会让 shell 脚本难以做有意义的条件判断。
实操建议：
- 解析参数失败（如未知 flag）→
os.Exit(2) - 业务逻辑错误（如文件不存在、权限不足）→
os.Exit(1) - 不要用 exit code 传递详细错误类型，用 stderr 文本说明更可靠
- 如果调用外部命令，应尽量透传其 exit code（尤其
126–128等特殊值）
用 cmd.Execute() 启动 cobra 命令时，错误没打到 stderr 或 exit code 不对
cobra 默认会在 cmd.Execute() 内部调用 os.Exit(1)，但它使用的错误打印方式取决于你是否设置了 cmd.SilenceErrors 和 cmd.SilenceUsage。未设置时，它用 fmt.Fprintf(os.Stderr, ...) 打印，但如果你提前替换了 os.Stderr（比如为了测试），而没同步更新 cobra 的 error output，就会静默失败。
关键点：
- cobra 的错误输出目标是
cmd.ErrOrStderr()，默认返回os.Stderr，但可被cmd.SetErr()修改 - 若手动调用
cmd.Execute()后再自己os.Exit()，会导致重复退出（clobber） - 推荐写法：
if err := rootCmd.Execute(); err != nil { os.Exit(1) }—— 但注意这会丢弃 cobra 内部的 exit code 分类
更稳妥的做法是让 cobra 全权负责退出：设 rootCmd.SilenceErrors = false，然后直接 rootCmd.Execute()，不额外处理返回值。
Exit code 和 stderr 的配合不是“写完就跑”，而是要和 shell 脚本、CI 流程、管道操作形成稳定契约。最容易被忽略的是：在封装了 cobra 或 urfave/cli 的项目里，开发者常以为“只要返回 error 就够了”，却忘了框架内部是否真的把它送到了 stderr、是否用了预期的 exit code —— 这种隐性契约一旦断裂，自动化流程就会在深夜报出一个空错误和神秘的 0 退出码。