临时文件创建后必须显式清理，os.CreateTemp不会自动删除，需defer os.Remove或在所有退出路径确保清理；跨平台应传""让os.TempDir自动选目录；pattern必须含*防冲突；Write失败时文件仍残留，需覆盖全部退出路径。

临时文件创建后必须显式清理

Go 的 os.CreateTemp 或 ioutil.TempFile（已弃用）只负责生成路径并打开文件，**不会自动删除**。不手动调用 os.Remove 或用 defer 清理，临时文件会一直残留。

• 推荐在函数入口立即生成 defer 清理逻辑，例如：

  tmp, err := os.CreateTemp("", "prefix-*.log")
  if err != nil {
      return err
  }
  defer os.Remove(tmp.Name()) // 注意：不是 tmp.Close()

• 若文件需长期存在（如跨 goroutine 使用），不能依赖 defer，应改用带生命周期管理的封装结构
• Windows 下正在被进程打开的文件无法被 Remove，需确保先 Close() 再 Remove()

避免硬编码临时目录路径

直接拼接 /tmp 或 C:\Temp 会破坏跨平台兼容性，且忽略用户自定义的 TMPDIR/TEMP 环境变量。

• os.CreateTemp(dir, pattern) 的 dir 参数传 "" 即可自动使用系统默认临时目录（由 os.TempDir() 返回）
• 若需指定子目录（如项目专属临时区），应先用 os.MkdirAll 创建，并检查权限；不要假设 /tmp/myapp 一定可写
• 注意：Docker 容器中 /tmp 可能是内存文件系统（tmpfs），大文件易触发 OOM，需结合业务预估大小

并发场景下临时文件名冲突风险

os.CreateTemp 底层依赖随机数生成器和原子文件创建（O_EXCL），但若模式字符串中不含 *（如 "myapp.log"），将退化为固定名，**必然冲突**。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• pattern 必须包含至少一个 *，Go 会将其替换为随机字符串（如 "data-*.json" → "data-a1b2c3.json"）
• 高并发批量创建时，建议增加重试逻辑（最多 3 次），捕获 os.ErrExist 后重新调用 CreateTemp
• 不要用 time.Now().UnixNano() 拼接文件名——纳秒级时间戳在短时高频调用下极易重复，且无文件系统原子性保障

临时文件内容写入失败时的清理盲区

常见错误是只在 CreateTemp 成功后 defer Remove，但后续 Write 或 Sync 失败时，文件仍留在磁盘上。

立即学习“go语言免费学习笔记（深入）”；

• 应在所有可能退出的路径上确保清理，例如：

  tmp, err := os.CreateTemp("", "job-*.bin")
  if err != nil {
      return err
  }
  defer func() {
      if tmp != nil {
          os.Remove(tmp.Name())
      }
  }()
  _, err = tmp.Write(data)
  if err != nil {
      return err // tmp 未关闭，但 defer 仍会触发 Remove
  }
  err = tmp.Close()
  if err != nil {
      return err
  }

• 更稳妥的方式是封装为函数，用命名返回值或闭包统一收口清理逻辑
• 注意：Remove 本身也可能失败（如权限不足），生产环境建议记录警告日志，而非 panic

临时文件管理真正的复杂点不在创建，而在**退出路径的全覆盖**——函数有多个 return、panic 可能发生、goroutine 提前退出，都可能导致清理遗漏。别依赖“应该没问题”，每个 CreateTemp 都要配对思考“这个文件在什么情况下会被漏删”。