NamedTemporaryFile退出后文件仍在，因默认delete=False（Windows除外）且不注册atexit钩子；需显式delete=True+with语句，或delete=False+手动os.unlink()。
tempfile.NamedTemporaryFile 为什么退出后文件还在？
直接调用 tempfile.NamedTemporaryFile() 默认不会在程序退出时自动清理，尤其当文件被显式 close() 后，系统只是释放句柄，文件实体仍保留在磁盘上——这是最常被误解的一点。根本原因在于：Python 的 NamedTemporaryFile 默认参数是 delete=False（仅在 Windows 上为 True），且它不注册 atexit 清理钩子。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 始终显式传入
delete=True（Linux/macOS 必须） - 避免手动调用
.close()，改用with语句确保上下文退出时自动关闭+删除 - 若需在关闭后仍访问路径（比如传给 subprocess），必须自己管理生命周期，
delete=False+ 手动os.unlink()
如何保证临时文件路径安全且不可预测？
绕过 NamedTemporaryFile 直接拼接路径是危险的：/tmp/myfile_123.txt 可能被竞态攻击（TOCTOU）。正确做法是让 tempfile 库生成带随机后缀、权限受限的路径。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
tempfile.mkstemp()获取安全路径和 fd，再用os.fdopen(fd, 'w')包装成文件对象 - 或更推荐：用
tempfile.mktemp()已被弃用，绝对不要用 - 创建后立即
os.chmod(path, 0o600)（Linux/macOS），防止其他用户读取 - Windows 下注意：
mkstemp创建的文件默认继承父目录权限，需额外调用os.chmod限制
subprocess 调用外部命令时怎么传临时文件又不泄漏？
常见错误是把 NamedTemporaryFile(delete=False) 的 .name 传给 subprocess.run()，然后忘记 os.unlink() —— 一旦子进程崩溃或异常退出，文件就永久残留。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 优先使用
tempfile.SpooledTemporaryFile处理小数据，它内存中缓存，超阈值才落盘，且close()后自动清理 - 若必须落盘并传给子进程：用
with tempfile.NamedTemporaryFile(delete=False) as f:→ 写入 →f.close()→ 调用subprocess→ 用try/finally包裹os.unlink(f.name) - 更健壮的做法：用
shutil.copyfileobj()把内容流式传入子进程 stdin，完全避免写临时文件
Windows 下 delete=True 为何有时仍报 PermissionError？
Windows 锁定打开的文件句柄，如果临时文件在 with 块内被子进程（如 notepad.exe）打开，Python 关闭时会因句柄未释放而抛 PermissionError: [WinError 32] The process cannot access the file...。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- Windows 上慎用
delete=True配合子进程访问；改用delete=False+ 显式os.unlink()并捕获异常 - 调用子进程前，确保已
close()临时文件对象（with块内不能直接传f.name给子进程） - 必要时用
tempfile.gettempdir()检查实际路径，确认不是在只读或 NTFS 加密卷上
真正安全的临时文件不是“创建完就不管”，而是明确控制打开、使用、关闭、删除四个阶段的边界。跨平台时，Linux/macOS 的 delete=True 行为与 Windows 的句柄语义差异，是最容易翻车的地方。
