XML 校验器实际在检查什么
XML 校验器做的事情非常聚焦：读完一份文档，回答一个明确的问题——“这段文本算不算格式良好的 XML？任何一个合规的解析器读它会不会出错？”这是结构层面的问题，不是语义层面的问题。它不会知道 price 元素应该是正数、user 元素应该有邮箱、或者一份 feed 是否符合某家发布商的编辑规范。它检查的，是“在更高层的业务规则能开始判断之前，最起码要先成立的那一层”。
为什么“格式良好”是一个精确术语
W3C 的 XML 规范把“格式良好”定义成一组明确清单：必须有且只有一个根元素、每个开标签必须有对应闭合、嵌套不能交叉、属性值必须加引号、特殊字符必须转义、文件必须声明已知编码。违反其中任何一条的文档在定义上就不是 XML，哪怕它看起来很像。校验器的工作，就是把这个定义机械化执行，不让讨论降级成“反正我编辑器能打开”。
校验器实际执行的几条格式良好规则
知道是“哪条规则失败了”，错误信息才能真正帮上忙。下面每一条都对应一类“解析器一旦遇到就拒绝继续”的失败。
- 有且只有一个根元素。即便每个子树自己是格式良好的，并排出现两个顶层元素也不算 XML。
- 每个开标签都有匹配的闭标签，大小写一致、位置正确：开标签和闭标签必须严格对应，不可大小写不一致或位置错位。
- 嵌套不能交叉：必须严格“先开后闭”，不能先闭外层再闭内层。
- 属性值必须加引号，单双引号都行但必须成对。属性值不加引号是不被允许的。
- 文本和属性里的特殊字符必须转义：& 写成 &、< 写成 <、属性值里出现引号时用 " 或 '。
- 文件开头声明的编码（或 BOM/HTTP header 暗示的编码）必须与实际字节匹配。声明为 ISO-8859-1 的 UTF-8 文件，第一个非 ASCII 字节就会让解析报错。
一句话原则：先修第一个报错再说。顶部一个未闭合的标签，往往会在下面制造出一串看似无关、其实都因它而起的“假报错”。
如何使用这个工具
- 先在 XML 校验器 中准备一份有代表性的需要做结构校验的 XML 文档、订阅源和复制来的标记片段，不要一开始就处理最大或最敏感的真实内容。
- 执行处理流程并生成带首个 XML 结构错误提示的有效性结果后，优先检查闭合标签、嵌套顺序、属性、转义、命名空间，以及复制内容究竟是不是 XML 而非类 HTML 片段，再判断结果是否真的可用。
- 只有当结果已经适合用于订阅源调试、配置审查、导入 QA 和支持分诊，并且不再触发这条风险提醒时，才复制或下载输出：XML 格式良好只是第一道门槛，schema 或应用层语义仍需在别处继续验证。
XML 校验器 示例
这个 XML 校验器 示例使用有代表性的需要做结构校验的 XML 文档、订阅源和复制来的标记片段，展示生成后的带首个 XML 结构错误提示的有效性结果，便于你先确认闭合标签、嵌套顺序、属性、转义、命名空间，以及复制内容究竟是不是 XML 而非类 HTML 片段，再把同样设置用于真实输入。
示例输入
<item><name>ToolKit</name></item>
预期输出
Valid XML; root element: item四种常见错误以及校验器会怎样报
A) 标签未闭合
<book><title>XML in a Nutshell<author>Eckstein</author></book>
-> 遇到 </book>，但 <title> 仍未闭合
B) 嵌套交叉
<b><i>important</b></i>
-> </b> 与当前打开的 <i> 不匹配
C) 属性值未加引号
<a href=https://example.com>link</a>
-> 属性值必须加引号
D) 裸 & 符号
<title>Lock & Key</title>
-> 实体引用必须以 ";" 结束；你想写的是 & 吗？注意：这四类错误全部位于结构层，与文档主题无关——只关乎 XML 对标签、属性、实体写法的要求。
什么时候跑一遍 XML 校验最划算
XML 校验最划算的时机，是文件“即将脱手”的那一刻。一旦坏掉的 XML 进了订阅源、进了导入管线、进了合作方邮箱，修复成本会立刻翻一两个数量级。
- 发布 RSS/Atom 订阅源之前——一次解析失败就会让阅读器和索引方对这个源失去信任。
- 把 XML 报文发给 SOAP 接口或合作方接口之前，对方往往只回一句“解析失败”，没有行号——本地先校验能定位具体位置。
- 手工改完 Spring/Maven/Ant/Tomcat 这类配置文件后，一个漏闭合标签足以让下一次发布静默失败。
- 导出的 XML 在浏览器里看着没事，却被严格的导入器拒掉时，先用校验排除结构层问题，再去查业务规则。
- 排查 OOXML、SVG 这种以 XML 为容器的文件时——文件开头某个坏元素往往会让后续整段都解析不出来。
光看“格式良好”解决不了的事情
通过格式校验，只能保证“能被解析”。解析出来的树是不是下游期望的形状，是另一个问题、另一套工具的工作。提前理清这条边界，能省掉一场“它都通过校验了，为什么还不对”的争论。
- Schema 校验（DTD / XSD / RELAX NG）才会检查元素名、允许出现的子元素、属性类型、必填次数。格式良好层面这些都不会过问。
- 命名空间正确性：文档可以是格式良好的，但用错了命名空间 URI，下游按命名空间查询时会“一个节点都找不到”，却没有任何报错。
- 业务不变式——比如价格必须为正、日期必须早于今天——在 XML 的“是否合法”概念里完全不存在。
- 混合内容元素里的空白对阅读者有意义，但对校验器没有意义；文件能解析，但渲染出来可能和你预期不一样。
- 超大文档可能在实体展开（billion laughs）那一步就崩了，跟“格式是否良好”无关——安全加固和解析器加固属于另外一层。
格式良好与相邻的 XML 检查的对比
| 检查类型 | 回答的问题 | 什么时候跑 |
|---|---|---|
| 格式良好（本工具） | 任何合规的 XML 解析器能不能加载这份文件？ | 交付、导入或发布之前。 |
| Schema 校验 (XSD/DTD/RELAX NG) | 元素名、子元素、属性类型是否符合契约？ | 格式良好通过之后、业务使用之前。 |
| XPath / XQuery 抽查 | 某条路径能不能取到期望的节点？ | 排查具体 bug 或与合作方对接时。 |
| 业务规则校验 | 字段值是否合情合理（正价格、合理日期）？ | 在消费这份数据的应用里。 |
使用注意
- 复用带首个 XML 结构错误提示的有效性结果前，先检查闭合标签、嵌套顺序、属性、转义、命名空间，以及复制内容究竟是不是 XML 而非类 HTML 片段。
- XML 格式良好只是第一道门槛，schema 或应用层语义仍需在别处继续验证。
- 当结果会影响生产工作或客户可见内容时，应保留原始需要做结构校验的 XML 文档、订阅源和复制来的标记片段以便回退和核对。
XML 校验器 参考说明
XML 校验器 的参考说明应始终围绕需要做结构校验的 XML 文档、订阅源和复制来的标记片段、生成的带首个 XML 结构错误提示的有效性结果，以及用于订阅源调试、配置审查、导入 QA 和支持分诊前必须确认的检查点。
- 输入重点：需要做结构校验的 XML 文档、订阅源和复制来的标记片段。
- 输出重点：带首个 XML 结构错误提示的有效性结果。
- 复核重点：闭合标签、嵌套顺序、属性、转义、命名空间，以及复制内容究竟是不是 XML 而非类 HTML 片段。
参考资料
常见问题
以下问题围绕 XML 校验器 的实际用途整理，重点说明输入要求、输出结果和常见限制。在浏览器中校验 XML 语法并快速显示解析错误。
XML 校验器 最适合处理什么样的需要做结构校验的 XML 文档、订阅源和复制来的标记片段？
XML 校验器 的核心用途是在交给其他解析器前检查 XML 是否格式良好。当需要做结构校验的 XML 文档、订阅源和复制来的标记片段需要快速变成带首个 XML 结构错误提示的有效性结果，并继续用于订阅源调试、配置审查、导入 QA 和支持分诊时，它最有价值。
复用 XML 校验器 生成的带首个 XML 结构错误提示的有效性结果前，最该检查什么？
应优先检查闭合标签、嵌套顺序、属性、转义、命名空间，以及复制内容究竟是不是 XML 而非类 HTML 片段。这些细节最能直接判断结果是否已经适合继续交给下游流程。
XML 校验器 生成的带首个 XML 结构错误提示的有效性结果通常会被带到哪里继续使用？
最常见的下一步就是用于订阅源调试、配置审查、导入 QA 和支持分诊。这类输出是按真实交接场景来组织的，不是泛化占位结果。
什么时候不应该直接相信 XML 校验器 的结果，而要人工复核？
XML 格式良好只是第一道门槛，schema 或应用层语义仍需在别处继续验证。