np.append 每次都创建新数组，不是原地修改：它始终分配新内存、拷贝旧数据与新数据后返回新数组，时间复杂度为 O(n)，循环调用 k 次总代价达 O(k²)，应避免在循环中使用，推荐预分配或一次性转 array。
np.append 每次都创建新数组，不是原地修改
np.append 从不修改原数组，而是每次调用都分配一块全新内存、拷贝旧数据 + 新数据，再返回新数组。这意味着：一次 np.append(arr, x) 的时间复杂度是 O(n)，如果在循环里调用 k 次，总代价就是 O(n + (n+1) + (n+2) + ... + (n+k)) ≈ O(k²) —— 典型的“二次方膨胀”。
常见错误现象：for i in range(10000): result = np.append(result, i) 跑到几千次就开始明显卡顿，内存占用飙升。
- 它底层调用
np.concatenate，而后者必须保证输入数组内存连续且类型一致，因此还会触发隐式np.ascontiguousarray和类型转换 - 即使
result是float64，追加一个int也可能导致整个数组升为float64并重拷贝 - 无法复用已有缓冲区，
.resize()或list.append()都比它更省内存
替代方案：预分配 + 索引赋值（最稳）
如果你能预估最终长度（比如读取固定行数的文件、已知循环次数），直接用 np.zeros 或 np.empty 分配好目标数组，用索引写入：
size = 10000
result = np.empty(size, dtype=np.float64)
for i in range(size):
result[i] = some_computation(i)这种写法没有副本、无类型推断开销、CPU缓存友好。性能通常是 np.append 循环的 100 倍以上。
立即学习“Python免费学习笔记（深入）”；
- 用
np.empty而非np.zeros，避免初始化零的额外开销（只要确保每个位置都会被写入） - 如果 dtype 不确定，先用 Python
list收集，最后一次性转np.array(my_list)—— 这比反复np.append快得多 - 避免在循环中调用
result.shape[0]查长度，改用计数器变量，减少属性访问
广播和向量化操作根本不需要 append
很多你以为“必须边算边加”的场景，其实完全可以用向量化一次生成：
比如想把多个计算结果拼成一维数组：[f(x) for x in inputs] → 直接 f(np.array(inputs))，只要 f 支持 NumPy 数组输入（如 np.sin, np.exp, 自定义 np.vectorize 包装函数）。
- 不要写
for x in arr: res = np.append(res, x**2)，直接res = arr ** 2 - 需要条件拼接？用布尔索引：
large_vals = arr[arr > threshold]，不是一个个append - 多维堆叠？用
np.vstack/np.hstack/np.stack，它们内部优化了内存布局，比链式np.append可靠得多
为什么 np.append 看起来“方便”却最危险
它名字带 append，让人误以为像 Python list.append() 那样轻量，但语义完全不同：list.append() 是 O(1) 均摊，而 np.append() 是 O(n) 实打实。
- 调试时容易忽略——
print(result.shape)看不出问题，但arr.flags.owndata会显示每次都是新所有权 - 在 Jupyter 中小数据试跑没问题，一上生产环境数据量翻十倍，耗时直接从 0.1s 涨到 10s+
- 它不报错、不警告，只是悄悄拖慢你整个 pipeline，尤其嵌在多重循环或 IO 后处理里时最难定位
真正要注意的，从来不是“怎么让 np.append 更快”，而是“哪段逻辑本就不该用它”。
