NamedTemporaryFile 创建即返回可读写类文件对象并带真实路径，默认 delete=True 关闭后自动删除；需保留路径时设 delete=False 并手动清理，写入后须 flush() + os.fsync() 确保落盘。
用 tempfile.NamedTemporaryFile 直接获得可读写句柄
不需要先写再打开，NamedTemporaryFile 创建即返回一个类文件对象，带真实路径和系统级文件句柄。它默认在关闭后自动删除，但你可以在关闭前安全地读写、传递给其他需要 file 或 path 的函数。
常见错误是忽略 delete=False 参数导致后续无法通过路径访问——如果你需要在关闭后仍用该路径（比如传给子进程），必须显式设为 delete=False，并手动 os.unlink() 清理。
- 默认行为：
delete=True，close()后文件立即消失，仅适用于“写完就交给另一个库处理”的场景 - 需保留路径时：加
delete=False，且记得捕获异常后清理，否则临时文件会残留 - 跨平台注意：Windows 下不能在文件打开时用同一路径再次打开（如用
subprocess调用外部命令），应先close()再用name
写入内存数据后如何确保内容已落盘？
write() 只进内核缓冲区，不保证磁盘写入。若下游程序（如 C 工具、shell 命令）依赖文件内容完整，必须调用 flush() + os.fsync()。
典型场景：用 Python 生成配置文本，再调 subprocess.run(['some_tool', tmp.name]) —— 若没 fsync，工具可能读到空或截断内容。
立即学习“Python免费学习笔记（深入）”；
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
-
tmp.write(b'data')→ 数据在用户空间缓冲 -
tmp.flush()→ 推到内核页缓存 -
os.fsync(tmp.fileno())→ 强制刷到物理存储（关键！） - Windows 上
os.fsync()等价于_commit()，Linux/macOS 行为一致
为什么不用 tempfile.mkstemp()？
mkstemp() 返回的是裸文件描述符（int），不是文件对象，没法直接 .write()，必须包一层 os.fdopen(fd, 'w+b')。多数人真正要的是“带路径的可操作文件对象”，而非底层 fd。
容易踩的坑：用 mkstemp() 后忘记 os.close(fd)，导致 fd 泄露；或包成 fdopen 后没设好模式（比如二进制写却开成文本模式），引发编码错误。
-
NamedTemporaryFile更贴近直觉：创建即可用，接口统一 -
mkstemp()适合需要绕过 Python 缓冲、做原子重命名、或与 C 扩展交互的极少数场景 - 二者都遵守系统临时目录策略（
$TMPDIR/%TEMP%），无需额外配置
临时文件路径被其他进程读取失败？检查打开模式和平台限制
Windows 下，NamedTemporaryFile 默认以 delete=True 和 mode='w+b' 创建，但文件仍被当前进程独占打开。若子进程尝试以只读方式打开同一路径，会报错 PermissionError: [WinError 32] The process cannot access the file...。
解决办法只有两个：关掉当前句柄，或换用 tempfile.mktemp()（不推荐）+ 手动 open(..., 'w+b', delete=False)（更不推荐）。正确做法是——
- 写完调
tmp.close() - 再用
open(tmp.name, 'rb')或直接传tmp.name给子进程 - Linux/macOS 无此限制，但保持 close-then-open 习惯能提升跨平台健壮性
别依赖“文件对象还开着就能被别人读”——这既不符合 POSIX 语义，也不在 Windows 上成立。临时文件的本质是“暂存”，不是“共享管道”。
