Decimal128在MongoDB内部能避免浮点误差，但跨链路易因驱动、ORM或ETL导致隐式降级为double而丢失精度；整数存“分”更安全，前提是全链路严格统一单位换算与类型约束。
用整数更安全，前提是能控制精度和单位（比如全部存“分”）；Decimal128 能表达精确小数，但实际落地时容易因驱动、序列化、聚合操作引入隐式转换或精度丢失。
Decimal128 在 MongoDB 里真能避免浮点误差？
能——但仅限于 MongoDB 内部存储和原生运算。一旦经过 driver 序列化/反序列化，或被前端、ORM、ETL 工具处理，就可能降级为 Number 或字符串，失去精度保障。
- Node.js 驱动默认把
Decimal128当作对象返回，需显式调用.toNumber()或.toString()；直接 JSON.stringify() 会丢精度 - Python PyMongo 返回的是
Decimal128实例，但 pandas 或 Flask jsonify 默认不支持，常 fallback 成 float - Java Spring Data MongoDB 对
Decimal128支持较弱，部分版本映射成BigDecimal时字段名不一致，导致写入失败
用整数存金额（如“分”）有哪些硬性前提？
必须统一业务层的单位换算逻辑，且所有读写路径都绕过自动类型推断。不是“存整数就万事大吉”，而是“整数 + 严格约束 = 可控”。
- 所有写入前强制乘以 100 并
Math.round()（避免 JS 浮点乘法误差），再转parseInt()或BigInt - 查询时不能用
{ amount: { $gt: 99.99 } }这类小数条件，得写成{ amount_cents: { $gt: 9999 } } - 聚合阶段（如
$sum）结果仍是整数，需在应用层除以 100 并格式化，不能依赖$divide后直接当元显示
什么时候不得不选 Decimal128？
当业务要求保留小数位数参与复杂聚合（如按 0.001 元粒度分组统计）、或已有系统强依赖 IEEE 754 外的十进制语义（如金融风控规则引擎），且能锁定全链路 stack 支持。
- 确认 driver 版本支持：Node.js mongodb@6+、PyMongo@4.7+ 才对
Decimal128做了较完整序列化修复 - 避免在
$lookup后的 pipeline 中混用Decimal128和Double字段，否则$add等操作会静默转为 double - 备份/导出工具（如
mongodump）默认不保留Decimal128类型，需加--legacy或用mongosh的db.collection.find().toArray()手动导出
真正难的不是选类型，而是让所有环节——从用户输入框的 onBlur 校验，到 Kafka 消息序列化器，再到 BI 工具连接器——都认得清“这不是普通数字”。Decimal128 是个好工具，但它的安全边界只在 MongoDB Server 和你亲手写的 driver 层之间。跨出去一步，就得靠人盯住每处转换。
