standalone="yes"表示xml文档完全自包含、不依赖外部dtd，若doctype中引用外部dtd则必须设为"no"，否则解析器报错；其值须与实际dtd使用一致，否则导致解析失败或行为不一致。

Standalone="yes" 表示 XML 文档不依赖外部 DTD

当你在 XML 声明里写 standalone="yes"，就是在告诉解析器：“本文件所有元素定义、实体声明、属性默认值等，都已内嵌或完全自包含，不需要读取外部 DTD”。这会影响解析器是否尝试加载 DOCTYPE 中引用的外部 DTD 文件。

常见错误现象：standalone="yes" 却在 DOCTYPE 里写了外部 DTD 引用（比如 ），多数严格解析器会直接报错，例如 Python 的 <code>xml.etree.ElementTree 抛出 xml.etree.ElementTree.ParseError: mismatched tag 或更明确的 standalone document declaration must be 'no' if external DTD is referenced。

• 如果文档没用任何 DTD 功能（没声明实体、没用属性默认值、没重定义元素内容模型），就该设为 standalone="yes"
• 只要 DOCTYPE 出现了 SYSTEM 或 PUBLIC 关键字，standalone 就必须是 "no"，否则解析失败
• standalone="yes" 能略微提升解析速度——解析器跳过外部网络/文件请求，也避免因 DTD 不可达导致超时

Standalone="no" 允许解析器加载并使用外部 DTD

standalone="no" 是默认值（即使不写 standalone 属性，效果也等同于 "no"）。它表示“请解析器按需加载并应用 DTD 中的定义”，比如展开   这类外部实体，或填充属性默认值。

使用场景：遗留系统中大量使用自定义实体（如 &company;）、需要基于 DTD 校验结构合法性、或依赖 DTD 提供的属性默认值（例如 <img src="x.jpg" alt=""> 中 alt 自动补空字符串）。

• 外部 DTD 文件路径不可达时，standalone="no" 可能导致解析卡住（HTTP 超时）或静默忽略（取决于解析器配置）
• Java 的 DocumentBuilder 默认会加载外部 DTD；若想禁用，得手动设置 setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false)
• Python 的 lxml 在 parse() 时默认加载外部 DTD；用 XMLParser(load_dtd=False) 可绕过，但此时 standalone="no" 就只是“名义上”的声明，实际没生效

standalone 属性和实际 DTD 使用必须逻辑一致

这个属性不是可有可无的装饰。它的值必须与文档真实依赖关系匹配，否则轻则解析失败，重则行为不一致——比如同一个 XML，在 A 解析器里成功展开实体，在 B 解析器里因为 standalone 声明冲突而拒绝处理。

容易踩的坑：

• 生成 XML 时硬编码 standalone="yes"，但模板引擎悄悄注入了 .. SYSTEM "...dtd">
• 用工具（如某些 XSLT 处理器）转换 XML 后，保留原 standalone 值，却删掉了 DTD 或改成了内嵌 DTD，导致声明失真
• 误以为 standalone="yes" 能阻止 DTD 加载——其实它只是个声明；真正控制加载的是解析器自身的安全策略（如禁用外部实体）

现代开发中 standalone 属性基本可以忽略

XML Schema（XSD）早已取代 DTD 成为主流校验机制，而 XSD 不受 standalone 影响；JSON 也在大多数新接口中替代了 XML。所以除非你对接的是老银行系统、EDIFACT 报文或某些工业协议，否则大概率不会主动写这个属性。

但如果你在日志里看到类似 ParseError: standalone document cannot contain DOCTYPE declaration，第一反应不该是改解析代码，而是检查 XML 源头——是不是构建流程里混入了 DTD 引用，或者模板拼接出了矛盾声明。

真正麻烦的从来不是 standalone 本身，而是它暴露出来的 DTD 依赖混乱和解析器策略不统一。