直接结论：不靠加内存，靠控制dtype、避免隐式拷贝、用np.memmap替代全量加载、拆分原地运算——这些操作在Python3.11下依然有效，且更易暴露真实内存问题。
直接结论：不靠加内存，靠控制 dtype、避免隐式拷贝、用 np.memmap 替代全量加载、拆分原地运算——这些操作在 Python 3.11 下依然有效，且更易暴露真实内存问题。
选对 dtype 能省下一半以上内存
NumPy 数组内存 = size × itemsize，而 itemsize 完全由 dtype 决定。float64 占 8 字节，float32 只占 4 字节；100 万元素数组从 float64 切到 float32，就少占 4MB。
- 图像/音频预处理优先用
np.uint8或np.int16，别用默认float64 - 机器学习特征工程中，若原始数据是整数且范围 ≤ 255，强制指定
dtype=np.uint8 - 训练时
float32足够，除非你明确需要双精度（如某些数值稳定性敏感场景） - 创建时就指定类型：
np.array(data, dtype=np.float32)，而不是先创建再.astype()——后者会多一个临时副本
np.memmap 是处理超大数组的底线方案
当你有单个大文件（比如 data.npy 或裸二进制），RAM 明显小于数据体积，又需要随机读写部分切片时，np.memmap 是最稳妥的选择。它不把整个数组加载进 RAM，只在访问时按需读取磁盘块。
- 初始化必须填全
filename、dtype、mode和shape；缺一不可，也不能靠“自动推导” - 常见报错
ValueError: buffer size does not match array size，基本就是shape × dtype.itemsize和文件实际字节数对不上 - 模式选
'r'最安全；'r+'支持修改但要小心 flush；'w+'会清空原文件 - 别直接拿
np.memmap对象做广播运算（如arr * 2），那可能触发全量加载；应改用分块处理
切片和索引何时悄悄拷贝内存？
多数切片返回的是视图（view），共享底层内存；但布尔索引、花式索引（fancy indexing）、跨步太大或非连续访问，会触发隐式拷贝。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
- 检查是否为视图：
arr[::2].base is arr返回True表示是视图；False很可能已拷贝 - 用
np.where()替代纯布尔索引做条件提取，可减少意外拷贝 - 如果不想影响原始数组，必须显式调用
.copy()，别依赖“看起来像新数组” - 修改视图会同步改原数组——这点容易被忽略，尤其在 pipeline 中多次切片后传参
原地运算（inplace）为什么能省几倍内存？
a += b、a /= 2 这类操作不产生中间数组；而 a = a + b 或 a = (a - a.mean()) / a.std() 会在计算过程中生成多个临时数组，循环里极易堆积。
- 归一化推荐写法：
a -= a.mean()然后a /= a.std()，比一行公式少至少一个临时数组 - 函数带
out=参数才能真正原地写入，例如np.clip(a, 0, 1, out=a) - 广播本身不拷贝，但如果目标数组形状不匹配，仍可能触发隐式扩容——确保
shape对齐再运算
最容易被忽略的一点：Python 3.11 并没改变引用计数逻辑，但 sys.getsizeof() 和 psutil.Process().memory_info().rss 报告更准了。你删了变量但内存没降，往往不是 GC 没运行，而是还有其他变量引用着同一块内存，或者 .base 仍在 hold 住原始缓冲区。
