xs:restriction 不能直接约束 xs:String 以外的复杂类型，其 base 属性仅接受已定义的简单类型（如 xs:Integer、xs:date），不支持 complextype 或 xs:anysimpletype；pattern 遵循 xsd 正则语法，隐式锚定且不支持 ^$ 和 . 元字符。
xs:restriction 能不能直接约束 xs:string 以外的类型
不能。xs:restriction 的 base 属性只接受「简单类型」（simpleType），且必须是已定义的原子类型或派生的简单类型，不能是 xs:complexType 或未声明的类型别名。常见误写如 <restriction base="xs:person"></restriction>（xs:person 是自定义 complexType）会直接报错：「Invalid type reference」。
实际能用的 base 值集中在 XSD 内置简单类型，比如 xs:string、xs:integer、xs:date、xs:decimal 等。注意：xs:anySimpleType 虽然名义上是“基类”，但不能作为 xs:restriction 的 base —— 它只用于 xs:union 或通配场景。
- 检查错误时优先确认 base 值是否在 XSD 1.1 内置类型表 中
- 若想约束复合结构（如带属性+子元素的对象），必须先用
xs:complexType定义整体结构，再用xs:simpleContent+xs:extension或xs:restriction去约束其文本内容部分 -
xs:restriction对xs:integer类型可用minInclusive、maxExclusive；对xs:string才支持pattern、maxLength、enumeration
pattern 里写正则，为什么校验总不生效
XSD 的 pattern 使用的是 xml Schema 正则语法（XSD Regex），不是 JavaScript 或 PCRE。最常踩的坑是：它默认锚定整个字符串（即隐含 ^…$），不支持 ^ 和 $ 显式书写，写了反而报错「Invalid regular expression」。
另一个关键是字符类和转义。例如想匹配邮箱，[a-z0-9._%+-]+@[a-z0-9.-]+.[a-z]{2,} 看似合理，但在 XSD 中 +、.、- 在字符类内外含义不同，且 . 不代表任意字符（它就是字面量点号），真正表示“任意字符”的是 . 只在非字符类中有效，而 XSD regex 不支持 . 元字符 —— 必须用 [^rnt] 或显式枚举。
- 所有 pattern 必须用双引号包裹，且内部不能出现未转义的
"、、<code>& - 需要匹配中文？用
[u4E00-u9FFF]（Unicode 范围），但确保你的 XML 解析器支持 Unicode 1.1+；老版本 Xerces 可能只认p{IsHan}（仅 XSD 1.1） - 调试建议：先用最小 pattern 测试，比如
pattern="a"，确认 schema 加载无错，再逐步加复杂度
enumeration 和 whiteSpace 一起用，空格处理很诡异
xs:enumeration 的值是严格按字面匹配的，而 xs:whiteSpace 控制解析时如何归一化空白 —— 这两者叠加容易出意料结果。比如设了 <whitespace value="collapse"></whitespace>，输入 ” yes ” 会被转成 “yes” 再比对；但若 enumeration 值写的是 “yes“，就匹配成功；若写的是 “ yes “（带空格），则永远不匹配。
更隐蔽的问题是换行符。windows 下编辑的 XSD 文件若在 enumeration 的 value 属性值里不小心粘贴了 CRLF，XML 解析器可能保留 r 或 n，导致枚举值实际变成 “yesr”，而输入数据经 collapse 后不含 r，必然失败。
- 枚举值一律手动删除前后空格和不可见控制符，用工具（如 VS Code 的 “显示不可见字符”）确认
- whiteSpace 设为
preserve时，enumeration 必须完全一致（包括空格、制表符、换行）；设为replace时，所有 tnr 都变为空格；collapse会进一步把连续空格压成一个，首尾去掉 - 如果业务上允许“大小写不敏感”，XSD 本身不支持，得靠应用层转换，或改用
pattern配合flags="i"（XSD 1.1）
xs:restriction 嵌套定义时，命名和引用容易混乱
很多人试图这样写：
<xs:simpleType name="positiveInt"> <xs:restriction base="xs:integer"> <xs:minInclusive value="1"/> </xs:restriction> </xs:simpleType> <xs:element name="age" type="positiveInt"/>看起来没问题，但若在另一个文件里用 xsi:type="positiveInt"，却提示类型未声明 —— 很可能是没正确 import 或 include 命名空间，或者 targetNamespace 不一致。
根本原因是：XSD 中 type 的可见性取决于 namespace + import/include 关系，而不是文件物理位置。一个常见的静默失败是：主 schema 用了 targetNamespace="http://my.org/ns"，但被引用的 simpleType 定义在无 namespace 的 schema 里，又没用 xmlns="" 声明 default namespace，结果解析器找不到 positiveInt。
- 所有跨文件引用，务必检查
targetNamespace是否匹配，以及<import namespace="..." schemalocation="..."></import>的 namespace 值是否与被导入文件的 targetNamespace 完全一致（包括末尾斜杠、大小写） - 避免用本地无 namespace 的 simpleType 名直接赋给
type属性；稳妥做法是统一用带前缀的 QName，如tns:positiveInt，并声明xmlns:tns="http://my.org/ns" - 调试时用命令行工具验证：
xmllint --schema main.xsd test.xml，比 ide 的实时校验更可靠
XSD 的约束逻辑是静态且严格的，没有运行时 fallback；每个 xs:restriction 节点都对应一个明确的类型派生路径，漏掉一个 base、写错一个命名空间、或多一个不可见字符，都会让整个验证链断裂。