tmpnam 不安全，因存在 TOCTOU 漏洞且已被标准弃用；应改用 mkstemp（POSIX）或 std::filesystem::temp_directory_path + 随机名（C++17+），tmpfile() 仅适用于进程内无路径需求场景。
tmpnam 为什么不能用，连编译都警告
因为 tmpnam 生成的文件名不绑定实际文件，调用后只是返回一个字符串，没人帮你创建文件。攻击者可以在你 fopen 之前抢先创建同名文件（符号链接或普通文件），导致写入被劫持——这是经典的 time-of-check-to-time-of-use（TOCTOU）漏洞。
几乎所有现代编译器（GCC、Clang、MSVC）默认对 tmpnam 发出弃用警告，Windows 上甚至直接禁用（除非定义 _CRT_SECURE_NO_WARNINGS）。
- 不要用
tmpnam，哪怕加锁或 sleep 也解决不了竞争条件 - POSIX 标准已将其标记为 obsolete，C++23 明确移除
- 如果旧代码里看到它，优先替换成
mkstemp或std::filesystem::temp_directory_path+ 随机名
tmpfile() 看似安全，但有隐性限制
tmpfile() 确实原子地创建并打开一个唯一临时文件（通常在 /tmp），且进程退出时自动删除。但它返回的是 FILE*，文件句柄不可跨进程共享，也不能获取文件路径——这意味着你无法把它传给外部命令（如 system("gzip")）或 mmap。
更关键的是：它依赖系统 tmp 目录的权限和空间，且某些嵌入式或容器环境可能禁用 /tmp 写入；Windows 上它用的是当前目录而非系统 temp 路径，容易因工作目录变更出错。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
tmpfile()适合“只在本进程内读写、不关心路径”的场景（比如中间缓存） - 不适用于需要路径字符串的操作（
exec、stat、日志记录） - 返回
NULL时别只检查 errno，也要确认磁盘配额、umask 和/tmp挂载选项（如noexec、nosuid）
C++17 起该用 std::filesystem::temp_directory_path + 随机名
标准库不提供“安全生成唯一临时路径”的原子函数，但组合 std::filesystem::temp_directory_path() 和 std::tmpnam_s（C11 安全版）或自己生成随机后缀，是目前最可控的方式。关键是：生成名字 → 创建文件（O_CREAT | O_EXCL）→ 失败则重试。
注意 std::filesystem::temp_directory_path() 可能返回空或抛异常（比如环境变量 TMP 被设成非法路径），不能无条件信任。
- 用
std::random_device+std::uniform_int_distribution生成 6~8 位随机后缀，比时间戳+pid 更可靠 - 创建时务必用
std::filesystem::create_directories()确保父目录存在，再用std::filesystem::status()检查是否可写 - Linux 下推荐用
O_TMPFILEflag（需 kernel ≥3.11），但 C++ 标准库不封装它，得用 syscall 或openat
Linux/macOS 用 mkstemp 最省心，Windows 用 GetTempFileNameW
POSIX 的 mkstemp 是事实标准：传入模板字符串（如 "/tmp/myappXXXXXX"），它就地替换 XXXXXX 并原子创建文件，返回 fd——既安全又给你路径和句柄。Windows 对应的是 GetTempFileNameW（注意它只生成名字，不创建文件，得自己 CreateFile）。
跨平台项目别自己拼接 XXXXXX，不同系统对模板要求不同（比如 macOS 要求必须是 6 个 X，且路径需存在）；也不要忽略 umask 影响——mkstemp 创建的文件权限是 0600，但若进程 umask 是 0077，结果就是 0600，没问题；若 umask 是 0002，结果会是 0600 & ~0002 = 0600，依然安全。
- 模板字符串必须可写，且
XXXXXX必须在末尾，否则mkstemp返回 -1 - Windows 上
GetTempFileNameW生成的名字不带路径，要自己拼GetTempPathW结果 - 所有方案都要检查返回值：fd == -1、返回空字符串、抛 exception，都得兜底处理
临时文件真正的难点不在生成，而在生命周期管理：谁删、何时删、删失败了怎么办。用 std::unique_ptr 包裹 RAII 删除器？还是注册 atexit？抑或依赖系统 tmpwatch？这些决策比选哪个 API 更影响健壮性。
