np.memmap能避免内存爆炸，因为它通过操作系统分页机制按需读取磁盘块，不将整个数组加载进ram；初始化需严格指定filename、dtype、mode及shape，否则易因字节对不上或类型错配导致错误。
为什么 np.memmap 能避免内存爆炸
因为 NumPy 默认把整个数组加载进 RAM，而 np.memmap 只在访问时按需读取磁盘块——本质是让操作系统帮你做分页管理。它不复制数据，也不强制转成内存数组，所以 10GB 的 .npy 文件打开几乎不占内存，但首次索引某行可能稍慢（触发磁盘 IO）。
适用场景：你有单个大文件（比如 data.npy 或裸二进制）、需要随机读写部分切片、且机器 RAM 明显小于数据体积。
- 必须提前知道 dtype 和 shape，否则无法映射；
np.memmap不解析文件头，它只信你给的参数 - 文件路径必须真实存在（读模式）或可写（写/读写模式），不存在时不会自动创建目录
- 如果原始数据是
float64但你错设为float32，读出来的值全错，且无警告
np.memmap 初始化时必填的三个参数
filename、dtype、mode 缺一不可，shape 在读模式下也得给（除非用 offset + 手动算字节长度）。别指望靠 np.load 那套自动推导逻辑。
常见错误现象：ValueError: buffer size does not match array size——基本就是 shape × dtype.itemsize 算出来和文件实际字节数对不上。
-
mode='r'：只读，最安全；'c'（copy-on-write）适合多进程读+局部修改，但改完不主动flush()不会落盘 -
dtype=np.float32必须和原始数据一致；不确定时用np.fromfile(filename, dtype=np.uint8).nbytes先看总字节数再反推 -
shape=(1000000, 200)这种大维度要小心：NumPy 内部仍按 C-order 展开，切片[i, :]是连续内存，[:, j]是跨步访问，速度差几倍
用 np.memmap 替换 np.load 的实操步骤
不是简单改函数名，关键在“把磁盘当内存用”的思维切换：你不能再依赖 .shape 之后立刻做广播运算，因为那会触发全量加载。
假设你原来写 arr = np.load('big.npy'); result = arr * 2，现在得改成逐块处理：
mm = np.memmap('big.npy', dtype=np.float32, mode='r', shape=(1000000, 200))
result = np.empty(mm.shape, dtype=mm.dtype)
for i in range(0, mm.shape[0], 1000): # 每次读 1000 行
chunk = mm[i:i+1000] # 触发实际读取
result[i:i+1000] = chunk * 2
- 别直接对
mm调用np.mean(mm)，它会试图把整个映射区载入内存求均值 - 写入要用
mode='r+'或'w+'，且确保文件已存在并有足够空间；'w+'会清空原文件 - 多进程共享同一
np.memmap对象没问题（OS 层面支持），但别让多个进程同时写同一区域，没锁机制
比 np.memmap 更省心的替代方案
如果你的数据是列存格式（比如 HDF5、Parquet）、或者需要压缩/元数据/并发查询，np.memmap 就太裸了。这时候该换工具，而不是硬调参。
例如用 h5py 读 HDF5：f['dataset'][1000:2000] 同样惰性加载，还自带压缩、chunking、属性描述；pyarrow.parquet.read_table 支持按列过滤，跳过无关字段。
-
np.memmap不支持压缩，文件必须是纯二进制；想减体积得先解压到临时文件再映射 - Windows 上大文件（>2GB）用
np.memmap可能遇到 mmap 失败，报OSError: [Errno 22] Invalid argument，此时换mmap.mmap底层 API 更可控 - 调试时别用
print(mm)——它会试图显示前几行+后几行，导致意外加载大量数据
真正麻烦的从来不是怎么映射，而是你怎么确认磁盘布局和代码里的 dtype/shape 完全对得上。一个字节偏移错了，后面全乱。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
