np.float64算错是因IEEE 754双精度无法精确表示0.1等十进制小数，属二进制固有限制；np.float128仅在Linux/macOS+GCC下提升精度，Windows多无效；Decimal+object数组可精确但丧失向量化；工程中宜用np.allclose、高精度累加、字符串预读等策略平衡精度与性能。
为什么 np.float64 依然会算错？
不是 NumPy 不够准，而是底层用的 IEEE 754 双精度浮点数——它根本存不了 0.1 这种十进制小数。比如 0.1 + 0.2 == 0.3 返回 False，这不是 bug，是二进制表示的天然限制。NumPy 默认所有浮点数组都是 np.float64，所以照样踩坑。
什么时候该换 np.float128？
np.float128 在支持扩展精度的平台（Linux/macOS + GCC）上能提供约 34 位十进制精度，比 float64 多一倍，适合中间计算高敏感场景，比如数值积分、条件数大的矩阵求逆。
但要注意：
- Windows 上多数 Python 发行版（包括 Anaconda）的
np.float128实际就是float64，没提升 - 它不兼容 pickle 序列化，保存数组可能失败
- 部分 ufunc（如
np.log）在float128上可能回退到float64计算，结果反而“降级” - 声明方式必须显式：
np.array([0.1, 0.2], dtype=np.float128)，不能靠自动推断
更靠谱的替代方案：用 decimal + NumPy 手动桥接
如果业务逻辑本质是“钱、计量、配置值”这类必须精确十进制的场景，别硬扛浮点——改用 Python 原生 decimal.Decimal，再套一层 NumPy 数组包装。
立即学习“Python免费学习笔记（深入）”；
示例做法：
from decimal import Decimal
import numpy as np
<h1>构造精确十进制数组（注意：dtype=object）</h1><p>arr = np.array([Decimal('0.1'), Decimal('0.2'), Decimal('0.3')], dtype=object)
result = arr[0] + arr[1] # Decimal('0.3')
print(result == Decimal('0.3')) # True
缺点也很明显：
- 失去向量化运算能力：
arr + arr会触发 Python 原生循环，慢一个数量级 - 不能直接传给 SciPy 函数（比如
scipy.linalg.eig），会报TypeError: no supported conversion - 内存占用翻倍以上，
dtype=object存的是指针，不是紧凑数值
真正实用的工程策略：容忍 + 校验
90% 的科学计算不需要“绝对精确”，需要的是“可控误差”。NumPy 提供了现成工具：
- 比较用
np.allclose(a, b, atol=1e-10)，别用== - 求和累积误差大时，改用
np.sum(arr, dtype=np.float128)指定高精度累加器（即使平台不支持float128，也会 fallback 到float64安全执行） - 读取 CSV 或 JSON 里的小数时，先用
pd.read_csv(..., dtype=str)读成字符串，再转Decimal，避免 float 解析阶段就失真 - 调试时用
np.set_printoptions(precision=17)看清真实值，而不是被默认 8 位截断误导
精度问题从来不是“能不能解决”，而是“在哪一层解决最省事”。盲目升 dtype 或强切 Decimal，往往让代码更难维护、更慢、更脆。
