whiteSpace 的合法值仅限 preserve、replace、collapse 三者；preserve 保留所有空白，replace 将换行制表符转空格，collapse 进一步压缩连续空格并去首尾空格；它需配合 pattern 或 minLength 等约束才生效，不独立触发校验。
xs:restriction whiteSpace 的合法值只有三个
不是随便写个字符串就能当 whiteSpace 值用的，XSD 规范硬性限定只能是 preserve、replace、collapse。写成 trim 或 ignore 看似合理，但解析器会直接报错——比如 Invalid facet 'whiteSpace': value 'trim' is not in the enumeration。
这三个值的行为差异很关键：
-
preserve：原样保留所有空白（包括换行、制表符、连续空格），适合日志、代码块等需要格式保真的场景 -
replace：把所有制表符和换行符替换成空格，但不合并空格，适合需要统一换行符但保留分词边界的文本 -
collapse：先replace再把连续空格压缩成单个空格，并去掉首尾空格，这是 HTML 渲染前最常用的清洗方式
whiteSpace 必须配合 xs:pattern 或 xs:minLength 才能观察到效果
单独声明 whiteSpace 不会触发任何校验或转换——它只是告诉解析器“等真正校验值时，按这个规则预处理”。如果你只写了 <restriction base="xs:string"><whitespace value="collapse"></whitespace></restriction>，XML 实例里传 " a b \n\t " 还是会被当成原始字符串通过，除非后续加了 xs:minLength 或 xs:pattern 等依赖实际字符内容的约束。
实操建议：
- 想验证
collapse是否生效？加个<minlength value="2"></minlength>，然后传" \t\n "（纯空白）——它会失败，因为折叠后长度为 0 - 想确认
preserve是否起作用？用<pattern value=".*\n.*"></pattern>匹配含换行的字符串，传入带\n的值才能通过 - 别指望
whiteSpace自动截断或报错，它不产生独立校验动作
不同 XSD 处理器对 whiteSpace 的实现有细微偏差
Java 的 Xerces 和 .NET 的 XmlSchemaSet 都支持全部三个值，但 Python 的 lxml 在 4.9.1 之前对 collapse 的首尾空格处理不一致；更隐蔽的是，某些老版本解析器（如早期 IBM WebSphere 内置解析器）会把 replace 错当成 collapse 处理。
这意味着：
- 跨平台部署时，必须在目标环境中实测空白输入，不能只看本地验证结果
- 如果 schema 要被多个系统共用，优先选
collapse——它是兼容性最好的，且行为最接近开发者直觉 - 避免在
whiteSpace="preserve"的字段上依赖长度校验，因为不同解析器对 Unicode 换行符（如\u2028）是否算“空白”的判断可能不同
whiteSpace 不影响 xs:enumeration 的字面匹配
枚举值比对发生在 whiteSpace 处理之后。也就是说，如果你定义了 <enumeration value="foo"></enumeration>，而 XML 里传的是 " foo "，即使 whiteSpace="collapse"，也不会匹配成功——因为枚举比对的是原始字面值，不是折叠后的结果。
常见错误场景：
- 前端表单提交时自动 trim 了输入，后端 schema 却用
preserve+enumeration，导致 “yes” 和 “ yes ” 被视为不同值 - 用
collapse本意是容错，但忘了枚举列表本身没做空白清洗，结果"active"和" active "在枚举里得写两遍 - 解决方案只有两个：要么枚举值也写成带空格的（不推荐），要么改用
xs:pattern模拟枚举逻辑，例如<pattern value=" *(active|inactive) *"></pattern>
空白处理规则本身很简单，但和枚举、长度、正则这些机制一叠加，就容易漏掉预处理时机这个关键点。
