os.exit() 直接终止进程，跳过所有 defer；应将主逻辑封装在 run() 函数中返回退出码，由 main() 统一调用 os.exit()，确保 defer 正常执行。
为什么 os.Exit() 一调用就跳过 defer
因为 os.Exit() 是底层系统调用，它不走 Go 的函数返回路径，而是直接终止进程。所有已注册的 defer 都不会执行——哪怕你刚写了 defer f.Close()，只要中间调了 os.Exit(1)，文件句柄就漏关了。
常见错误现象：程序反复运行后出现 “too many open files”；日志里没看到 cleanup 日志；临时文件没被清理。
- 别在业务逻辑中途直接调
os.Exit()，尤其在有资源要释放、日志要刷盘、状态要保存的地方 - 如果必须快速退出（比如启动参数校验失败），确保前置操作已做完，或改用带 cleanup 的封装模式
-
log.Fatal()本质也是os.Exit(1)，同样跳过defer，别把它当“安全替代”
如何让命令行工具返回有意义的退出码
Linux 下约定：退出码 0 表示成功，非零值表示不同类别的失败。但 Go 默认不设退出码——哪怕 main() 函数 return，进程也总是以 0 结束。
使用场景：CI/CD 脚本靠 $? 判断 Go 工具是否成功；Shell 管道中用 && 控制后续步骤；systemd 根据退出码重试或标记服务失败。
- 必须显式调用
os.Exit(n)，n 建议控制在[0, 125]范围内（避免和信号冲突） - 常见语义：
1通用错误，2参数解析失败，126命令不可执行，127命令未找到 - 不要用负数或 >255 的值——内核会截断，
os.Exit(256)实际等价于os.Exit(0)
执行外部命令时怎么拿到真实退出状态
用 exec.Command().Run() 失败时，错误类型通常是 *exec.ExitError，但它不会直接暴露状态码；你需要类型断言 + 方法提取。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
容易踩的坑：只检查 err != nil 就 panic，却不知道命令其实只是返回了 exit status 1（比如 cp 源文件不存在），而非崩溃。
- 正确做法：
if err != nil { if exitErr, ok := err.(*exec.ExitError); ok { fmt.Println("exit code:", exitErr.ExitCode()) } } - 注意：
exitErr.ExitCode()在 Windows 上可能返回 -1，建议先判断exitErr.Success() == false - 别忽略
cmd.CombinedOutput()——很多工具（如dexdump）把错误信息打到 stdout，只读Stderr会漏诊断线索
怎样兼顾错误码退出和 defer 清理
最稳妥的方式是把主逻辑包进一个 run() 函数，用 return 代替 os.Exit()，让 main() 统一收口。
复杂点在于：你要自己管理错误传播路径，不能依赖 log.Fatal 那种“一出错就死”的懒办法。
- 示例结构：
func main() { os.Exit(run()) }，而run()返回int（0 或错误码） - 所有
defer写在run()里，无论 return 还是 panic，它们都会执行 - 遇到不可恢复错误（如配置加载失败），
run()返回1；成功则返回0
这个模式看起来多了一层函数，但能守住 defer 的边界——这也是 CLI 工具上线前最容易被忽略的一环。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
