C++里那个“临时目录”到底该不该信？——temp_directory_path()实战避坑手记

刚写完一段代码，想把中间生成的日志、缓存或压缩包扔进系统临时目录，顺手调了 std::filesystem::temp_directory_path()。结果一跑，程序在同事的Mac上卡住，在CI服务器上直接抛 filesystem_error。不是它不工作，而是它太“诚实”——它只告诉你“理论上该去哪”，从不保证“那里真能用”。

这大概就是C++20引入 temp_directory_path() 后，最常被忽略的真相：它返回的是一条路径，不是一张通行证。

temp_directory_path() 的逻辑其实很朴素：按顺序查环境变量（TMPDIR / TEMP / TMP），再 fallback 到系统默认位置（Windows 是 GetTempPathW，Linux/macOS 通常是 /tmp）。但它不做任何可写性、存在性、空间余量或权限校验。你拿到 /tmp，不代表你有权限 mkdir 一个子目录；你看到 $HOME/.cache/tmp，也不代表那个 .cache 目录已经存在。

实际项目里，我见过三种典型翻车现场：

• 某嵌入式设备 rootfs 只读，/tmp 指向 /var/tmp，而 /var 根本没挂载——temp_directory_path() 照样返回 /var/tmp，直到 create_directories() 才崩；
• macOS 上用户禁用了全盘访问权限，沙盒进程连 /tmp 都打不开，is_writable() 返回 false，但没人检查；
• Docker 容器启动时没挂载 /tmp，或者挂载为 noexec,nosuid，路径存在，但 open() 失败，错误码却是 EACCES 而非 ENOENT，容易误判。

所以，拿到路径只是第一步，真正干活前必须亲手验证。别嫌啰嗦，加三行检查，省得半夜收告警：

namespace fs = std::filesystem;
auto tmp = fs::temp_directory_path();
if (!fs::exists(tmp)) {
    throw std::runtime_error("temp dir does not exist: " + tmp.string());
}
if (!fs::is_directory(tmp)) {
    throw std::runtime_error("temp path is not a directory: " + tmp.string());
}
if (!fs::is_writable(tmp)) {
    throw std::runtime_error("temp directory is not writable: " + tmp.string());
}

更进一步，如果你要创建子目录（比如 myapp_abc123），别直接 fs::create_directories(tmp / "myapp_abc123") 就完事。create_directories 成功，不代表你能往里写文件——某些 NFS 或容器卷会允许建目录，但拒绝 open(O_CREAT)。稳妥做法是：建完立刻 touch 一个测试文件，再删掉：

auto my_tmp = tmp / ("myapp_" + generate_id());
fs::create_directories(my_tmp);
auto test_file = my_tmp / ".write_test";
std::ofstream(test_file).close();
if (!fs::exists(test_file)) {
    throw std::runtime_error("cannot write to temp directory");
}
fs::remove(test_file);

还有个隐形坑：路径长度。Windows 对全路径长度有限制（MAX_PATH=260，虽已支持长路径但需显式开启），而 temp_directory_path() 返回的路径本身可能就很长（比如 %LOCALAPPDATA%\Packages\...\Temp）。如果你再拼上多层子目录和长文件名，很容易触发 filename too long。对策很简单：优先用 std::filesystem::weakly_canonical 规范化路径，再检查 string().length() 是否逼近临界值（如 Windows 下超过 240 字符就预警）。

另外，别迷信“临时=可随意删除”。有些系统（如 systemd-tmpfiles）会定期清理 /tmp，但清理策略不统一。如果你的程序需要临时文件存活数小时以上，temp_directory_path() 不是最佳选择——改用 fs::current_path() / "cache" 或明确配置的用户数据目录更可控。

最后说个容易被忽略的细节：temp_directory_path() 是线程安全的，但返回的 path 对象不是引用，是值拷贝。所以你不必加锁，也无需担心生命周期问题。但它不会自动处理编码问题——在 Windows 上，如果环境变量含非UTF-8字符（极少见但存在），返回路径可能乱码。此时应捕获异常并 fallback 到硬编码安全路径（如 C:/Temp），而不是让整个流程静默失败。

总结下来，temp_directory_path() 是个好工具，但不是免检通道。它像朋友告诉你“地铁口右转第三家咖啡馆”，你得自己走到门口，推门试试能不能进，再点杯拿铁确认营业。路径只是地图上的一个点，真正的可用性，得靠你亲手敲门验证。

下次再用它，别急着 open()，先 exists()、is_directory()、is_writable()——这三关过了，临时目录才真正属于你。