XSD的xs:pattern不支持^、$和\d，需用[0-9]替代，且必须覆盖全长；正确写法为[0-9]{4}-(0[1-9]|1[0-2])-(0[1-9]|12|3[01])，仅校验格式而非语义。

xs:pattern 里写 YYYY-MM-DD 正则为什么总不生效

因为 XSD 的 xs:pattern 默认使用 XML Schema 正则语法，不支持 ^、$、\d 这类常见简写，也不做全局匹配——它只校验字符串是否「包含」符合模式的子串，而不是「完全等于」。

常见错误现象：2023-13-01 或 abcd2023-01-01xyz 居然能通过验证；或者写成 \d{4}-\d{2}-\d{2} 直接报 schema 解析失败。

• 必须用 [0-9] 替代 \d
• 必须显式锚定首尾：用 .* 包裹 + ^/$ 无效，正确方式是让整个模式「覆盖全长」
• 月份和日期要限制范围，否则 2023-99-99 也能过

正确的 xs:pattern 写法（带年月日范围校验）

真正可用的模式得兼顾格式和逻辑合理性。XSD 正则不支持条件分支或回溯引用，所以月份天数只能靠穷举或宽松约束+应用层兜底。

推荐折中方案（覆盖绝大多数误输）：

^[0-9]{4}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])$

但注意：XSD 中不能直接写 ^ 和 $，它们会被忽略。等效写法是：

[0-9]{4}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])

这个模式本身已隐含「从头到尾匹配」语义，只要不加 .* 类通配前缀/后缀即可。

• 年份：固定 4 位数字 [0-9]{4}，避免 23-01-01
• 月份：(0[1-9]|1[0-2]) 涵盖 01～12，排除 00、13
• 日期：(0[1-9]|[12][0-9]|3[01]) 覆盖 01～31，但无法区分大小月或闰年

为什么不用 xs:date 而坚持 xs:pattern

如果你只是想校验字符串格式，xs:date 看似更省事，但它会强制解析为有效日期（比如拒绝 2023-02-30），而某些场景下你只需要「长得像日期」——比如日志字段、用户输入草稿、数据库迁移中间态。

但要注意：xs:date 和 xs:pattern 是互斥的，不能同时用在同一个 xs:simpleType 上。

• 用 xs:date：语义强，自动校验闰年、大小月，但要求输入必须是真实可解析日期
• 用 xs:pattern：仅格式校验，轻量灵活，适合前端预检或松散协议
• 混合方案：先用 pattern 做初步过滤，再在业务代码里用 DateTime.parse() 或类似函数做二次解析

容易被忽略的兼容性坑

不同 XSD 处理器对正则支持程度不一。例如 .NET 的 XmlSchemaSet 和 Java 的 Xerces 对 Unicode 类别、重复次数语法容忍度不同。

• 避免用 {2,4} 这种量词，有些老解析器只认 {2} 或 {2,}
• 不要用 [[:digit:]]，必须写 [0-9]
• 括号必须成对，且不能嵌套超过 2 层（部分处理器限制）
• 如果 schema 要用于 SOAP 或 WSDL，建议在实际运行环境（如 Tomcat + Axis2）里测一遍 2023-02-29 是否被拒

最稳妥的做法，是把日期字段声明为 xs:string + xs:pattern，然后在反序列化时交由语言原生日期类型处理——格式校验和语义校验分两层做，反而更可控。