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()：
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”。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
