tmpfile在windows上常返回null，因旧版msvcrt对tmp路径权限要求严格，遇不可写目录、杀毒拦截或uac限制即静默失败；推荐跨平台用mkstemp（linux/macos）或gettempfilenamea+fopen（windows）替代，并注意自动清理与权限隔离。
tmpfile 在 Windows 上为什么总返回 NULL？
因为 tmpfile 默认以 "wb+" 模式打开，而 Windows 的 C 运行时（尤其是旧版 MSVCRT）对临时文件的权限和路径处理较严格，若系统 TMP 环境变量指向不可写目录、或防病毒软件拦截、或进程无管理员权限但 TMP 落在受保护路径（如 C:\Windows\Temp），就会静默失败。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 调用前先检查
getenv("TMP")或getenv("TEMP")是否存在且可写（用access(path, W_OK)验证） - 不要依赖
tmpfile自动清理——它只在 fclose 时删文件，进程崩溃就残留；跨平台更不可靠 - Linux/macOS 下它通常工作，但文件名不可知，无法传递给子进程或 mmap，实用性受限
mkstemp 是更可靠的选择，但 Windows 没原生支持
mkstemp 在 POSIX 系统上能生成唯一路径+打开文件描述符，避免竞态，是事实标准。Windows 缺这个函数，直接调用会链接失败或触发未定义行为。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用条件编译封装：Linux/macOS 直接调
mkstemp；Windows 改用_mktemp_s+fopen组合（注意_mktemp_s只生成路径，不创建文件） - 模板字符串必须含至少六个
X（如"myappXXXXXX"），否则mkstemp拒绝执行 - Windows 下
_mktemp_s不保证线程安全，需加锁或用GetTempFileNameA替代（但它只支持 65535 个唯一名，易耗尽）
一个最小可行封装：返回 FILE* 且自动清理
跨平台临时文件的核心诉求其实是「开一个独占、可读写、进程退出时自动删」的文件。没必要强求统一接口，而是按平台选最稳路径。
示例逻辑（关键片段）：
#ifdef _WIN32
char path[MAX_PATH];
GetTempPathA(MAX_PATH, path);
GetTempFileNameA(path, "tmp", 0, path); // 生成唯一路径
FILE* f = fopen(path, "w+b");
if (f) _set_fmode(_O_BINARY); // 避免文本模式换行符干扰
#else
char path[] = "/tmp/myappXXXXXX";
int fd = mkstemp(path);
if (fd != -1) {
FILE* f = fdopen(fd, "w+b");
// 成功后 unlink(path) 立即删除路径，文件句柄仍有效
unlink(path);
}
#endif
注意点：
- Windows 下
GetTempFileNameA生成的文件默认存在，需手动unlink或DeleteFileA清理；POSIX 下unlink后只要 fd 没关，文件内容仍在磁盘直到 fclose - 路径长度：Windows MAX_PATH 是 260，
GetTempPathA可能返回长路径，建议用GetTempPath2A（Win10 1903+）或手动截断 - 别用
std::filesystem::temp_directory_path()—— C++17 该函数在 MinGW 和旧 MSVC 上常返回空或错误路径
临时文件名冲突与安全风险
用时间戳或 PID 拼接名字（如 "tmp_12345_6789"）看似简单，但在高并发场景下极易撞名，导致数据覆盖或权限泄露。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 必须用内核级原子操作生成名：POSIX 是
mkstemp，Windows 是GetTempFileNameA或CreateFileA配CREATE_ALWAYS | FILE_ATTRIBUTE_TEMPORARY - 临时目录权限要设为仅当前用户可读写（
chmod 0700/SetSecurityDescriptor），尤其服务进程不能把临时文件放全局可写目录 - 如果文件需被其他进程访问（如调试日志），改用命名管道或内存映射文件，别硬塞临时目录
真正麻烦的不是怎么生成文件，而是确保“唯一性”“及时清理”“权限隔离”三者同时成立——这三个点任意一个漏掉，跨平台临时文件就变成定时炸弹。
