std::tmpnam在多线程中不可用，因其无同步机制、共享静态缓冲区导致名称覆盖与重复，且不保证文件不存在；应改用mkstemp（Linux/macOS）或GetTempFileNameW（Windows），二者均原子创建文件。
std::tmpnam 为什么在多线程里根本不能用
它不带任何同步机制，内部静态缓冲区被多个线程同时调用时会相互覆盖，生成的文件名大概率重复。更糟的是，std::tmpnam 返回的路径不保证对应文件不存在——它只“建议”一个名字，你 fopen 时仍可能因竞态条件失败（errno == EEXIST）。
实操建议：
- 彻底弃用
std::tmpnam和std::tmpfile（后者内部也依赖不可重入的底层实现） - 不要自己拼接
/tmp/myapp_+std::time(nullptr)+std::this_thread::get_id()—— 时间精度低、线程 ID 可能复用、无原子性保障 - Linux/macOS 下优先用
mkstemp；Windows 下用GetTempFileNameW，二者都原子创建并返回已打开的 fd / HANDLE
Linux/macOS：用 mkstemp 替代手写逻辑
mkstemp 是 POSIX 标准函数，真正原子：模板字符串中六个 X 被随机字节替换，文件立即创建且以 O_EXCL 打开，确保唯一性和竞态免疫。
常见错误现象：传入栈上字符串（如 char tmpl[] = "/tmp/myapp_XXXXXX"），但 mkstemp 会就地修改它——若该内存后续被复用或释放，行为未定义。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 模板必须可写、生命周期覆盖整个使用过程（推荐
std::vector<char></char>或堆分配） - 模板路径尽量用绝对路径，避免当前工作目录影响（
/tmp/最稳） - 创建后立即
unlink（可选），让文件系统在 fd 关闭时自动清理，防残留
简短示例：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::vector<char> tmpl{'/','t','m','p','/','t','m','p','_','X','X','X','X','X','X',' '};
int fd = mkstemp(tmpl.data());
if (fd == -1) { /* handle error */ }
// 此时 tmpl.data() 已含真实路径，fd 已打开且独占Windows：别碰 tmpnam，用 GetTempFileNameW
GetTempFileNameW 是 Windows 唯一靠谱选择。它会在指定目录下原子生成唯一文件名（基于时间戳+计数器+随机扰动），并创建空文件（注意：不是打开）。比自己调 CreateFileW + 循环重试安全得多。
容易踩的坑：
- 传入的缓冲区必须至少
MAX_PATH长（260），否则截断导致路径非法 - 第二个参数是前缀（最多3字符），不是完整文件名；第三个参数是唯一序号输出，可传
nullptr - 它不保证文件内容为空——若磁盘满或权限不足，可能静默失败，务必检查返回值
示例关键片段：
WCHAR path[MAX_PATH];
WCHAR tempDir[MAX_PATH];
GetTempPathW(MAX_PATH, tempDir);
if (GetTempFileNameW(tempDir, L"my", 0, path) == 0) {
// 失败，查 GetLastError()
}
// path 现在是完整绝对路径，文件已存在（空）跨平台封装要注意的三个硬约束
如果项目要同时跑 Linux 和 Windows，直接封装一层函数看似省事，但有三处必须显式处理：
- 路径分隔符：Windows 用
\，POSIX 用/；临时目录路径本身就得按平台选（/tmpvsGetTempPathW） - 文件语义差异：
mkstemp返回 fd 并打开文件；GetTempFileNameW只建空文件，需额外CreateFileW打开 - 编码：Windows API 默认宽字符，Linux 路径是 UTF-8 字节流；C++17
std::filesystem的temp_directory_path()能统一获取路径，但创建操作仍需平台分支
最简健壮做法：用预处理器分两支，各自调原生 API，不强求“一份代码走天下”。临时文件这种基础设施，宁可多几行 #ifdef _WIN32，也别为抽象引入竞态风险。
真正麻烦的从来不是“怎么生成名字”，而是“名字生成后到文件写入完成之间，有没有其他线程/进程插进来删掉或覆盖它”——所以所有方案必须绑定原子创建动作，而不是名字生成动作。
