直接用open()读写几十GB文件会卡死，因其默认将整个文件加载进内存或频繁触发系统调用，易引发OOM；mmap通过页表映射绕过I/O缓冲层，实现按需分页加载，适合随机访问但非顺序流式处理。
为什么直接用 open() 读写几十GB文件会卡死？
因为默认方式会把整个文件加载进内存或频繁触发系统调用，read() 和 write() 在超大文件上会变成 I/O 瓶颈，甚至触发 OOM。mmap 的核心价值不是“更快”，而是绕过 Python 的 I/O 缓冲层，让进程直接操作页表映射——数据不复制、不缓存、按需分页加载。
但注意：mmap 不是万能加速器。它适合随机访问、重复读写固定偏移、或需要多进程共享同一文件的场景；对纯顺序流式处理，反而可能因缺页中断变慢。
mmap.mmap() 的三个关键参数怎么选？
最常出错的是 length、access 和 offset 的配合。尤其 length 必须显式指定（不能传 0 除非你确定文件大小不变），否则在 Windows 上会报 WindowsError: [Error 87]，Linux 则可能映射失败。
-
length：必须 ≤ 文件当前大小；若要支持后续追加，得先f.truncate(new_size)再重新mmap -
access：读写必须用mmap.ACCESS_WRITE；只读用ACCESS_READ；若需写但不想落盘，用ACCESS_COPY（但修改不会同步到文件） -
offset：必须是系统页大小的整数倍（通常为 4096），否则抛ValueError: offset is not a multiple of the page size
示例：安全打开一个 100GB 二进制文件用于随机写入
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
import mmap
f = open("huge.bin", "r+b")
# 先确保文件至少有 100GB
f.seek(0, 2)
if f.tell() < 100 * 1024**3:
f.truncate(100 * 1024**3)
# 正确映射：offset=0，length=100GB，可读可写
mm = mmap.mmap(f.fileno(), length=100*1024**3, access=mmap.ACCESS_WRITE)
mm[0:8] = b"\x01\x02\x03\x04\x05\x06\x07\x08" # 直接字节赋值
多进程共享 mmap 文件时为何总遇到 PermissionError: [WinError 5]？
Windows 下，文件句柄默认不可继承，子进程无法复用父进程的 mmap 对象；Linux 虽支持 fork 后继承，但若用 spawn 启动方式（如 multiprocessing 默认在 Windows/macOS），同样失效。
- 跨平台解法：所有进程都独立
open()同一文件，再各自mmap—— 但必须保证access一致，且写入时加外部锁（如filelock），否则数据撕裂 - Windows 专用：用
mmap.mmap(..., tagname="MySharedMap")创建命名映射，子进程通过同名打开（注意权限和大小需预先协商） - 绝对避免：在父进程中创建
mmap后，试图把它作为参数传给Process(target=..., args=(mm,))—— 这在任何平台都会失败
写完 mmap 为啥文件没更新？
常见误解是 “写了内存就等于写了磁盘”。实际上，mmap 的修改是否落盘取决于操作系统调度和 flush() 调用。Linux 下通常会在内存压力大或 sync 时刷盘；Windows 更保守，可能延迟更久。
- 强制落盘：调用
mm.flush()—— 它等价于msync(MS_SYNC)，会阻塞直到数据写入磁盘（注意：不保证元数据如 mtime 更新） - 异步提示：
mm.flush(offset, size)可刷局部区域；mm.flush()无参则刷全部 - 退出前别忘
mm.close()和f.close()，否则可能残留映射导致文件被锁定（尤其 Windows）
真正影响性能的关键点往往不在 mmap 本身，而在你是否理解它只是内存与文件的“视图同步机制”——它不改变 I/O 本质，只换了一种同步方式。页错误、写时复制、缓存策略这些底层行为，比函数调用本身更值得花时间观察。
