xs:token会自动去除首尾空白并将内部连续空白（含制表符、换行符）压缩为单个空格，而xs:string不做任何空白处理；二者语义适用场景不同，且xs:token的空白处理不可通过whitespace facet覆盖。
xs:token 会自动 trim 和 normalize 空白，string 不会
这是最常踩坑的地方：你用 xs:string 声明一个字段，XML 里写了 " hello world "，解析后字符串就真带前后空格和中间多个空格；换成 xs:token，它会在验证/解析阶段自动变成 "hello world"——即去除首尾空白，并把内部连续空白（包括制表符、换行）压缩成单个空格。
实际场景中，比如配置项、用户名、URL 片段这类「语义上不该有冗余空白」的字段，用 xs:token 更安全；而日志文本、代码片段、base64 编码块等需要保留原始空白的，必须用 xs:string。
-
xs:token等价于 W3C 定义的「normalized string + trim」 -
xs:string是最底层类型，不做任何空白处理 - 部分 XML 解析器（如 Java 的 JAXB）在绑定到 Java
String时，对xs:token的处理可能依赖底层 DOM 或 StAX 实现，不一定完全一致
xs:token 对换行符和制表符也敏感
很多人只注意空格，忽略 xs:token 同样会把 \n、\t、\r 当作「空白字符」一并归一化。例如：
<name>Alice<tab><newline>Smith</newline></tab></name>
用 xs:token 声明时，最终值是 "Alice Smith"（<tab></tab> 和 <newline></newline> 被替换成空格）；用 xs:string 则原样保留。
- 如果你的 XML 数据来自用户粘贴（比如富文本编辑器导出），且内容含有意图的缩进或换行，别误用
xs:token - XSD 验证器（如 Xerces）报错
cvc-datatype-valid.1.2.1: '' is not valid with respect to the type 'xs:token'，往往是因为字段值全是空白（被 trim 后为空），而xs:token允许空字符串，但某些业务逻辑或后续解析器会拒收空值
xs:token 是 xs:string 的限制类型，不能反过来赋值
在 XSD 类型继承体系中，xs:token 是 xs:string 的派生类型（restriction），所以 XML 实例中，一个声明为 xs:token 的元素，其内容必须满足 xs:token 的空白规则；但反过来，声明为 xs:string 的字段可以接受任意空白形式的内容。
- 如果已有 XML 实例含大量冗余空白，又想加 XSD 验证，优先选
xs:string，否则验证直接失败 - 用
<simpletype></simpletype>自定义类型时，若基于xs:token再加 pattern 约束（比如邮箱格式），要注意 pattern 是在归一化后的字符串上匹配的 - 某些工具（如 XMLSpy）生成的 Java 类，默认把所有文本字段映射为
String，不会体现token和string的差异——这时业务层得自己补 trim 或校验
验证时 whitespace facet 对 token 无效
xs:token 的空白处理是硬编码行为，不受 whiteSpace facet 控制。你写：
<simpletype name="myToken"><restriction base="xs:token"><whitespace value="preserve"></whitespace><!-- 这行会被忽略 --></restriction></simpletype>
这个 <whitespace></whitespace> 根本不起作用。只有在基于 xs:string 或其他原子类型（如 xs:integer）做 restriction 时，whiteSpace 才有效。
- 想保留空白？只能用
xs:string，别试图“覆盖”xs:token行为 - 想强制非空+归一化？用
xs:token+<minlength value="1"></minlength>，比在代码里手动 trim 更靠前、更统一 - 不同解析器对「归一化时机」理解略有差异：有些在 DOM 加载时归一化，有些在 Schema 验证时，调试时注意看最终进入业务逻辑的字符串长什么样
事情说清了就结束
