list不支持元素级运算是因其内存不连续、存储对象引用；array.array虽更紧凑但也不支持+等运算符重载，仅支持拼接；真需向量化运算应选NumPy。
list 不支持元素级运算是因为它的设计目标是通用容器：每个元素可以是任意类型、任意大小的对象，存储的是对象引用而非原始值，内存不连续，也没有统一的数据布局。这导致无法像 C 数组那样用指针偏移+固定步长做批量计算。
真正能做元素级运算的，是 array.array ——但它本身也不支持 +、* 这类运算符重载。很多人误以为“用了 array 就能直接加减”，其实不然。关键在「为什么不用 NumPy」和「什么时候真该用 array」。
为什么 array.array 不能直接做 a + b
因为 array.array 的 __add__ 方法只实现拼接（类似 list.__add__），不是逐元素相加：
import array
a = array.array('i', [1, 2, 3])
b = array.array('i', [4, 5, 6])
print(a + b) # array('i', [1, 2, 3, 4, 5, 6]) —— 拼接，不是 [5,7,9]
- 它没有内置广播、对齐或类型提升逻辑
- 所有操作都基于 C 层原始内存拷贝，不引入解释器层的数值语义
- 连
a * 2都只是重复整个数组，不是每个元素乘 2
什么场景下 array.array 真正比 list 更“密”
密度优势只在满足以下全部条件时才成立：
- 元素全是同一种基本数值类型（如全
int或全float） - 数据量较大（通常 > 10⁴ 项），且频繁做 I/O（比如写入二进制文件、socket 发送）
- 不需要动态类型混合、不依赖
list的丰富方法（如.sort(key=...)） - 你手动控制类型码：用
'i'而不是'l'可省一半内存（32 位 vs 64 位整数）
例如存 10 万个 16 位整数：array.array('h', data) 占 200KB；而 list 至少占 800KB（64 位系统上每个 int 对象约 28 字节 + 引用开销）。
如何用 array.array 实现真正的元素级运算
必须手动遍历或配合 map / 列表推导式，但要注意类型一致性：
import array
a = array.array('f', [1.0, 2.0, 3.0])
b = array.array('f', [4.0, 5.0, 6.0])
# 正确：转成 list 做运算再塞回去（小数据可接受）
result = array.array('f', [x + y for x, y in zip(a, b)])
<h1>更省内存：用 memoryview（Python 3.3+）避免中间 list</h1><p>mv_a, mv_b = memoryview(a), memoryview(b)
result = array.array('f', (x + y for x, y in zip(mv_a, mv_b)))
- 不能混用类型码：
array('i', [...]) + array('f', [...])会报TypeError -
memoryview对array是零拷贝视图，但仅支持一维、同类型、C 连续布局 - 若需频繁运算，不如直接上
numpy.array—— 它的+是真向量化，且自动处理 dtype 对齐
容易被忽略的兼容性陷阱
array.array 看似轻量，但几个边界行为常踩坑：
- 字符串初始化只对
'u'类型码有效：array.array('u', 'hello')✅；用'i'传字符串会报TypeError: expected integer, got str -
array不支持负步长切片赋值：a[::−1] = [...]报ValueError - 从
bytes构建时，字节长度必须整除类型码字节数：array.array('i', b'\x01\x00\x00\x00')✅（4 字节）；b'\x01\x00'❌（2 字节 ≠ 4） -
array的.tofile()写出的是裸二进制，无长度头、无类型信息，读取端必须严格知道 typecode 和长度
真正要提升“密度”又需要运算能力，array.array 只是过渡方案。它的价值不在运算，而在与 C API、二进制协议、嵌入式数据流的无缝对接——这点常被教程忽略。
