xml schema（xsd）不支持条件分支逻辑，xsd 1.1 可用 xsd:assert 实现，但兼容性差；xsd 1.0 需拆分为可选结构或交由应用层校验，辅以 schematron/xslt 增强，规则参数须外置，签名不保证业务逻辑正确。
XML Schema 中如何表达条件分支逻辑
XML Schema（XSD）本身不支持 if/else、switch 或布尔表达式判断，所谓“业务规则”必须拆解为结构约束或通过外部机制实现。直接在 xsd:complexType 里写“如果 status=‘APPROVED’ 则 require approvedBy 字段”是做不到的。
可行路径只有两条：用 xsd:assert（仅 XSD 1.1 支持），或把校验逻辑移出 Schema，交给应用层。
- XSD 1.1 的
xsd:assert可写类似<assert test="(@status != 'APPROVED') or approvedBy"></assert>，但多数老系统（如 Java JAXB 2.2、.NET Framework 4.8 默认）只认 XSD 1.0，会直接报错Invalid content was found starting with element 'xs:assert' - 若必须兼容 XSD 1.0，只能靠多个
xsd:element配合minOccurs="0"和命名区分，例如定义approvalInfoForApproved和approvalInfoForRejected两个可选组，再由业务代码判断启用哪一组 - 注意：XSD 断言中的 XPath 表达式作用域是当前元素，不能跨文档引用外部数据（比如查数据库状态），所有依赖值必须已存在于当前 XML 实例中
JAXB / Jackson XML 绑定时如何注入动态校验
当 XML 映射到 Java 或 Kotlin 对象后，真正的规则执行应落在对象构建之后、业务处理之前。JAXB 本身不提供钩子，Jackson XML Module 也仅支持基础注解映射，复杂逻辑得靠手动干预。
典型做法是在反序列化后调用自定义验证方法，而不是试图让 @XmlElement 或 @JacksonXmlProperty 承担规则判断责任。
- 避免在 setter 里 throw 异常——JAXB 在填充字段时可能乱序执行，
status还没设，approvedBy的 setter 就先被触发，导致误判 - 推荐统一入口：用
@PostConstruct（配合 Spring 管理 Bean）或定义显式validate()方法，在 XML 转 POJO 完成后集中检查 - Jackson XML 可配合
@JsonDeserialize自定义反序列化器，但仅适合单字段逻辑；整树级规则仍建议走独立校验层，否则难以测试和复用
用 XSLT 或 Schematron 做增强校验的实操边界
当 XSD 表达力不足，又不想把全部规则下沉到应用代码，XSLT 或 Schematron 是更贴近 XML 生态的补充方案。它们不是替代 Schema，而是叠加一层语义检查。
Schematron 更适合业务规则：用 XPath 写断言，输出可读性高的错误提示；XSLT 则适合做转换+校验混合任务（比如把旧格式 XML 拆成多个新消息并同时验证）。
- Schematron 规则示例中，
<rule context="order"><assert test="count(item) > 0 and sum(item/price) > 100">订单金额必须大于100且至少含一个商品</assert></rule>—— 这类计算型规则 XSD 根本无法覆盖 - 注意 Schematron 需要额外处理器（如
libxml2、saxon），Java 项目常用net.sf.saxon+ISO-SchematronXSLT 样式表预编译，不能直接扔进 JAXB 流程 - XSLT 校验容易陷入“一边转换一边改数据”的陷阱，比如用
<message terminate="yes"></message>报错虽可行，但终止后无标准错误码，下游系统难做分类处理
<?xml version="1.0"?>
<sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron" queryBinding="xslt2">
<sch:pattern id="order-rules">
<sch:rule context="order">
<sch:assert test="customer/@type = 'VIP' or @priority != 'URGENT'">
非VIP客户不能提交紧急优先级订单
</sch:assert>
</sch:rule>
</sch:pattern>
</sch:schema>
为什么不要在 XML 文件里硬编码规则参数
见过把阈值、状态码映射表直接写进 XML 示例文件（如 <rule maxitems="5" minamount="200.0"></rule>），再让解析器读取它来控制后续行为——这看似灵活，实则破坏契约稳定性。
XML 是数据载体，不是配置中心。规则参数变动频率远高于结构定义，混在一起会导致每次参数调整都要重发 Schema、重启服务、重新测试所有消费者。
- 参数应外置：放在数据库、配置中心（如 Consul、Nacos）或版本化 YAML/JSON 配置中，XML 只保留事实性数据（如
<orderamount>250.0</orderamount>） - 若真需运行时差异化规则，用
schemaLocation动态指向不同 XSD 版本，或在根元素加version属性，由解析器路由到对应校验器 - 最易忽略的一点：XML 签名（
ds:Signature）只保障内容未被篡改，不保证规则逻辑正确。签了名的 XML 如果含错误的业务参数，系统照常执行，后果更严重
