xs:unsignedint 最大值为4294967295（2³²−1），是32位无符号整数；它包含0，而xs:positiveinteger从1开始且无上界；jaxb将其映射为long以避免溢出。
xs:unsignedInt 在 XSD 中到底能表示多大数字
它最大是 4294967295（即 2³² − 1），不是无限大，也不是 JavaScript 的 Number.MAX_SAFE_INTEGER。XSD 规范明确定义 xs:unsignedInt 为 32 位无符号整数，和 C/C++ 的 unsigned int（在大多数平台上）一致。
常见错误现象：用它校验一个值为 5000000000 的 XML 字段，解析器直接报错 cvc-datatype-valid.1.2.1: '5000000000' is not a valid value for 'unsignedInt' —— 这不是解析器 bug，是类型越界。
- 使用场景：适合 ID、状态码、计数器等明确不会超过 42 亿的整数字段
- 如果业务可能超过该范围（比如某些日志时间戳毫秒值、大数据量统计），必须改用
xs:unsignedLong - 注意：不同 XML 解析器对溢出的处理不一致——有的静默截断（危险！），有的严格拒绝，不能依赖运行时兜底
和 xs:positiveInteger 的关键区别在哪
xs:unsignedInt 包含 0，xs:positiveInteger 从 1 开始且无上界（基于任意精度整数）。这不是风格偏好问题，而是语义和验证行为的根本差异。
典型误用：把“订单数量”定义成 xs:unsignedInt，结果允许 <quantity>0</quantity> 通过校验，但业务逻辑里 0 表示“未下单”，不该出现在已提交订单中。
-
xs:unsignedInt：底层是固定宽度二进制存储，校验快，序列化紧凑 -
xs:positiveInteger：底层是十进制字符串解析，支持超大数（如123456789012345678901234567890），但校验开销略高 - 兼容性提示：老旧的 .NET XmlSchemaSet 或某些嵌入式 XML 引擎可能不完全支持
xs:positiveInteger的大数解析，建议先实测
Java/JAXB 解析 xs:unsignedInt 时为什么变成 long
因为 Java 没有原生的 unsigned 32 位整数类型。JAXB 默认将 xs:unsignedInt 映射为 java.lang.Long，而不是 int 或 Integer —— 这是规范行为，不是配置错误。
容易踩的坑：有人手动改成 int 字段，结果值为 4000000000 时被强制转型成负数（溢出），后续比较或计算全错。
- 正确做法：保持生成的
Long类型，必要时用Long.intValue()（但要先if (val 校验） - 如果确定值永远 ≤
2147483647（有符号 int 上限），可考虑用xs:int替代，但会失去 0–2147483647 之外的合法范围 - 注意：Jackson + JAXB 注解混用时，
@XmlSchemaType(name = "unsignedInt")必须配Long，否则反序列化失败
XML 实例中写 0xABC 这种十六进制会通过校验吗
不会。xs:unsignedInt 只接受十进制数字字符串，开头带 0x、下划线、逗号或任何非数字字符都会触发校验失败，报错类似 cvc-datatype-valid.1.2.1: '0xABC' is not a valid value for 'unsignedInt'。
常见混淆点：XSD 本身不支持十六进制字面量语法（那是编程语言的特性），所有值在 XML 文档里都必须是纯十进制文本。
- 如果你控制 XML 生成端，确保序列化时调用
String.valueOf(intValue)而非Integer.toHexString() - 如果接收第三方 XML，别指望 schema 能自动识别并转换进制；预处理或自定义验证器才能解决
- 特别注意：带前导零的十进制数（如
007）是合法的，会被解析为7—— 这是标准行为，不是 bug
真正麻烦的是跨系统协作时，一方按 xs:unsignedInt 理解，另一方文档写“整数（支持十六进制）”，这种隐含假设比类型定义本身更容易导致线上故障。
