XML 校验完整指南：XSD、DTD、API 与 CI 实战

你可能正遇到这些问题

如果你在搜“XML 校验”，大概率遇到过下面的情况：

• 本地看起来没问题，上线后却被下游系统拒绝
• 文件能解析，但结构不符合协议（元素顺序、根节点、属性值）
• 批量文件里只有 1~2 个错，人工抽查很难及时发现

这篇文章的目标很简单：给你一条可直接落地的流程，从单文件自检到 CI 自动阻断。

先给结论（5 分钟版）

按这个顺序做，基本不会错：

1. 先做 基础语法校验（闭合、嵌套、实体转义）
2. 再做 XSD 或 DTD 结构校验（二选一）
3. 发布前做 批量校验（任一失败即阻断）
4. 在 CI 里用 错误码 做判断，不要只匹配报错文案

👉 直接开始： 打开 XML 校验工具

第一步：先把“语法错误”清干净

先不要急着上 XSD/DTD。连语法都不合法，后续结构报错会很噪。

最常见错误示例：

<order>
  <item>Apple</item>
  <total>12.5</total>
</orders>

这里是根标签不一致（order vs orders）。

建议做法：

• 先跑基础校验，拿到行列位置
• 修完后再进入结构层（XSD/DTD）

第二步：XSD 和 DTD 怎么选？

一句话：

• 需要强类型、命名空间、复杂约束 → XSD
• 历史系统或轻量声明流 → DTD

什么时候更适合 XSD

比如你要明确约束：

• total 必须是小数
• 元素顺序必须固定
• 命名空间需要严格控制

什么时候更适合 DTD

你维护的是老系统协议，或者已有大量 DTD 规则，想低成本延续。

当前 DTD 校验可以覆盖：

• ELEMENT 内容模型（序列/选择/重复、EMPTY、ANY、mixed）
• ATTLIST 属性约束（#REQUIRED、#FIXED、枚举）
• 内部 ENTITY 引用解析

DTD 示例：

<!ENTITY cat "cooking">
<!ELEMENT bookstore (book+)>
<!ELEMENT book (title,price)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT price (#PCDATA)>
<!ATTLIST book category (cooking|children) #REQUIRED>

第三步：批量校验，别只看单文件

真实项目里，问题经常来自“99% 通过 + 1% 异常”。

所以发布前建议固定跑批量：

• 输入全量待发布文件
• 统计通过/失败数
• 保留逐文件错误明细

团队策略建议：fail-fast（有一个失败就阻断）。

第四步：接入 API，让 CI 自动把关

单文件接口示例

curl -X POST https://www.ilovedevtool.com/api/xml/validate \
  -H "Content-Type: application/json" \
  -d '{
    "xml": "<order><item>Apple</item><total>12.5</total></order>",
    "xsd": "<xs:schema .../>"
  }'

批量任务接口示例

curl -X POST https://www.ilovedevtool.com/api/xml/validate/jobs \
  -H "Content-Type: application/json" \
  -d '{
    "files": [
      {"fileName":"a.xml","xml":"<order>...</order>","xsd":"<xs:schema .../>"},
      {"fileName":"b.xml","xml":"<bookstore>...</bookstore>","dtd":"<!ELEMENT bookstore ...>"}
    ],
    "options": {"outputFormat":"all"}
  }'

注意：同一文件项中，xsd 与 dtd 建议二选一。

实战里最有用的错误码

建议把这些错误码直接接入 CI 规则：

• XML_INVALID
• XSD_INVALID
• SCHEMA_MISMATCH
• DTD_INVALID
• DTD_MISMATCH
• PAYLOAD_TOO_LARGE

为什么强调错误码？

• 报错文案更适合人看
• 错误码更适合自动化（稳定、可统计、可告警）

常见坑（建议直接贴给团队）

1) “最近更新”不是当前时间

看到“最近更新：2026-02-11”，它表示内容更新时间，不是系统当前时间。

2) 文件能 parse，不代表协议正确

“能解析”只是第一关。根节点、顺序、属性约束才是线上稳定性的关键。

3) 少量失败也会引发事故

不要因为通过率 95%+ 就忽略失败样本。线上事故往往从小比例异常开始。

4) 测试样本别带敏感数据

建议在样本和日志里统一脱敏，避免把生产字段暴露到协作环境。

可直接复制的上线前检查清单

• 基础语法校验通过
• XSD 或 DTD 校验通过（同一文件只选一种）
• 批量校验通过（失败数 = 0）
• CI 使用错误码阻断
• 关键报文样本做过回归

从现在开始怎么做

如果你今天就要落地，按这个顺序：

1. 打开 XML 校验工具
2. 查看 DTD 专项页
3. 查看 API 接入页
4. 下载样本做一次回归

你不需要一次做完全部。先把“语法 + 单文件结构校验”落地，第二步再接批量和 CI。