NamedTemporaryFile 默认不能跨进程访问，因其在Windows上delete=True导致文件路径被标记删除待定、其他进程无法打开，Linux也存在缓存或权限问题；跨进程须设delete=False并手动close后由其他程序打开，再用os.unlink()清理。

tempfile.NamedTemporaryFile 为什么默认不能跨进程访问

因为它的底层行为依赖操作系统临时目录权限和文件句柄独占机制，NamedTemporaryFile 在 Windows 上默认使用 delete=True，创建后立即被标记为“删除待定”，但文件句柄仍有效——这导致其他进程无法打开该路径；Linux 虽允许路径存在，但若未显式关闭并重新打开，也可能因缓存或权限问题失败。

实操建议：

• 跨进程共享必须设 delete=False，且手动调用 .close() 后再由其他程序打开
• 务必用 os.unlink() 或 Path.unlink() 清理，不能依赖上下文管理器自动删除
• 避免在多线程中复用同一 NamedTemporaryFile 实例，不同线程可能触发竞态删除

如何确保 tempfile.mktemp() 不再被推荐使用

mktemp() 返回纯路径字符串，不创建文件，也不做存在性检查或权限控制，极易引发竞态条件（TOCTOU）：调用返回路径后、你真正 open() 前，另一进程可能已创建同名文件并写入恶意内容。

替代方案直接用 NamedTemporaryFile 或 mkstemp()：

立即学习“Python免费学习笔记（深入）”；

Claw Code Suite (Python-Only Edition)

仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...

下载

• NamedTemporaryFile(delete=False) —— 返回带句柄的文件对象，路径安全可共享
• os.mkstemp() —— 返回 (fd, path) 元组，需自行 os.close(fd)，适合需要细粒度控制 fd 的场景
• 永远不要对 mktemp() 结果做 open(..., 'w')，这是明确的安全反模式

在 Docker 容器里用 tempfile 创建文件要注意什么

容器内 /tmp 通常挂载为 tmpfs，空间有限且重启即失；更关键的是，若应用以非 root 用户运行（推荐做法），tempfile 默认仍尝试写入系统级 /tmp，可能因权限不足静默失败或回退到当前目录——而当前目录未必可写。

解决方法：

• 启动容器时通过环境变量指定：export TMPDIR=/app/tmp && python app.py，并在代码中传入 dir=os.environ.get("TMPDIR")
• 创建前主动检查：os.access(temp_dir, os.W_OK)，避免静默降级
• 避免依赖 tempfile.gettempdir() 的默认值，它可能指向不可写的只读路径

为什么 with tempfile.NamedTemporaryFile() 写入后读不到内容

常见于未重置文件指针位置。NamedTemporaryFile 默认以 w+b 模式打开，写入后指针停在末尾，紧接着 .read() 返回空 bytes。

正确做法：

• 写入后调用 .seek(0) 回到开头再读
• 若需多次读写，用 seek(0, 2) 移动到末尾追加，而非反复 open/close
• 注意 Windows 下文本模式换行符处理差异，二进制模式 w+b 更可控

临时文件的安全性不在“随机名”，而在创建原子性、权限隔离与生命周期可控——名字只是表象，句柄持有、路径可见性、删除时机才是关键。稍不注意，delete=False 就变成磁盘泄漏点，mkstemp 的 fd 若未关闭就可能触发“too many open files”。