处理大规模数组需避免全量复制，应采用写时复制、内存映射、分块视图、零拷贝引用及生成器流式处理等机制，以降低内存占用与延迟。
处理大规模数组时，内存限制不是靠“加大内存”就能解决的，关键在于避免全量复制、减少中间副本、让数据按需加载或共享。真正有效的方案，往往不依赖一次性的深拷贝，而是结合写时复制、内存映射、分块视图或零拷贝引用等机制。
优先用共享与延迟复制，而非立即深拷贝
对读多写少、局部更新频繁的结构（如用户列表中仅修改个别 profile 字段），直接深拷贝整个数组会浪费大量内存和时间。按需拷贝（Lazy Clone）就是为此设计：初始所有副本共享同一份只读内存；只有当某次写操作触及具体索引或子数组时，才为该区域分配新内存并复制——其余部分仍复用原始数据。它要求配合不可变语义使用，禁止绕过封装直接修改原始引用。
- 适合含嵌套对象的数组，例如
[{id:1,profile:{name:'A'}}, {id:2,profile:{name:'B'}}] - 不适合需要全局快照一致性的场景（如事务回滚）
- 本质是写时复制（Copy-on-Write），不是语法糖，需底层支持
用内存映射绕过内存加载瓶颈
当数组大到远超物理内存（比如 50GB 的 float32 数据），连“加载”都成问题。NumPy 的 memmap 或 MATLAB 的 tall 数组能将磁盘文件直接映射为数组接口，访问某行某列时才从磁盘读取对应页——不占内存，也不触发完整加载。计算均值、过滤、聚合等操作可分块执行，每块独立加载、处理、释放。
-
np.memmap(filename, dtype='float32', mode='r', shape=(1e7, 1000))创建一个逻辑上巨大的数组，实际只驻留当前访问块 - 写入需用
'r+'模式，并注意同步落盘 - 比
np.load()节省 90%+ 内存，但随机访问延迟略高
系统级高效搬运：arraycopy 与 TypedArray 视图
当必须复制时，别用 for 循环或 Arrays.copyOf。Java 的 System.arraycopy 是 JVM 内置本地调用，绕过字节码循环和边界检查；JS 中 new Uint8Array(buffer, offset, length) 是基于 ArrayBuffer 的零拷贝视图——两者都不分配新内存，只建立引用或地址偏移。
-
arraycopy前必须确保目标数组已存在且容量充足，类型严格匹配（int[] → int[]），小数组（≤256 元素）反而不如循环 - TypedArray 零拷贝成立的前提是
buffer来自高效源头（如fetch().arrayBuffer()），手动new ArrayBuffer()后填充仍可能触发 GC - 重叠复制（如 RingBuffer 前移）由 JVM/引擎自动保序，无需手动倒序
用生成器或流式结构规避数组构建
很多“大数组”其实没必要真构造出来。PHP 的 yield、Python 的生成器、甚至 SQL 的游标式遍历，都能把“数组”变成一个持续产出的迭代过程。每次只 hold 一条记录或一个批次，处理完即丢弃，彻底避开内存峰值。
- 读 CSV 时不用
file_get_contents+explode，改用SplFileObject迭代逐行 - 数据库查询避免
fetchAll()，改用fetch循环或游标 fetch - 合并多个大数据源时，用生成器 yield 每个源的 chunk，而非
array_merge全量拼接
