JavaScript 的 Number 类型基于 IEEE 754 双精度浮点数，仅支持约 15–17 位有效数字，无法精确表示后端 Java 的 BigDecimal（如 1.123456789012345678），导致解析 JSON 时自动舍入或截断。解决方案是前后端协同：后端以字符串形式序列化高精度数值，前端使用专用大数库（如 js-big-decimal）安全解析。
javascript 的 number 类型基于 ieee 754 双精度浮点数，仅支持约 15–17 位有效数字，无法精确表示后端 java 的 bigdecimal（如 1.123456789012345678），导致解析 json 时自动舍入或截断。解决方案是前后端协同：后端以字符串形式序列化高精度数值，前端使用专用大数库（如 `js-big-decimal`）安全解析。
在 Web 应用中，当 Java 后端使用 BigDecimal 精确传递如 "qty": 1.123456789012345678 这类高精度数值时，若直接通过 JSON 返回原始数字字面量，JavaScript 前端（无论 AngularJS、React 或 Vue）在调用 JSON.parse() 时会将其强制转换为原生 Number 类型——而该类型最大安全整数为 Number.MAX_SAFE_INTEGER（2⁵³−1），小数精度上限约为 15–17 位有效数字。因此，1.123456789012345678 在解析后变为 1.1234567890123457，末尾数字丢失，属于不可逆的精度坍塌，而非简单“四舍五入”。
✅ 正确实践：字符串传输 + 专用大数库解析
后端应将 BigDecimal 字段序列化为字符串（而非数字），例如：
{
"uom": "EA",
"qty": "1.123456789012345678"
}前端使用 js-big-decimal（轻量、无依赖、支持加减乘除、比较、格式化）安全构造高精度对象：
npm install js-big-decimal
import { BigDecimal } from 'js-big-decimal';
// 解析响应数据（假设 data 是已解析的 JSON 对象）
const qtyStr = data.qty; // "1.123456789012345678"
const qty = new BigDecimal(qtyStr);
console.log(qty.toString()); // "1.123456789012345678"
console.log(qty.add(new BigDecimal("0.000000000000000001"))); // "1.123456789012345679"⚠️ 关键注意事项：
- 禁止在 JSON 中传数字字面量：即使后端用 Jackson 的 WRITE_NUMBERS_AS_STRINGS 全局配置，也需确保 BigDecimal 字段被显式标注为 @JsonSerialize(using = ToStringSerializer.class) 或使用 @JsonFormat(shape = JsonFormat.Shape.STRING)。
- 避免 parseFloat() 或 +str 转换：这些操作仍会落入 Number 精度陷阱。
- AngularJS 特别提示：若使用 $http，确保响应拦截器不提前 JSON.parse() 并二次处理；推荐在成功回调中直接处理字符串字段。
- 服务端一致性：所有涉及金额、计量、科学计算等需亚微米/纳秒级精度的字段，均应统一采用字符串序列化策略。
? 总结：JavaScript 本身不提供原生 BigDecimal 支持，这不是框架（AngularJS）或 HTTP 协议的问题，而是语言底层数值模型的固有限制。解决精度丢失的唯一可靠路径是——信任字符串，移交控制权给专业大数库。这既是跨语言协作的最佳实践，也是金融、IoT、计量系统等对精度零容忍场景的工程底线。
立即学习“Java免费学习笔记（深入）”；
