NamedTemporaryFile在Windows下不会自动删除，因其默认delete=True时文件句柄被保持至垃圾回收，而Windows禁止删除已打开文件，导致磁盘泄漏；跨平台应避免依赖delete=True，改用mkstemp()或TemporaryDirectory配合手动清理。
tempfile.NamedTemporaryFile 为什么不会自动删除？
默认情况下，tempfile.NamedTemporaryFile 创建的文件在 Windows 上无法被同一进程再次打开（报 PermissionError: [WinError 32]），而在 Linux/macOS 上虽可读写，但只要 Python 没有显式调用 .close() 或退出上下文，文件就一直存在——更关键的是：它并不会在对象销毁时自动 unlink（删除），除非你传入 delete=True（这是默认值，但容易被覆盖）。
常见误操作是手动调用 .name 后把它当普通路径传给其他程序（比如 subprocess.run(['cat', f.name])），然后忘了关闭或没进上下文管理器，导致文件残留甚至权限冲突。
实操建议：
- 始终用
with tempfile.NamedTemporaryFile(delete=False)显式控制生命周期，再手动os.unlink() - 若需跨进程访问，必须设
delete=False，且确保在使用完毕后调用os.unlink(f.name) - 避免直接依赖
__del__或 GC 触发删除：不可靠，尤其在异常中途退出时
如何保证临时文件路径不被猜中又可安全传递？
tempfile.mktemp() 已被弃用，因为它不原子、有竞态风险（生成路径和创建文件之间可能被抢占）。正确做法是先创建文件句柄，再取其路径——所有 tempfile 的“安全创建”函数都基于 os.open(..., os.O_EXCL | os.O_CREAT) 级别的原子性。
立即学习“Python免费学习笔记（深入）”；
实操建议：
- 用
tempfile.mkstemp()获取(fd, path)，然后用os.fdopen(fd, 'w')包装成文件对象；记得最后os.close(fd)（如果没用fdopen） - 若只需路径（如给外部命令用），用
tempfile.mktemp()是错的；改用tempfile.mkstemp()[1]或tempfile.NamedTemporaryFile(delete=False).name - 路径本身不含敏感信息，但别硬编码前缀或后缀（如
/tmp/myapp_*.log），否则易被预测并提前创建占位
Windows 下 subprocess 调用临时文件失败怎么解？
典型错误是：PermissionError: [WinError 32] 另一个程序正在使用此文件。这是因为 Windows 锁定已打开的文件，不允许其他进程同时访问，而 NamedTemporaryFile 默认以 delete=True 创建，内部文件句柄未关闭前，路径虽存在但无法被 subprocess 打开。
实操建议：
- Windows 必须用
delete=False+ 显式.close()+os.unlink() - 关闭后立即调用
subprocess，避免被其他线程干扰；必要时加time.sleep(0.01)（极少数情况需要） - 更稳妥的做法：用
tempfile.mktemp()替代？不行。改用tempfile.mkstemp()，关闭 fd 后再传路径
临时目录比临时文件更安全吗？
不是绝对更安全，但更可控。临时目录（tempfile.TemporaryDirectory()）自带上下文管理，退出时递归删除整个目录，适合存放多个关联文件（如配置+数据+日志）。但它不解决单个文件的并发访问问题，也不防止目录内文件被外部进程篡改。
实操建议：
- 多文件场景优先用
with tempfile.TemporaryDirectory() as tmpdir:，再在其中用os.path.join(tmpdir, 'xxx')构造路径 - 不要把
TemporaryDirectory的路径暴露给不受信代码（比如拼接进 shell 命令），否则可能路径遍历 - 注意：
TemporaryDirectory删除失败会抛出异常，但不会静默忽略；捕获OSError并记录即可
真正难处理的从来不是“怎么删”，而是“删之前有没有被其他逻辑意外持有句柄或路径”。Windows 的文件锁、Linux 的 open-atime、容器里 /tmp 的挂载方式……都会让看似简单的自删除变得脆弱。动手前先想清楚：这个临时文件是否必须跨进程？是否可能被异常中断？是否涉及敏感内容？这些比选哪个 API 更关键。
