基于Java BigDecimal优化Saxon 9.8 HE JSON数值精度是否合理？

首先直接给结论：从解决IEEE double精度丢失的核心需求来看，这个思路是完全合理的，但实际落地前需要考虑实现复杂度和更轻量化的替代路径。

• 需求匹配上完全贴合
  Saxon 9.8 HE默认用IEEE double处理JSON数值，确实会在处理超大整数、高精度小数时出现精度丢失——这在金融、科学计算场景里是致命问题。改用Java BigDecimal来存储和运算数值，能完美保留精度，完全命中你的需求。而且Saxon HE是开源的，克隆现有JSON处理逻辑并替换底层数值类型，从技术可行性上来说是站得住脚的。

• 但实现复杂度不可忽视
  你需要梳理Saxon整个JSON处理的链路：从JSON文本的解析、数值节点的构建、XPath/XQuery表达式中对数值的运算，到最终序列化回JSON的全流程。每个环节都要把double的依赖替换成BigDecimal，还要处理好：

  • 与Saxon现有类型系统的兼容（比如如何让BigDecimal适配XPath的数值类型体系）
  • 所有内置数值运算函数的适配（比如+、-、round()这些函数要支持BigDecimal）
  • 序列化JSON时BigDecimal到字符串的转换（避免再次引入精度问题）
    另外，Saxon 9.8是比较老旧的版本（当前主流是12.x），后续如果要升级Saxon，你的定制化代码可能需要大量修改，迁移成本不低。

• 更轻量化的替代方案值得优先考虑
  不一定非要克隆整个JSON模块，你可以试试这些侵入性更低的方法：

  1. 自定义扩展函数：利用Saxon的扩展机制，注册自定义函数来处理BigDecimal——比如在解析JSON后，把double数值转换为BigDecimal存储，后续运算都通过自定义函数完成。
  2. 提前解析转换：先用第三方JSON库（比如Jackson）把JSON中的数值解析为BigDecimal，再将这些值导入到Saxon的节点树中，后续用自定义函数做运算。
     这些方法开发成本低很多，也能快速验证你的需求是否能满足。

• 额外要注意的细节
  要考虑标准兼容性：XPath/XQuery的官方标准中数值类型是基于IEEE double的，改用BigDecimal后，一些默认运算的行为会和标准不一致（比如精度处理、特殊值NaN/Infinity的处理），你需要在自定义逻辑中明确这些差异，避免使用者踩坑。另外，BigDecimal的运算速度比double慢，如果要处理海量数值运算，得提前评估性能影响。

内容的提问来源于stack exchange，提问作者MTH