flush()仅清空Python层缓冲区，不保证数据落盘；需配合os.fsync()（Unix/macOS）或os._commit()（Windows）才能强制写入物理磁盘，否则仍可能丢失。
flush() 只清 Python 缓冲区，不保证落盘
调用 f.flush() 后文件内容仍可能卡在操作系统或磁盘缓存里，外部进程读不到、断电就丢失。这是最常被误解的一点——flush() 仅把 Python 层缓冲区数据交给 OS，后续是否写入物理磁盘，它不管。
- Linux/macOS 必须补
os.fsync(f.fileno())才强制落盘 - Windows 上用
os._commit(f.fileno())替代 -
f.close()会自动flush()，但 fsync 行为取决于平台和文件系统，不可靠 - 如果文件已关闭再调
flush()，抛ValueError: I/O operation on closed file
buffering=1 不等于“实时”，它只对换行敏感
文本模式下设 buffering=1 是行缓冲，不是“每 write 都落盘”。只有写入 \n 时才触发刷新，且仅限文本模式；二进制模式设 buffering=1 等同于 buffering=8192（即按字节大小缓冲）。
- 写日志时，必须确保每条记录末尾带
\n，否则即使buffering=1也压根不刷 - 交互式终端中 Python 默认启用行缓冲，但脚本运行时不一定——别依赖环境默认值
- 想彻底禁用缓冲？只能用二进制模式 +
buffering=0，但性能极差，慎用
with 语句能自动 flush，但 fsync 仍需手动
with open(...) 是安全习惯，退出时自动 close() → 自动 flush()，但它不调用 fsync() 或 _commit()。对关键数据（如配置、交易记录、MD5 校验前的文件），这远远不够。
- 校验 MD5 前，必须先
f.flush()+os.fsync(f.fileno())（或os._commit()） - 多线程/多进程写同一文件时，
with不解决竞态，需额外加锁或改用原子写法（如写临时文件后os.replace()） - 频繁调
fsync()会严重拖慢吞吐，别在循环内无脑加——权衡延迟与可靠性
子进程读不到刚写的内容？大概率是没 fsync
用 subprocess.run() 启动另一个程序去读刚写完的文件，却读到空或旧内容，几乎全是缓冲未落盘导致。Python 写完、flush() 完、甚至 close() 完，OS 层仍可能缓存着。
- 典型场景：生成配置文件后立即
execv或subprocess.Popen启动服务 - 验证方法：写完后在 shell 里执行
sync（Linux）或fsync命令，看子进程能否读到——若能，就是 Python 没 fsync - 简洁写法：
os.fsync(f.fileno()) if hasattr(os, 'fsync') else os._commit(f.fileno())
真正落盘这件事，Python 层只是第一关。跨过 flush()，还有 OS 缓存、磁盘固件缓存、NFS 等层层拦截，而 fsync() 或 _commit() 是唯一能穿透到底层的手段。漏掉它，数据就始终悬在半空。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
