np.sum(arr > 0) 能统计正数个数，因布尔数组中 True 视为 1、False 为 0，求和即计数；但需注意 dtype、NaN、浮点误差及高维 axis 控制，语义上 np.count_nonzero 更清晰。
为什么 np.sum(arr > 0) 能统计个数
因为 arr > 0 返回的是布尔数组，而 NumPy 中 True 当作 1、False 当作 0 参与数值运算。np.sum() 对这个布尔数组求和，本质就是把所有 True 加起来，结果就是满足条件的元素个数。
这比写循环或用 np.count_nonzero() 更简洁，但要注意：它依赖隐式类型转换，不是所有上下文都这么“宽容”。
- 只适用于一维或能自然广播的多维场景；高维时默认对全部元素求和，容易误判维度
- 如果
arr是 object 类型数组，arr > 0可能报TypeError: '>' not supported between instances of 'str' and 'int' - 浮点数比较时，
> 0不等于!= 0，负零、NaN 都会被排除，这点常被忽略
np.count_nonzero() 和 np.sum() 选哪个
功能完全等价，但语义和行为有细微差别：np.count_nonzero() 明确表达“计数”意图，且在多维时默认不降维，更可控。
np.sum() 更通用，但容易在高维数组中意外展平——比如二维数组 arr.shape == (3, 4)，np.sum(arr > 0) 返回标量，而 np.count_nonzero(arr > 0, axis=0) 可按列统计。
- 想统计整个数组符合条件总数 → 两个都行，
np.sum()打字少一点 - 需要按某轴统计（如每行正数个数）→ 必须用
np.count_nonzero(arr > 0, axis=1)，np.sum()虽然也能加axis参数，但语义模糊 - 数组含 NaN →
arr > 0对 NaN 返回False，两者结果一致；但若用np.isnan(arr)做条件，就别混用np.sum()，易读性差
常见错误：条件写错导致全 False 或全 True
最典型的是拿字符串数组跟数字比较，或者用 == 判等时没考虑浮点误差。例如：
arr = np.array(['1', '2', '3']) np.sum(arr > '0') # ✅ 字符串比较合法，但逻辑可能不是你想要的 np.sum(arr > 0) # ❌ TypeError: '>' not supported between instances of 'str' and 'int'
另一个坑是忘记括号优先级：np.sum(arr > 0 & arr 会报错，因为 <code>& 优先级高于 > 和 ，实际解析为 <code>arr > (0 & arr) ，必须写成 <code>np.sum((arr > 0) & (arr 。
- 复合条件务必给每个比较表达式加括号，
&|~不接受链式写法 - 用
np.where()调试时，先跑arr > 0看输出是不是预期的布尔数组 - 整数除法或 dtype 为
uint8时，arr - 10 可能因溢出全为 <code>True，建议先转int64
性能差异真的存在吗
在绝大多数场景下，np.count_nonzero() 和 np.sum() 性能几乎一样，底层都走高度优化的 C 循环。真正影响速度的是布尔索引本身，而不是求和函数。
但有一个例外：当数组极大且稀疏（比如亿级元素中只有几十个 True），np.count_nonzero() 内部做了短路优化（实际未公开文档），而 np.sum() 一定遍历全部——不过这种差异通常不到 10%，远不如换用 numba 或改用稀疏结构来得实在。
- 别为这点差异提前优化，先确保逻辑正确
- 如果真卡在统计这步，检查是不是在重复计算同一条件，比如在循环里反复写
np.sum(arr > threshold)，应把布尔数组缓存出来 -
dtype影响更大：用bool数组比用int8稍快，但 NumPy 自动做对了，不用手动转
布尔数组求和这事看着简单，但一旦嵌进复杂条件、混合 dtype、再配上 axis 参数，很容易产出“结果对但不知道为啥对”的代码。最稳妥的做法是：先用 print((arr > 0).dtype, (arr > 0).shape) 确认中间态，再决定用 sum 还是 count_nonzero。
