np.array() 会 OOM 是因为它必须将整个输入（如百万行列表或生成器展开后的字符串）一次性载入内存并拷贝转换；应改用 np.empty()+分块填充、np.fromiter() 或 np.memmap()/Dask。
为什么直接用 np.array() 加载大文件会 OOM
因为 np.array() 必须把整个输入对象（比如一个含百万行的列表）一次性加载进内存，再逐个元素拷贝、类型转换、分配连续内存块。哪怕源数据是生成器，它也会先调用 list(generator) 强制展开——这一步就足以让 10GB 文本在 Python 层膨胀出 20GB+ 的字符串对象，再叠加上 NumPy 的副本开销，OOM 几乎必然发生。
常见错误现象：MemoryError 报在 np.array(...) 调用处；系统开始疯狂 swap；任务管理器里 Python 进程内存占用飙升后卡死。
- 根本原因不是 NumPy 慢，而是你让它“扛着整座山走路”
-
copy=True（默认）会让已有 ndarray 再复制一份，双倍吃内存 - 若原始数据含不规则结构（如每行字段数不同），
np.array()还会退化为object类型数组，内存效率更差
用 np.empty() + 分块填充替代全量 np.array()
核心思路：预分配目标形状的空数组，再用循环/迭代器分批读取、解析、写入指定切片。内存峰值只取决于单块大小，而非全量数据。
适用场景：已知最终数组形状（如 CSV 行数可预估、图像批量尺寸固定）、数据格式规整。
立即学习“Python免费学习笔记（深入）”；
- 先用轻量方式估算行数（例如
sum(1 for _ in open("data.csv"))，但注意别用len(list(...))） - 调用
np.empty((n_rows, n_cols), dtype=np.float32)——float32比float64省一半内存 - 用
csv.reader或line.split()逐行解析，转成数值后写入arr[i, :] = parsed_row - 避免在循环内反复调用
np.append()或np.vstack()，它们每次都会新建数组
用生成器函数封装数据流，配合 np.fromiter() 构建一维数组
np.fromiter() 是少数真正支持生成器的 NumPy 函数，但它只接受一维可迭代对象，且要求明确指定 count 和 dtype。适合构建特征向量、标签序列等线性结构。
关键限制：不能直接生成二维数组；count 必须已知，否则得先遍历一遍计数（可用 itertools.tee 拆成两路）。
- 示例：从日志文件提取时间戳数值序列
def timestamp_gen(filename):<br> for line in open(filename):<br> ts = parse_timestamp(line)<br> yield ts<br>timestamps = np.fromiter(timestamp_gen("log.txt"), dtype=np.int64, count=1000000) - 若 dtype 推断不准（如混合整数/浮点），显式指定比依赖自动推导更稳
- 不要传入未设
count的无限生成器，否则np.fromiter()会一直跑直到内存耗尽
何时该放弃 NumPy 数组，改用内存映射或 Dask
当数据规模远超物理内存（比如 >80% RAM），且需随机访问或复杂切片时，硬扛 NumPy 初始化已无意义——此时预分配本身就会失败。
两个务实选择：
-
np.memmap()：创建指向磁盘文件的“伪数组”，读写操作自动触发页加载，适合固定格式、重复访问的 TB 级科学数据arr = np.memmap("data.dat", dtype="float32", mode="r", shape=(1000000, 1000)) - Dask Array：延迟计算 + 自动分块，语法近似 NumPy，但所有操作都不真正执行，直到调用
.compute()
适合需要 map-reduce 风格处理、或要和 Pandas/Delayed 混合调度的流程
最容易被忽略的一点：生成器解决的是“加载阶段”的内存压力，但若后续计算（如 arr @ arr.T）本身需要全量驻留内存，OOM 只是推迟发生——必须同步审视整个 pipeline 的中间态规模。
