minlength和maxlength限制字符串值的unicode码点数量，非字节数或显示宽度；对非字符串类型无效，需配合whitespace使用，且校验优先级高于pattern。
XML Schema里minLength和maxLength到底限制谁？
它们只作用于字符串值的Unicode码点数量（即string.length在多数语言中的行为），不是字节数，也不是显示宽度。比如中文字符、emoji、代理对（如某些罕见emoji）都各算1个长度单位。
常见错误现象：maxLength="10"却校验通过了10个汉字——这其实是预期行为；但若传入"??"（一个ZJW序列），它可能被算作2或4个码点，取决于解析器是否启用Unicode正规化，这时maxLength="1”反而可能不生效。
- 必须配合
whiteSpace使用：默认preserve，开头/结尾空格计入长度；若想忽略，得显式设whiteSpace="collapse" - 只对
xsd:string及其派生类型（如xsd:token、xsd:normalizedString）有效；对xsd:int或xsd:date加minLength会被忽略（XSD处理器通常静默丢弃） - 数值型字段要限制位数？别用
minLength，改用xsd:pattern或应用层校验
为什么minLength="0"有时校验失败？
因为minLength管的是“有值时的最小长度”，不是“是否允许为空”。空字符串""是否合法，取决于nillable="true"或元素是否为optional（minOccurs="0"）。
使用场景：API接收JSON转XML后，字段值为null，映射成xsi:nil="true"——此时minLength完全不参与校验；但若传了<name></name>（空标签），那就是""，受minLength约束。
-
minLength="0"允许空字符串，但不允许缺失该元素（除非minOccurs="0"） - 想同时允许“缺失”和“为空”，需组合：
minOccurs="0"+minLength="0" - 某些老版本Xerces或.NET XmlSchemaSet会把
minLength="0"当成无效约束并报warning，建议升级解析器或避开这个写法
和正则pattern一起用，谁先执行？
顺序是固定的：先按minLength/maxLength粗筛，再跑pattern。这意味着pattern不会收到超长或过短的字符串。
性能影响：长度检查是O(1)开销，pattern是O(n)，所以把长度限制放前面能提前拦截明显非法输入，减少正则引擎负担。
- 不要用
pattern模拟长度限制，例如pattern=".{5,10}"——它无法处理换行符（.不匹配\n），且语义模糊 - 若
maxLength="5"但pattern="[a-z]+@example\.com"，实际最大长度由正则决定，XSD校验会失败（因为正则要求至少11字符） - Java JAXB、.NET XSD.exe等工具生成类时，
minLength/maxLength通常转为注解或运行时断言，而pattern可能不生成任何校验逻辑，这点务必手动补全
不同解析器对边界值的处理差异
maxLength="10"在Xerces-J 2.12中严格拒绝11个码点，在libxml2 2.9.12里可能因UTF-8解析偏差多算1个，导致同一XML在不同环境校验结果不一致。
容易踩的坑：前端JavaScript用str.length做前置校验，后端Java用String.length()，看似一致，但若XML经过Node.js xml2js解析再转出，中间可能触发UTF-16代理对拆分，让长度+1。
- 跨系统传输前，对关键字符串字段做Unicode正规化（NFC），能大幅降低长度计算差异
- 测试时别只用ASCII，必须覆盖中文、emoji（如
"?"）、带变音符号的字母（如"café"） - 生产环境建议在XSD校验后，再用应用层代码二次检查长度（尤其涉及数据库字段长度限制时）
