临时文件未被删除且os.Remove报no such file or directory，根本原因是文件可能未成功创建、已被提前清理或路径错误；正确做法是先用os.Stat校验文件存在性与类型，再清理，并将清理逻辑与文件生命周期绑定，避免盲目调用os.Remove。
临时文件没被删，os.Remove 报 no such file or directory 怎么办
不是代码漏调用，而是文件可能已被其他协程或进程提前清理，或根本没成功创建。直接 os.Remove 不做判断会掩盖真实问题，还可能误报错误。
正确做法是：先检查文件是否存在，再决定是否清理；同时把清理逻辑和文件生命周期绑定，而不是靠“事后补救”。
- 用
os.Stat判断文件是否存在且是普通文件，避免对目录或符号链接误操作 - 在创建临时文件时就记录其预期存活时间（如通过
time.Now().Add(10 * time.Minute)），后续回收时按此判断是否过期 - 避免在 defer 中无条件调用
os.Remove—— 如果创建失败，tempFile是 nil，tempFile.Name()会 panic
os.CreateTemp 创建的文件怎么带自动过期标记
Go 标准库不提供内置过期机制，但可以在创建后立即写入元数据，或用文件名/路径编码过期时间。更轻量的做法是：把过期时间存进文件扩展名或前缀，比如 tmp_20240520143022_abc123.json，解析时间戳即可判断是否过期。
- 推荐用
os.CreateTemp创建时拼接时间戳：os.CreateTemp("", "cache_"+time.Now().Format("20060102150405")+"_*.log") - 不要依赖文件系统修改时间（
ModTime）做过期判断——程序重启、NTP 同步、挂载卷时钟漂移都会导致误判 - 如果必须用
ModTime，至少加一个最小安全偏移（如time.Now().Add(-5 * time.Second)）防止纳秒级时钟抖动引发误删
多个 goroutine 同时清理临时目录，如何避免重复删或删错
并发清理的核心矛盾是：一个文件可能被多个 goroutine 同时发现“过期”，然后都去 os.Remove。这不是竞态，但会造成冗余日志、误删刚写入的新文件（如果清理逻辑没做原子判断）。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 用
os.Rename先将待删文件移到临时隔离目录（如.to_delete），再批量清理该目录 —— 移动是原子的，可避免重复处理 - 对整个临时目录加读写锁（
sync.RWMutex）太重，改用基于文件名哈希的分片锁（如shardLocks[filenameHash%8]）更实用 - 清理前加一句
if !strings.HasPrefix(filepath.Base(name), "tmp_") { continue }，过滤掉非临时文件，防止误伤配置或日志
定时回收用 time.Ticker 还是信号触发
短周期（如每 30 秒）轮询适合低频写入、高一致性要求场景；但频繁 stat 所有文件开销大，尤其在临时目录有上千文件时。信号触发（如收到 SIGHUP 或内部 channel 通知）更省资源，但无法保证过期文件及时释放。
- 折中方案：用
time.Ticker每 2 分钟触发一次扫描，但只处理mtime超过阈值且文件名匹配tmp_*的项，跳过最近 10 秒内创建的文件 - 关键点：每次扫描前先
filepath.Glob获取候选列表，再逐个os.Stat—— 避免 glob 通配符遗漏，也避免反复 open 大量无效路径 - 如果程序本身有请求入口（如 HTTP handler），可在每次请求结束时顺带检查一次过期文件，降低 ticker 频率
真正难的不是“怎么删”，而是“什么时候删”和“删之前确认它真该删”。临时文件的生命周期管理，本质是时间判断 + 命名约定 + 原子操作三者的组合，缺一不可。
