np.memmap报OSError常见原因是路径不存在、权限不足或文件被独占锁定；它严格按OS层面打开文件，不自动创建目录或覆盖只读文件，且dtype与shape必须与原始二进制布局完全一致。
memmap 读取大文件时为什么报 OSError: Unable to open file
常见原因是路径不存在、权限不足，或文件被其他进程独占锁定。NumPy 的 np.memmap 不会自动创建父目录，也不会覆盖只读文件——它严格按 OS 层面打开文件，出错直接抛原生 OSError。
实操建议：
- 先用
os.path.exists()和os.access(path, os.R_OK)检查路径与可读性 - 若文件需写入，确保磁盘空间充足且路径所在分区支持 mmap（如某些 NFS 或 FAT32 卷不支持）
- Windows 下注意防病毒软件可能劫持文件句柄，临时禁用实时扫描可快速验证是否为此类干扰
dtype 和 shape 参数必须和原始二进制布局严格一致
np.memmap 不解析文件头，它把文件当作裸字节流按指定 dtype 和 shape 直接映射。哪怕只是 dtype='float32' 写成 'float64'，读出来的数值就全错，且不会报错。
使用场景：你手头只有文件路径，但不确定原始保存参数？
立即学习“Python免费学习笔记（深入）”；
- 用
hexdump -C file.dat | head -n 4查看前几字节，结合已知数据范围反推 dtype（如 0x0000003f 很可能是 float32 的 1.0） - 若由你自己写入，务必记录元信息到同目录的
meta.json，内容类似：{"dtype": "float32", "shape": [1000000, 784]} - shape 的总元素数 × dtype.itemsize 必须等于文件字节长度，否则触发
ValueError: size mismatch
mode='r' 和 mode='c' 的实际区别不只是“是否可写”
mode='r' 是只读映射，任何写操作（包括 a[0] = 1）都会抛 TypeError；mode='c'（copy-on-write）看似安全，但容易被忽略的是：它只对当前 Python 进程生效，且修改不会落盘——其他进程或下次重启后读不到变更。
性能与兼容性影响：
- Linux 下
mode='r+'最常用：既允许原地修改又保证落盘，但要求文件有写权限 - Windows 对
mode='r+'支持较弱，尤其在文件被其他程序打开时易报PermissionError，此时优先试mode='c'+ 显式flush() - 所有模式下，调用
del arr或让变量超出作用域后，底层 mmap 会自动释放，无需手动 close
用 memmap 做分块计算时别直接切片整个数组
像 data[1000000:2000000] 看似只取一部分，但 NumPy 仍会为整个映射区域分配虚拟内存地址空间（即使没访问）。在 100GB 文件上这么做，可能触发系统 OOM Killer 杀死进程。
正确做法是控制每次映射的粒度：
- 按需构造小段 memmap：例如每次处理 10MB 数据，用
offset=10*1024**2 * i和shape=(n_rows_per_chunk, n_cols)显式限定范围 - 避免链式索引：
data[::1000][::100]会先生成完整步长视图再切片，应改用np.s_或直接算偏移 - 如果只是统计（如求均值），用
np.memmap(..., mode='r').sum()是安全的，因为 sum 内部做了分块迭代，不会加载全量
最易被忽略的一点：memmap 对象本身不校验数据一致性——文件被外部程序中途截断或覆盖，Python 进程里可能继续读到脏数据或 segfault，生产环境务必加文件大小守卫和定期 stat 校验。
