不能直接用os.CreateTemp做并发文件管理，因其仅保证单次调用路径唯一，无并发控制，多goroutine调用可能生成相同前缀文件名，且返回的*os.File被共享会导致写入竞态、偏移错乱和panic。
为什么不能直接用 os.CreateTemp 做并发文件管理
因为 os.CreateTemp 只保证单次调用生成唯一路径，不提供任何并发控制——多个 goroutine 同时调用它，可能在极短时间内生成相同前缀的文件名（尤其当 pattern 缺少 * 或系统随机数熵不足时），更关键的是：它不管理后续的读写行为。一旦你把返回的 *os.File 交给多个 goroutine 共享，就会触发竞态：写入交错、偏移错乱、bad file descriptor panic。
TempFileManager 必须隔离句柄 + 控制生命周期
真正高并发安全的封装，核心不是“避免冲突”，而是“让每个操作拥有独立资源上下文”。这意味着：
- 每次
Create都应返回一个独占的*os.File，且该句柄**绝不复用**给其他 goroutine - 写入操作必须绑定到该句柄，并在完成时显式
Close()；若需多次写入，应由调用方自己维护句柄，管理器只负责创建和清理入口 - 清理逻辑不能只靠
defer os.Remove：如果文件正被另一个 goroutine 打开读取（比如上传中又启动了校验），os.Remove在 Windows 上会失败，Linux 下虽可删但句柄仍有效（直到所有引用关闭） - 推荐模式是：创建 → 使用 →
Close()→os.Remove()，三步串行不可跳过；若需延迟删除（如异步处理），应改用带 TTL 的后台清理 goroutine，而非依赖 defer
如何设计并发安全的创建与清理接口
一个最小可行的封装结构体应包含：
-
Dir string：传""让os.TempDir()自动选目录，避免硬编码/tmp或C:\Temp -
Pattern string：必须含*，例如"upload-*.bin"，否则退化为固定名，必然冲突 -
Create() (*os.File, error)：内部调用os.CreateTemp(dir, pattern)，并立即设置0600权限（防敏感内容泄露） -
CreateInDir(subdir string) (*os.File, error)：先os.MkdirAll(filepath.Join(m.Dir, subdir), 0755)，再创建，适合按业务分组隔离 - 不提供
Write方法：写入逻辑应由业务层决定（流式写？原子写？是否需要Sync()？），管理器只管“生”和“收”
示例初始化：
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
立即学习“go语言免费学习笔记（深入）”；
mgr := &TempFileManager{
Dir: "", // 自动选系统临时目录
Pattern: "job-*.log",
}
file, err := mgr.Create()
if err != nil {
return err
}
defer file.Close() // 必须先关句柄
defer os.Remove(file.Name()) // 再删文件
容易被忽略的跨平台陷阱
Windows 和 Linux 对“正在使用的文件能否删除”的行为完全不同：
- Linux：
os.Remove()立即成功，文件系统标记为待删，所有已打开的*os.File仍可读写，直到最后一个句柄Close() - Windows：只要文件被任意进程以写模式打开，
os.Remove()就会返回The process cannot access the file because it is being used by another process - 所以，如果你的模块要跨平台，就不能假设
defer os.Remove(...)总能成功——必须确保Close()在Remove()之前执行，且中间无 panic 跳过 - 更稳妥的做法是：把
Close()和Remove()放进同一个defer函数，并用recover()捕获 panic 后仍尝试清理
真正难的不是写代码，而是想清楚：这个临时文件，到底归谁关、归谁删、归谁负责超时兜底。没想清这点，再多封装也只是把坑藏得更深。
