Python mmap 修改文件后如何保证变更刷回磁盘

故障通常出在“内存里的内容变了”和“磁盘上的文件已经按要求落稳”被当成一件事。Python 的 mmap 修改成功，只能说明映射对象接受了写入；要让底层文件及时看到变化，需要使用可写共享映射并调用 mm.flush()。如果场景还要尽量应对进程崩溃或突然断电，则在它之后对同一个文件描述符调用 os.fsync()。

先确认映射模式真的会更新底层文件

排查第一步不是立刻加 fsync，而是回到构造映射的那一行。文件应以可更新的二进制模式打开，例如 r+b；映射则应明确指定 access=mmap.ACCESS_WRITE。这种映射对字节或切片的赋值会影响底层文件。

相反，ACCESS_COPY 是写时复制：程序可以在映射对象里看到新值，但这些值不会更新原文件。它适合临时试算，不适合作为“修改配置文件后保存”的实现。若原文件对象使用了缓冲写入，创建映射前还要先对文件对象执行 f.flush()，让待写缓冲先可见。

把 mmap.flush 和 os.fsync 排成两层

这两个调用解决的是相邻但不同的边界。mm.flush() 把内存映射中的变更刷回文件写回路径；Python 文档还明确指出，不调用它时，不能保证对象销毁前改动已经写回。os.fsync() 面向文件描述符，适用于需要更强落盘语义的场景。它会增加 I/O 等待，不应在每个字节修改后调用，而应放在一批修改完成之后。

import mmap
import os

path = "records.bin"
offset = 128
replacement = b"READY"

with open(path, "r+b", buffering=0) as f:
    # ACCESS_WRITE 让切片赋值关联到底层文件，而不是私有副本。
    with mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_WRITE) as mm:
        # 这里保持替换长度一致，避免把固定布局后的字段整体错位。
        mm[offset:offset + len(replacement)] = replacement
        # 先提交映射页；失败时让异常继续向上抛出，不要假装已保存。
        mm.flush()
        # 需要更强的崩溃持久性时，再同步同一个文件描述符。
        os.fsync(f.fileno())

上面的顺序表达的是一个工程选择：普通批量修改至少显式调用 flush()；配置、索引或恢复点文件若不能接受只停留在缓存层，则把 fsync() 放在 flush 成功之后。它仍不是事务机制，多个文件之间的一致提交需要临时文件、重命名或数据库等更高层方案。

局部刷盘、缓冲和关闭顺序

整段映射刷盘最简单：直接调用 mm.flush()。需要减少刷盘范围时，可以传入 offset 和 size，但 offset 必须按当前平台的页面大小或分配粒度对齐；把业务字段的任意偏移直接传进去，可能得到 OSError。因此固定格式文件通常先按页面范围计算，再决定是否值得做局部刷盘。

mm.close() 只关闭映射对象，不会关闭原先打开的文件；嵌套 with 可以让两种资源的退出顺序清晰可见。若 flush 或 fsync 抛出异常，应把这次写入当作未完成，记录文件、范围和异常，而不是仅依赖进程退出时的隐式清理。

用一条可复查的判断链收尾

遇到“修改偶尔消失”，可以按这条顺序复盘：文件是否以 r+b 打开；映射是否是 ACCESS_WRITE；赋值长度是否符合文件格式；是否在批次末尾调用 mm.flush()；是否真的需要并成功执行 os.fsync()；局部刷盘的 offset 是否对齐；最后才看并发写入、文件替换和文件系统本身的恢复策略。这样能把 Python API 语义与更高层的事务问题分开，避免给所有写入机械地加同步调用。

常见问题

只调用 mmap.flush，不调用 os.fsync，可以吗？

如果目标是让映射修改进入文件写回路径，通常可以；如果目标是提高突然断电后的持久性，应在 flush 成功后对文件描述符 fsync。两者不是重复调用。

ACCESS_COPY 修改后为什么重新打开文件看不到？

因为它是写时复制映射，修改只保留在当前映射的私有副本中。需要保存原文件时使用 ACCESS_WRITE，并安排 flush。

mm.close() 以后还要关闭 f 吗？

要。mmap.close 只释放映射对象，原文件对象仍由自己的 with 语句管理；嵌套上下文能避免遗漏关闭。