MyBatis映射BigDecimal丢失精度主因是JDBC驱动默认返回Double/Float，需在resultMap中显式指定javaType="java.math.BigDecimal"并配置JDBC参数确保用BigDecimal获取数值。
Java MyBatis 中 resultMap 映射 BigDecimal 丢失精度
MyBatis 默认用 ResultSet.getObject() 获取数值，对 Oracle/MySQL 的 DECIMAL 类型常返回 Double 或 Float，导致小数位截断或科学计数法显示。这不是数据库问题，是 JDBC 驱动 + MyBatis 类型处理器协同失当。
- 显式在
resultMap中为字段指定java.math.BigDecimal类型：<result property="amount" column="amount" javaType="java.math.BigDecimal"/>
- 确保数据库列定义明确为
DECIMAL(p,s)（如DECIMAL(19,4)），避免用FLOAT或DOUBLE - 检查 JDBC URL 是否含
useBigDecimal=true（MySQL）或decimalNumbers=true（PostgreSQL），Oracle 驱动通常默认正确，但旧版需加oracle.jdbc.defaultNChar=true配合
Python xml.etree.ElementTree 解析时浮点数字符串被自动转成 float 导致精度丢失
ElementTree 默认把文本内容当作字符串处理，但如果你手动调用 float() 或用 xmltodict 等第三方库，就可能触发隐式转换 —— 而 Python 的 float 是 IEEE-754 双精度，无法精确表示 0.1 这类十进制小数。
- 不要对 XML 中的数值文本做
float(text)，改用decimal.Decimal(text.strip())，传入原始字符串而非已转成 float 的值 - 若用
xmltodict，它默认不解析数字类型；如启用了postprocessor自动转类型，务必禁用或重写逻辑，保留字符串再按需转Decimal - XML 中应始终以字符串形式表达高精度数值，例如
<price>19.9900</price>，而非依赖解析器“猜类型”
SQL Server XML 数据类型中 value() 方法返回 xs:decimal 但 .NET 客户端接收为 double
SQL Server 的 value() 函数声明返回 xs:decimal，但 ADO.NET 的 SqlXml.Value 属性或 ExecuteScalar() 结果常被映射为 double，尤其在未显式指定 SQL 类型时。
- 在 T-SQL 中强制转换输出类型：
SELECT CAST(x.value('(/root/amount/text())[1]', 'decimal(19,4)') AS decimal(19,4)) AS amount - .NET 端用
SqlDataReader.GetDecimal()替代.GetValue()或.GetDouble() - 避免在 C# 中用
Convert.ToDecimal(obj)处理从 XML 提取的object，优先走强类型读取路径
前端 JavaScript 解析 XML 后用 parseFloat() 处理金额字段
XML 文本节点内容是字符串，parseFloat() 会丢掉末尾零、溢出精度（如 "123.4500" → 123.45），且对大数值（>253）完全不可靠。
- 金额类字段一律保留字符串，仅在必要展示时用
Number.prototype.toFixed()格式化，运算前才转BigInt或用big.js/decimal.js - DOM 解析后立即提取并冻结原始文本：
const amountStr = element.textContent.trim(); // 不要 parseFloat(amountStr)
- 如果必须数值运算，用
new Decimal(amountStr)（需引入 decimal.js），别信Number()或+操作符
精度问题从来不是单一环节的锅，而是 XML 字符串 → 解析器类型推断 → 语言运行时数值表示 → 序列化回传 这整条链上任意一环松动都会漏。最稳的做法：中间全程用字符串承载高精度值，只在确定上下文和精度需求后，才用对应语言的定点数类型做一次可信转换。
