dtd不支持命名空间而xsd支持，这是最根本差异；xsd用xml编写，支持targetnamespace等机制，能精确约束多命名空间元素，且提供丰富数据类型、模块化和ide友好等优势。
DTD不支持命名空间，XSD支持
这是最根本的差异。如果你的XML文档里用了xmlns或带前缀的元素（比如<element></element>），DTD完全无法描述这种结构，解析器会直接忽略命名空间信息，导致校验失效。XSD本身就是用XML写的，天然支持targetNamespace、xmlns:xs等机制，能精确约束不同命名空间下的元素行为。
常见错误现象：Element 'foo' is not declared——明明在DTD里写了，但XML中写成<foo></foo>就报错，因为DTD根本不认ns:这个前缀。
- 使用场景：SOAP消息、WSDL、混合多个标准的XML（如SVG嵌入HTML）必须用XSD
- 参数差异：DTD没有“命名空间作用域”概念；XSD通过
elementFormDefault和attributeFormDefault控制元素/属性是否必须带前缀 - 兼容性影响：老系统（如某些嵌入式XML解析器）可能只支持DTD，但现代Java/.NET/Python库默认优先读XSD
XSD能定义数据类型，DTD只能分文本/子元素两类
DTD里所有内容本质都是字符串：PCDATA是文本，EMPTY或ANY是结构占位符，没法说“这个字段必须是日期格式”或“必须是0–100之间的整数”。XSD则提供xsd:integer、xsd:date、xsd:pattern等丰富类型，还能自定义restriction。
常见错误现象：用DTD校验<age>abc</age>不会报错，而XSD配了<simpletype name="ageType"><restriction base="xsd:integer"><mininclusive value="0"></mininclusive><maxinclusive value="150"></maxinclusive></restriction></simpletype>就会明确拒绝。
- 使用场景：金融报文、医疗数据交换要求字段语义严格时，XSD是刚需
- 性能影响：XSD类型校验比DTD多一层解析开销，但现代解析器（如Xerces、libxml2）已优化得不明显
- 容易踩的坑：XSD里
xsd:string默认允许空白字符，要严格匹配需加<pattern value="\S+"></pattern>
DTD语法独立于XML，XSD本身就是XML
DTD用的是自定义语法（、），不能被通用XML工具链处理；XSD文件本身是合法XML，可以用XPath查、XSLT转、DOM解析，甚至用xsd.exe或pyxb直接生成代码。
常见错误现象：想用Python的xml.etree.ElementTree读取DTD？不行——它只认XML格式，遇到..开头就报ParseError: not well-formed。
- 实操建议：团队已有XML处理流程（如CI中用
xmllint --schema校验），换XSD几乎零成本；换DTD反而要额外引入SGML兼容工具 - 维护成本：XSD可模块化拆成多个
<include></include>文件，DTD的引用容易因路径问题失效 - IDE支持：VS Code、IntelliJ对XSD的自动补全和错误提示远强于DTD
DOCTYPE声明和xsi:schemaLocation哪个生效？
当XML同时有和<code>xsi:schemaLocation时，解析器行为不统一：Xerces-J默认优先用XSD，.NET XmlReader需要显式设置ValidationType.Schema才启用XSD，否则只走DTD。这不是bug，是规范允许的实现自由。
常见错误现象：本地测试XSD校验正常，上线后突然不报错——检查发现生产环境的解析器配置没开XSD验证，退回到DTD逻辑，而DTD里漏写了某字段。
- 实操建议：永远显式指定验证方式，别依赖默认行为。Java里用
SchemaFactory.newInstance("http://www.w3.org/2001/XMLSchema")，Python用lxml.etree.XMLSchema加载XSD对象再校验 - 容易被忽略的点：XSD的
schemaLocation只是提示，真正加载哪个文件由解析器决定；如果网络不可达，部分解析器会静默跳过，不报错也不校验 - 调试方法：用
xmllint --noout --schema schema.xsd doc.xml 2>&1看实际触发的校验路径
