xs:choice的maxoccurs修饰整个choice块而非内部元素，故允许多组“a或b”但不允许多个相同元素连续出现；需将maxoccurs设于具体element上或改用sequence/all实现混合重复。
xs:choice maxOccurs=”unbounded” 为什么没生效
常见现象是 xml 文档里明明写了多个 xs:choice 中的可选元素，但验证时只接受第一个，后续被报错——根本原因不是 maxOccurs 写错了，而是它作用对象理解反了。
maxOccurs 是修饰整个 xs:choice 块的出现次数，不是修饰块内每个子元素。也就是说：<choice maxoccurs="unbounded"><element name="a"></element><element name="b"></element></choice> 允许你重复写一整套「a 或 b」，比如 <a></a><b></b><a></a>，但不允许 <a></a><a></a>（除非 a 自己设了 maxOccurs）。
- 真正想让某个子元素（如
a）多次出现？得把maxOccurs放在那个xs:element上，而不是xs:choice上 - 如果想实现「a 和 b 可任意顺序、各出现多次」，
xs:choice不适合，该用xs:sequence+ 各自设maxOccurs，或改用xs:all（注意：XSD 1.0 中xs:all不支持maxOccurs > 1） - 某些老版本解析器（如 .NET Framework 2.0 的 XmlSchemaSet）对
maxOccurs="unbounded"在xs:choice下的支持不一致，建议实测验证
xs:choice 里嵌套 xs:sequence 性能和可读性代价
有人为了绕开 xs:choice 对重复元素的限制，会这么写：<choice><sequence><element name="a" maxoccurs="unbounded"></element></sequence><sequence><element name="b" maxoccurs="unbounded"></element></sequence></choice>。逻辑上看似“a 多个 或 b 多个”，但实际效果是：XML 只能全选 a，或全选 b，不能混用。
- 这种写法会让 XSD 更难维护，尤其当选项变多时，组合爆炸式增长
- 部分校验器（如 libxml2）在处理深度嵌套的
xs:choice+xs:sequence时，会显著拖慢验证速度 - 更务实的做法：如果业务上允许混合顺序和重复，直接放弃
xs:choice，改用xs:sequence并为每个元素单独控制minOccurs/maxOccurs
XSD 1.0 vs 1.1 中 xs:choice maxOccurs 行为差异
XSD 1.1 引入了 xs:assert 和更灵活的 occurrence 控制，但 xs:choice 本身的 maxOccurs 规则没变——变的是你能不能绕过去。
- XSD 1.0：无法表达「a 和 b 共同最多出现 5 次，且顺序任意」这类约束
- XSD 1.1：可用
<assert test="count(a) + count(b) <= 5"></assert>补足，但注意：不是所有工具链支持 XSD 1.1（例如 Java JAXB 默认只认 1.0） - 如果必须用 XSD 1.0 又要强约束，只能靠应用层二次校验，别指望 schema 本身兜底
用 xmllint 测试 xs:choice maxOccurs 是否生效
别依赖 ide 插件或文档描述，直接拿 xmllint 跑真实 XML 样例最可靠。它默认用的是 libxml2，行为贴近生产环境。
- 命令：
xmllint --schema schema.xsd test.xml --noout，出错信息里若含Element 'xxx': this element is not expected，说明maxOccurs或结构定义没匹配上 - 测试时务必构造边界用例：比如
maxOccurs="3"就试 3 次、4 次、0 次三种情况 - 注意命名空间：如果 schema 用了
targetNamespace，XML 必须声明对应xmlns，否则xmllint可能静默跳过校验
实际用的时候，最容易被忽略的是：XSD 中所有 occurrence 属性（minOccurs、maxOccurs）默认值都是 1，且只作用于直系父节点——哪怕嵌了三层 xs:choice，也得一层层确认谁管谁。