go中临时文件未被清理主因是defer在panic或kill-9时失效，可靠方案为signal.notify捕获sigterm/sigint后显式调用os.removeall，配合filepath.abs校验路径安全，并避免多goroutine竞态删同一目录。
临时文件没被删，os.Remove 报 no such file or directory
这不是你漏写了清理逻辑，而是常见于“文件已提前被删”或“路径拼错”。os.Remove 默认失败就 panic（如果没显式处理错误），但更隐蔽的问题是：多个 goroutine 同时操作同一 tempDir 时，可能 A 刚删完，B 又去删——直接报错。解决思路不是加锁，而是用 os.RemoveAll 替代单个 os.Remove，它对不存在的路径返回 nil 错误；或者统一用 os.Stat 先判断存在性再删。
用 os.MkdirTemp 创建后，怎么确保退出时一定清理
靠 defer 不可靠：如果程序 panic 或被 kill -9，defer 不执行。真正可靠的方案是结合 os.Exit 钩子 + 信号监听。但多数场景下，用 defer + 显式错误检查已足够——只要不依赖 100% 保证（比如写日志类临时文件）。实操建议：
- 在
main函数开头调用os.MkdirTemp，把路径存到全局变量或传入结构体 - 在函数末尾用
defer os.RemoveAll(tempDir)，注意不是Remove - 若需跨多个函数复用，把
tempDir作为参数传递，避免全局状态 - 不要在 defer 里忽略
os.RemoveAll的返回值——至少打日志，否则删失败你根本不知道
filepath.Join 拼路径时容易出错的三个点
临时文件路径看似简单，但 filepath.Join 的行为常被误读。比如 filepath.Join("/tmp", "myapp", "..", "data") 会变成 /tmp/data，但如果你传入的是绝对路径片段（如 "/home/user/tmp"），前面所有路径都会被丢弃。常见陷阱：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 永远不要手动拼接
"./tmp/" + name—— 用filepath.Join(tempDir, name) - 传给
os.Create前，先用filepath.Abs检查路径是否意外跳出了临时目录（防路径遍历） - Windows 下
filepath.Join("C:\tmp", "file.txt")没问题，但混用/和可能导致Stat失败，一律走filepath包
清理时机选 os.Exit 还是 signal.Notify
只靠 defer 挡不住 SIGKILL，但绝大多数 CLI 工具其实不需要扛住 kill -9——用户要的是 Ctrl+C 或正常退出时清理干净。这时候 signal.Notify 更实用：
- 监听
os.Interrupt和syscall.SIGTERM，收到后调用清理函数并os.Exit(0) - 清理函数里先关掉所有打开的
*os.File（避免 Windows 下删不了），再os.RemoveAll - 不要在 signal handler 里做耗时操作（比如压缩日志），清理必须快，否则系统可能强制终止进程
- 如果程序是 daemon 或长期运行服务，才需要额外考虑
atexit类机制（Go 没原生支持，得自己维护 cleanup list）
最易被忽略的是：临时目录本身可能被其他进程创建并写入，os.RemoveAll 会失败。实际部署前，务必在目标环境跑一次 ls -la /tmp/myapp* 看权限和归属——尤其容器里以非 root 用户运行时，/tmp 权限不对会导致整个清理链失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
