xs:decimal的精度由totaldigits和fractiondigits共同决定，二者独立约束；fractiondigits仅限制小数位数且不自动舍入，totaldigits限制整数与小数部分总位数（不含小数点）；正确声明两位小数金额需同时设置fractiondigits="2"和足够大的totaldigits（如18）。
xs:decimal 的精度不是靠小数位数控制的
XML Schema 中 xs:decimal 本身不带“小数位数”属性，你不能直接写 xs:decimal(2) 或类似语法。它的精度由 totalDigits 和 fractionDigits 共同决定，且二者是独立约束 —— 忘记这点会导致校验行为和预期严重不符。
常见错误现象：fractionDigits="2 却允许输入 123.456（被截断或报错，取决于解析器）；或者设了 totalDigits="5" 却发现 123.45 过不了校验（因为整数部分占了3位，小数部分超限）。
-
fractionDigits只限制小数点后最多几位，不控制舍入 —— 超出位数的值会直接校验失败，不是自动四舍五入 -
totalDigits是整个数字（不含小数点）的总位数，包括整数和小数部分；例如123.45的totalDigits是 5 - 两者可单独使用：只设
fractionDigits不限制整数长度；只设totalDigits不限制小数位数（但实际小数位可能为 0）
如何正确声明保留两位小数的金额字段
典型场景是货币金额，要求「整数部分不限长、小数固定两位」。这不能只靠 fractionDigits="2"，必须配合 totalDigits 合理放大上限，否则大额数字（如百万级）会意外失败。
示例（XSD 片段）：
<xs:simpleType name="amount">
<xs:restriction base="xs:decimal">
<xs:fractionDigits value="2"/>
<xs:totalDigits value="18"/>
</xs:restriction>
</xs:simpleType>
这里 totalDigits="18" 意味着最多支持 16 位整数 + 2 位小数（如 1234567890123456.78），够用又不至于过大影响性能。若设成 10，那超过 999999.99 就挂了。
- 别用
maxInclusive替代精度控制 —— 它只管数值范围，不管格式；999.999仍能通过校验 - Java JAXB、.NET XmlSerializer 等多数绑定工具会把
fractionDigits="2"映射为BigDecimal或decimal，但不会自动做舍入；业务层仍需自行处理输入截断逻辑 - 某些老版本解析器（如早期 Xerces）对极大
totalDigits值支持不稳定，18 是较安全的通用上限
fractionDigits=0 时的特殊行为
设 fractionDigits="0" 表示“不允许小数点”，但很多人误以为它等价于整数类型。实际上它仍是 xs:decimal，只是小数部分强制为 0 —— 所以 "123.0" 和 "123" 都合法，而 "123.00" 在部分严格解析器下会失败（因隐含了多余的小数位）。
- 如果真要强约束为整数格式，优先用
xs:integer，语义更清晰，兼容性更好 -
fractionDigits="0"+totalDigits="N"仍允许科学计数法输入（如"1.23E2"），只要最终值是整数；但多数业务系统不期望这种写法 - JSON Schema 没有对应机制，转成 JSON 时这类约束会丢失 —— 如果走 XML/JSON 混合流程，这里就是个隐性断点
验证时容易被忽略的空白与符号问题
xs:decimal 对前后空白敏感：XML 解析器默认会 trim，但某些配置（如 whiteSpace="preserve"）下，" 123.45 " 会校验失败。负号也常踩坑 —— "-123.45" 合法，但 "−123.45"（全角减号）或 "123.45-" 会直接报错，错误信息通常是 "cvc-datatype-valid.1.2.1: '-123.45' is not valid 这类模糊提示。
- 测试时务必用真实 XML 实例验证，别只看 XSD 定义；特别是从 Excel 或用户表单粘贴数据时，容易混入不可见字符
- 正则预处理不是好办法 —— XSD 校验发生在解析阶段，业务代码介入太晚；应在接收原始字符串时就清洗
- 国际化场景下注意小数点符号：XSD 强制使用英文点号
.，逗号,无论 locale 设置如何都会失败
