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，然后在反序列化时交由语言原生日期类型处理——格式校验和语义校验分两层做，反而更可控。
