直接写xs:date不能严格校验YYYY-MM-DD格式，需用xs:pattern限制为\d{4}-\d{2}-\d{2}；该正则仅校验格式，不验证日期有效性；词法错误如全角字符、缺零、空格等会报“invalid lexical value”；时区和绑定框架行为需在业务层处理。
XML Schema里怎么写xs:date才能真正校验YYYY-MM-DD？
直接写xs:date就行，但默认行为不等于你想要的“严格YYYY-MM-DD”。XML Schema的xs:date本身允许带时区（如2023-10-05+08:00），也接受2023-10-05Z，甚至某些处理器会宽松接受2023-10-5（单数字日）——这不是bug，是规范允许的。
如果你的业务系统只认2023-10-05这种零填充、无时区、无空格的格式，就得靠xs:pattern约束：
<xs:simpleType name="strictDate">
<xs:restriction base="xs:date">
<xs:pattern value="\d{4}-\d{2}-\d{2}"/>
</xs:restriction>
</xs:simpleType>
- 正则
\d{4}-\d{2}-\d{2}只匹配字面量，不解析语义，所以2023-13-01仍能通过——它只管格式，不管日期是否真实存在 - 别用
^和$：XSD的xs:pattern自动全匹配，加锚点反而报错 - 如果要连有效性（比如2月30日）也拦住，必须依赖解析器运行时校验，Schema层做不到
为什么xs:date校验失败时错误信息总说“invalid lexical value”？
这是XSD处理器的标准提示，意思是字符串没通过xs:date的词法解析规则，不是逻辑错误。常见触发场景：
- 输入含中文破折号或全角字符：
2023—10—05→ 失败（必须ASCII短横线） - 年份少于4位：
23-10-05→ 失败（xs:date要求至少4位年，支持负数年但不推荐） - 月份/日期没补零：
2023-9-5→ 失败（必须09和05） - 多了空格：
2023-10-05→ 失败（前后不可有空白，XSD不自动trim）
注意：这个错误和时区无关——哪怕你根本没写时区，只要格式不对，就卡在词法层。
Java JAXB或.NET XmlSerializer解析xs:date字段时日期变成本地时区？
不是Schema的问题，是绑定框架的默认行为。XSD规范里xs:date是“带时区偏移的日期”，但JAXB（XMLGregorianCalendar）和.NET（DateTime）在无时区输入时，会按本地时区解释为“当天0点”，导致序列化后多出+08:00之类。
- JAXB：用
XMLGregorianCalendar.toGregorianCalendar()前，先调setTimezone(0)强制UTC上下文 - .NET：改用
DateTimeOffset接收，再用.DateTime取无时区部分（但会丢失原始意图） - 更稳的做法：Schema层用
xs:string+xs:pattern，业务层自己parse——把校验和解析责任分开
用xsd.exe或xjc生成代码时，xs:date对应什么类型？
工具不会凭空发明类型，而是映射到宿主语言最接近的内置类型，但细节差异很大：
-
xsd.exe（.NET）：默认生成DateTime，但遇到2023-10-05Z会转成UTC时间，2023-10-05（无时区）则转成DateTimeKind.Unspecified，后续序列化可能补上本地偏移 -
xjc（Java）：生成XMLGregorianCalendar，保留原始时区信息；若想用LocalDate，得配jaxb2-basics插件+自定义绑定 - Go（
goxml等）：通常映射为string，因为time.Time必须有时区，而xs:date可无
关键点：生成的类型不等于你运行时想用的类型，中间常要手动转换。别假设生成代码能直接塞进数据库date字段——时区处理漏一点，凌晨数据就错一天。
