传-1作fd导致卡住，因mmap只接受文件描述符而非路径；须先open获取fileno，注意fd生命周期和flush同步，映射大小按页对齐，适用场景为随机访问而非顺序读。
用 mmap 读超大文件时为什么卡在 mmap.mmap(-1, ...)？
因为传了 -1 作为文件描述符（fd），但没先用 os.open() 或 open().fileno() 打开文件。Python 的 mmap.mmap() 不接受路径字符串，只认 fd —— 这是初学者最常卡住的地方。
正确做法是：先以二进制模式打开文件，拿到 fileno()，再传给 mmap。注意不能用 with open(...) as f: 后直接 f.fileno() 然后退出作用域，否则 fd 可能被回收（尤其 Windows 上）。
-
fd = os.open("huge.bin", os.O_RDWR)，之后记得os.close(fd) - 或
f = open("huge.bin", "r+b"); mm = mmap.mmap(f.fileno(), 0); f.close()—— 关闭f不影响mm，但别关早了（比如在mmap()前就f.close()） - Linux/macOS 上可设
access=mmap.ACCESS_READ提升只读场景安全性；Windows 上必须匹配打开模式（r+b对应ACCESS_WRITE）
mmap 写入后内容没落盘？
mmap 默认是“延迟写回”，修改内存区域不会立刻刷到磁盘，靠操作系统调度。你改完就退出程序，很可能数据丢了。
- 调用
mm.flush()强制同步：它等价于msync()，确保变更写入文件 - 若需每次写都落盘，加
flags=mmap.MAP_SYNC（仅 Linux 4.15+ 支持，且文件系统需支持 DAX） - 更稳妥的做法是：写完
mm.flush()，再os.fsync(fd)—— 防止内核页缓存还没提交到块设备 - 注意
mm.close()不触发 flush，必须显式调用
处理非整数倍页面大小的文件，len(mm) 和实际文件长度不一致？
因为 mmap 映射区域按系统页对齐（通常是 4KB），如果文件长度不是页大小整数倍，mmap 会把末尾补零映射进来。读取超出原文件长度的位置不会报错，但写入会触发 SIGBUS（Unix）或 AccessViolation（Windows）。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
- 用
os.path.getsize("file")获取真实长度，别依赖len(mm) - 写入前检查索引：
if pos >= real_size: raise ValueError("write beyond file") - 想安全扩展文件，先
os.ftruncate(fd, new_size)，再mm.resize(new_size)（注意resize()不保证跨平台，Windows 不支持）
用 mmap 替代 read() 真的更快吗？
只在特定场景快：随机访问大文件、频繁小范围读写、多进程共享同一文件。顺序读整个文件？反而可能更慢——少了 read-ahead 优化，还多了页表管理开销。
- 纯顺序扫描：老实用
for line in f:或f.read(8192)分块读，mmap没优势 - 需要跳转查找（如解析日志中某时间戳段）：
mmap+ 二分搜索比反复seek()快得多 - 多进程同时读同一文件：
mmap.ACCESS_READ共享物理页，省内存；写则需加锁或用mmap.ACCESS_COPY（写时复制） - 注意：32 位 Python 无法 mmap 超过 2GB 文件；64 位下也建议单次映射不超过几 GB，避免虚拟地址空间碎片
真正难的不是调用 mmap，而是判断该不该用、用在哪一段、怎么和文件生命周期配合。映射后忘了 flush，或者映射时没控好 fd 生命周期，比不用还危险。
