科技 · 实用指南
Windows 上的 Python NamedTemporaryFile：可重开且能清理
首次 PermissionError 与之后的删除失败原因不同。先决定删除边界，再确保所有第二句柄在该边界前关闭。
NamedTemporaryFile 在 Windows 上可能在两个时点失败：默认配置下，另一程序根本无法打开路径；改过参数后，程序虽能读取，却可能留下句柄，使上下文退出时清理失败。
把临时路径当作一次所有权交接。先决定删除发生在文件关闭、上下文退出还是自己的 finally 中，再让所有使用者在该边界前结束。
1. 先分清是哪一种 PermissionError
若子进程、浏览器或上传库无法打开路径，创建者仍持有一个 Windows 句柄，而第二打开者没有满足其共享条件。CPython 在 Windows 上对默认 delete=True、delete_on_close=True 使用 O_TEMPORARY；内置 open 和许多外部程序不会请求匹配的删除共享。
若使用者已经读完文件，但上下文退出或 os.unlink 才失败，应查找仍未关闭的另一个句柄。Microsoft 说明共享方式会持续到句柄关闭，删除也要等待兼容句柄。改一个参数不会替你关闭上传流、浏览器、子进程或重复文件对象。
2. Python 3.12+ 优先把清理放在上下文退出
面对普通外部打开者，可用 with NamedTemporaryFile(delete=True, delete_on_close=False) as tmp:。写入数据；若使用者在 tmp 保持打开时读取，就先 flush；若它要求独占访问，则在 with 块内先 close。路径会保留到 with 块退出，届时 Python 尝试 os.unlink。
离开 with 块前要等待子进程结束，并关闭上传时另行 open 的每个文件对象。不共享删除权限的普通第二打开必须先关闭。若目录本身没有删除权限，unlink 仍会抛出 PermissionError；应在实际部署目录验证，而不是吞掉错误。
3. 旧版 Python 用 finally 清理
Python 3.12 以前，或某个库要求先关闭包装器再交出路径时，使用 delete=False。关闭 NamedTemporaryFile，调用使用者，再在 finally 中删除路径。delete=False 会让 delete_on_close 失效，因此清理由你完全负责。
只在创建成功后保存路径；在 finally 中，先关闭所有第二流，再调用 os.unlink。不要用 tempfile.mktemp 绕过问题：它只返回未安全创建的名字，会引入 NamedTemporaryFile 正是为了避免的竞争条件。
4. 审计完整句柄生命周期
交接前确认写入已 flush，或按使用者要求关闭创建句柄，并确认路径存在。交接期间要等待使用者完成，不能异步启动后立刻退出上下文。若库接收文件对象，应把 open(tmp.name, 'rb') 放进自己的 with 块，让上传句柄确定性关闭。
清理前列出程序持有的文件对象、子进程和内存映射。清理后确认路径已消失，否则暴露准确错误。重试循环可能只是掩盖未关闭句柄，不能代替确认究竟是谁仍持有文件。
5. 明确保留可移植边界
POSIX 通常允许在命名临时文件仍打开时重开，但这不能证明 Windows 生命周期安全。所有平台都使用相同的显式交接与清理顺序，避免测试在 macOS 或 Linux 通过而生产在 Windows 失败。
三种选择的崩溃行为不同：默认关闭即删在所有打开者共享删除时最强；上下文退出清理更适合普通程序，却可能被中断；delete=False 兼容性最广，但需要 finally 以及启动时清扫遗留文件。代码评审应记录选择，并测试使用者失败和清理失败。
