Python浮点数精度误差源于IEEE 754二进制表示限制，0.1无法精确存储；Decimal可修复但必须全程字符串初始化、隔离上下文、杜绝float混用，否则无效。
Python浮点数运算产生精度误差，不是bug，而是所有IEEE 754双精度浮点实现的共性——0.1在二进制中是无限循环小数，必须截断存储，误差从输入那一刻就已固化。用Decimal能修复，但前提是**全程守住字符串初始化、隔离上下文、杜绝float混用**，否则只是自我安慰。
为什么0.1 + 0.2 ≠ 0.3根本无法避免
这不是Python的问题，是二进制表示十进制小数的数学限制：0.1的二进制展开是0.0001100110011...（无限循环），硬件只能存有限位，尾部被舍入。每次运算都在这个近似值上继续，误差会累积。
-
0.1 + 0.2 - 0.3结果是5.551115123125783e-17，不是零 -
sum([0.1] * 10)常得0.9999999999999999而非1.0 - 数据库ORM自动映射、JSON解析后直接喂给
Decimal(0.1)，精度早已丢失
Decimal("0.1")和Decimal(0.1)有本质区别
前者从字符串字面量解析，完全避开二进制浮点；后者先走一遍float(0.1)，误差已不可逆写入内存。
- ✅ 安全初始化：
Decimal("0.1")、Decimal("199.99")、Decimal(123) - ❌ 危险操作：
Decimal(0.1)、Decimal(float_value)、Decimal(json.loads('{"amt": 0.01}')['amt']) - ⚠️ CSV/Excel读取数值列时，默认转为
float，需显式指定dtype=str或用converters转字符串再构造
精度控制不是“显示几位”，而是全局有效位+quantize显式截断
getcontext().prec = 28设的是所有运算的**最大有效数字位数**，不是小数位数；财务场景要求固定两位小数，必须靠quantize()强制对齐。
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
立即学习“Python免费学习笔记（深入）”；
-
Decimal("1.234567").quantize(Decimal("0.01"))→Decimal("1.23") - 舍入模式默认是
ROUND_HALF_EVEN（银行家舍入），财务常用ROUND_HALF_UP，必须显式传参 - 多线程中改
getcontext()会影响全局，应改用with localcontext() as ctx:临时覆盖
Decimal和float混用=前功尽弃
只要表达式里出现任意一个float，整个运算链立刻降级为float，精度瞬间归零。
- ❌ 错误：
Decimal("10.5") + 0.2、Decimal("1.5") * 2.5、math.sqrt(Decimal("4")) - ✅ 正确：
Decimal("10.5") + Decimal("0.2")、Decimal("1.5").multiply(Decimal("2.5"))、Decimal("4").sqrt() - 第三方库如
numpy、pandas不支持Decimal，传入会静默转float；序列化json.dumps(Decimal("3.14"))直接报TypeError，必须预处理为str(d)
真正难的从来不是调用Decimal，而是确保从原始输入（API响应、CSV字段、用户表单）开始，每一步都拒绝float介入——漏掉任意一环，整条高精度链就断了。
