FloatingPointError 很少直接由普通计算触发，因为它默认禁用，仅在启用浮点异常信号且发生除零、溢出等严重异常时抛出；日常精度误差源于 float 二进制表示局限，非该异常。
为什么 FloatingPointError 很少直接由普通计算触发
FloatingPointError 默认是禁用的，Python 不会在 0.1 + 0.2 ≠ 0.3 这类精度误差时抛出它。它只在浮点运算发生**严重异常**（如除零、溢出、无效操作）且 float_error 信号被显式启用时才出现。多数人遇到的“计算不准”，其实是 float 本身的二进制表示局限，不是 FloatingPointError。
所以第一步不是捕获异常，而是确认你真正需要的是：高精度十进制计算（比如财务、科学测量），还是单纯想避免显示误差（比如格式化输出）。
- 若只需显示美观：
f"{x:.2f}"或round(x, 2)就够了，别动decimal - 若需中间计算全程无累积误差（例如累加 0.01 一百次），才该切到
decimal - 启用
FloatingPointError（通过signal.signal(signal.SIGFPE, ...)或numpy.seterr）属于调试/风控场景，生产环境慎用
用 decimal.Decimal 替代 float 的三个关键动作
直接写 Decimal(0.1) 是错的——它先把 0.1 当作 float 解析，误差已产生。必须从字符串或整数初始化。
- ✅ 正确初始化：
Decimal("0.1")、Decimal(1) / Decimal(10) - ❌ 错误初始化：
Decimal(0.1)（此时 0.1 已是近似值） - 设置全局精度（非默认）：
getcontext().prec = 28（影响所有后续运算，不是单个值的位数） - 算术运算符（
+,-,*,/）可直接用于Decimal，但**、math.sqrt()等需用Decimal.sqrt()等对应方法
示例：
立即学习“Python免费学习笔记（深入）”；
from decimal import Decimal, getcontext
getcontext().prec = 6 # 总有效数字位数，非小数位
a = Decimal("1.0000001")
b = Decimal("0.0000002")
print(a + b) # 输出：1.0000003，无 float 累积误差
decimal 的性能和兼容性代价不能忽视
Decimal 比 float 慢 10–50 倍，且不兼容大部分 NumPy 函数、matplotlib 绘图输入、JSON 序列化（需手动转 str 或自定义 encoder）。
- NumPy 数组无法直接存
Decimal；要用dtype=object，但失去向量化优势 -
json.dumps(Decimal("3.14"))会报TypeError，必须预处理：json.dumps(str(d)) - 与
float混合运算会隐式转回float，瞬间丢失精度：Decimal("0.1") + 0.2→ 结果是float -
math.log(Decimal("10"))会报错，得用Decimal("10").ln()
什么时候该坚持用 float 而不是硬切 decimal
很多场景下，“修复”浮点误差是伪需求。比如机器学习权重更新、物理仿真、图像处理——这些本就依赖 IEEE 754 的硬件加速和标准行为，强行换 Decimal 既慢又无意义，还可能破坏算法收敛性。
- 科学计算（尤其涉及
numpy、scipy）：保持float64，用相对误差判断相等（abs(a - b) < eps * max(abs(a), abs(b))） - 时间戳、坐标、传感器读数：原始数据本身就有测量误差，比 float 表示误差大得多
- 仅需最终结果四舍五入：用
round(x, 2)或格式化，而非全程高精度 - 真正要防的不是“误差”，是“业务逻辑因误差误判”——比如账户余额比较，应改用整数单位（分）或明确容差阈值
Decimal 不是银弹。它解决的是确定性十进制算术问题，而不是所有“看起来不准”的情况。用错地方，反而把简单问题搞复杂。
