javascript 的 number 类型基于 ieee 754 双精度浮点数，仅能精确表示最多约 15–17 位有效数字；当后端以 bigdecimal 传递超长小数（如 1.123456789012345678）时，前端直接解析为 number 会导致末位失真——必须改用字符串传输 + 高精度库解析。
javascript 的 number 类型基于 ieee 754 双精度浮点数，仅能精确表示最多约 15–17 位有效数字；当后端以 bigdecimal 传递超长小数（如 1.123456789012345678）时，前端直接解析为 number 会导致末位失真——必须改用字符串传输 + 高精度库解析。
在金融、计量、科学计算等对数值精度要求严苛的场景中，Java 后端常使用 BigDecimal 精确表达任意精度小数（如库存数量 1.123456789012345678 EA）。然而，当该数据通过 JSON 接口传输至 JavaScript 前端时，若后端序列化为原始数字（如 "qty": 1.123456789012345678），JSON 解析器会将其自动转为 JavaScript Number 类型——而该类型本质是 64 位双精度浮点数，其有效精度上限约为 15–17 位十进制数字。因此，原始 18 位小数 1.123456789012345678 在解析后变为 1.1234567890123457，末位 8 永久丢失。
✅ 正确做法：后端序列化为字符串，前端用高精度库解析
-
后端改造（Java / Jackson 示例）
禁止将 BigDecimal 直接序列化为数字，强制输出为字符串：// 使用 @JsonSerialize 注解或全局配置 public class Product { private String uom; @JsonSerialize(using = ToStringSerializer.class) // 关键：转为字符串 private BigDecimal qty; // getters/setters... }输出 JSON 将变为：
{ "uom": "EA", "qty": "1.123456789012345678" } -
前端解析（AngularJS + js-big-decimal）
安装依赖：npm install js-big-decimal
在服务或控制器中安全解析：
立即学习“Java免费学习笔记（深入）”；
const bigDecimal = require('js-big-decimal'); $http.get('/api/product').then(response => { const data = response.data; // ✅ 从字符串构造，保留全部精度 const qty = new bigDecimal(data.qty); // "1.123456789012345678" console.log(qty.getValue()); // "1.123456789012345678" // 支持高精度运算（无浮点误差） const doubled = qty.multiply(new bigDecimal("2")); console.log(doubled.getValue()); // "2.246913578024691356" });
⚠️ 注意事项：
- 切勿在 JSON 中传输原始数字再尝试“修复”：parseFloat()、Number() 或 + 运算符均无法恢复已丢失的精度；
- 避免使用 BigInt 替代：BigInt 仅支持整数，不适用于带小数的 BigDecimal 场景；
- 统一前后端约定：所有需高精度的字段（如金额、重量、数量）均应定义为字符串类型传输，并在文档中标注 type: string (decimal)；
- 校验与调试：前端接收后立即用 bigDecimal.isValid() 验证字符串格式，防止空值或非法字符导致静默失败。
总结：JavaScript 本身不提供原生 BigDecimal，但通过「字符串传输 + 专用库解析」这一业界标准方案，可完全规避浮点精度陷阱。关键在于切断 JSON→Number 的隐式转换链路，让精度控制权回归开发者手中——这不仅是技术选型问题，更是保障业务数据一致性的架构级实践。
