90%的内存暴涨源于隐式复制，如误用np.repeat、切片赋值形状不匹配、np.concatenate拼接或多进程传递大实例；应优先用广播替代repeat、预分配目标数组并切片赋值、多进程改用memmap按需加载。
直接说结论：90% 的内存暴涨不是因为数组太大，而是因为无意中触发了隐式复制——比如用 np.repeat、切片赋值不匹配形状、np.concatenate 拼接、或在多进程里传整个类实例。真正要防的，是“本可避免的物化”。
np.repeat 用错就等于主动申请新内存
很多人写 np.repeat(arr[:, None], repeats=100, axis=1) 只为把 (N,) 扩成 (N, 100)，却没意识到这会立刻分配一块 N×100 大小的新缓冲区。尤其当 arr 是千万级时，一次 repeat 就可能吃掉几 GB。
- ✅ 正确做法：用广播替代 repeat ——
target_array[:] = arr[:, None]（前提是 target_array 已预分配好且 shape 兼容） - ✅ 进阶只读场景：用
np.broadcast_to(arr[:, None], (len(arr), 100))，返回的是视图，零拷贝 - ⚠️ 注意：
np.broadcast_to返回只读对象，不能直接赋值；若需写入，请确保目标数组已存在且可写 - ❌ 别信“我只取了一行”，只要表达式里出现
np.repeat或np.tile，就代表 NumPy 正在 malloc 新内存
多进程里传大数组 = 每个子进程各扛一份
用 multiprocessing.Pool.map() 调一个带 self.data（比如 2GB 的 np.ndarray）的类方法？那 4 个 worker 就会各自反序列化出一份 2GB 数组，瞬间吃掉 8GB+ 内存，哪怕你每次只读一个标量。
- ✅ 正确做法：改用
concurrent.futures.ProcessPoolExecutor，配合流式提交——把任务拆成索引范围，只传start, end和文件路径，让每个子进程自己用np.memmap或np.load(..., mmap_mode='r')按需加载 - ✅ 更稳方案：把大数组提前存成磁盘文件，子进程中用
np.memmap(filename, dtype=..., shape=..., mode='r')映射，不占额外 RAM - ⚠️ 注意：
multiprocessing.Pool的maxtasksperchild不解决根本问题；它只控制 worker 复用，不减少初始数据拷贝
切片赋值时形状对不上，NumPy 会偷偷 copy
写 dst[100:200] = src[50:150] 看似安全，但如果 dst.strides 和 src.strides 不兼容（比如一个是 C-order，一个是 F-order），或者 dst 是 view（如 a.T），NumPy 可能放弃原地写入，转而创建临时副本再赋值。
- ✅ 检查是否真在原地写：执行后打印
dst.data.ptr == original_dst.data.ptr（需用__array_interface__或ctypes.data对比地址） - ✅ 强制连续内存：写之前加
dst = np.ascontiguousarray(dst)，但代价是可能触发一次复制——所以更推荐初始化时就用np.empty(..., order='C') - ⚠️ 常见坑：
arr[::-1]是 view，但arr[::2]在某些旧版本里可能不是；不确定时用np.may_share_memory(arr, view)辅助判断
最易被忽略的一点：内存暴涨往往发生在“看起来什么都没干”的地方——比如调用某个封装函数后突然卡住、top 里 RSS 暴增。这时候别急着加 swap，先查它内部有没有 np.concatenate、np.stack 或未设 out= 参数的 ufunc 调用。这些地方不打日志，也不报错，但每调一次都在后台 malloc 一块新内存。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
