os.CreateTemp 更安全因其默认 0600 权限、原子创建、忽略 umask、防符号链接攻击；需显式指定受控 dir、正确使用 * 模板、及时 close 并 remove。
os.CreateTemp 为什么比 os.TempFile 更安全
因为 os.CreateTemp 默认使用 0600 权限（仅属主可读写），且在创建时直接打开文件句柄，避免了“先创建再 chmod”或“先创建再 open”的竞态窗口。而 os.TempFile 创建的是目录项，返回的 *os.File 是可写的，但权限由 umask 决定，常导致临时文件被同用户其他进程读取甚至覆盖。
- Linux/macOS 上若 umask 是 0022，
os.TempFile创建的文件权限可能是 0644 —— 其他用户能读；os.CreateTemp强制忽略 umask，始终是 0600 - 不指定 dir 时，
os.CreateTemp会 fallback 到os.TempDir()，但该路径可能被配置为全局可写（如某些容器环境），需显式控制 - 它内部调用
syscall.Openat（Linux）或等价系统调用，原子性保证更强，不易被符号链接攻击劫持
必须显式指定 dir 参数，别依赖默认行为
os.CreateTemp 第一个参数是 dir，传 "" 看似省事，实则埋雷：它会调用 os.TempDir()，而该函数返回值受 TMPDIR 环境变量影响 —— 攻击者可通过伪造环境变量让临时文件落到任意可写路径（比如 /tmp 下某个软链指向 /etc/）。
- 安全做法是固定使用应用私有目录：
os.CreateTemp("/var/tmp/myapp", "*.log") - 若必须用系统临时目录，至少确保父目录权限严格：
stat -c "%a %U:%G %n" /var/tmp应显示 1777 root:root 或类似受限配置 - Windows 上注意
dir必须存在且可写，os.CreateTemp不会自动创建父目录
模板字符串里的星号 * 不能省，也不能放错位置
第二个参数 pattern 不是 glob，而是用于生成唯一文件名的模板。其中 * 是占位符，会被随机字节替换；没有 * 就会 panic，错误信息是 "pattern contains no asterisk"。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确：
os.CreateTemp("/tmp", "upload-*.bin")→ 生成/tmp/upload-aB3f9.bin - 错误：
os.CreateTemp("/tmp", "upload.bin")→ panic - 错误：
os.CreateTemp("/tmp", "upload.*.bin")→ 只替换第一个*，后面部分保留，仍合法但易误解 - 不建议用
time.Now().Format拼接时间戳代替*：缺乏随机性，可能冲突，且无并发安全保证
创建后务必检查并及时清理
os.CreateTemp 返回的 *os.File 是打开状态，但不会自动删除。如果程序 panic、提前 return 或忘记 close，文件会残留，还可能占用 inode。
立即学习“go语言免费学习笔记（深入）”；
- 用
defer f.Close()关闭句柄，但关闭 ≠ 删除文件 - 真正删除要靠
os.Remove(f.Name())，且应在业务逻辑完成、数据落盘确认后执行 - 更稳妥的做法是用
os.RemoveAll清理整个临时目录（配合唯一子目录），而非单个文件 —— 避免残留或误删 - 注意：Windows 上正被打开的文件无法删除，需确保已
f.Close()，否则os.Remove报错"The process cannot access the file because it is being used by another process"
临时文件的安全边界不在“怎么生成”，而在“谁可见、谁可写、谁可删”。哪怕用了 os.CreateTemp，如果目录权限松、模板可控、删得不及时，照样出问题。
