standalone属性仅控制解析器是否加载外部dtd，设为"yes"时若doctype含system/public声明且dtd不可访问则硬性报错；"no"为默认值，解析器会尝试加载外部dtd。
XML standalone 属性到底影响什么
standalone 属性只影响解析器是否加载外部 DTD，不控制实体解析、命名空间或 Schema 验证。设为 "yes" 时，解析器会直接报错：如果文档声明了外部 DTD（DOCTYPE 中含 SYSTEM 或 PUBLIC），但又没提供本地副本，就抛 org.xml.sax.SAXParseException: Document is not standalone —— 这不是警告，是硬性失败。
常见错误现象：standalone="yes" 却在 DOCTYPE 里写了 SYSTEM "common.dtd"，而该文件不在 classpath 或当前目录；或者用 Java 的 DocumentBuilder 解析时没配 setValidating(false)，导致它强行尝试读 DTD。
-
standalone="no"是默认值，解析器会尝试加载外部 DTD（即使你没用到里面的实体或属性定义） -
standalone="yes"不代表“完全离线”，只是承诺：文档所有声明都已内联（如必须出现在内部子集里） - 如果 DTD 只用于注释或未被引用的参数实体，
standalone="yes"仍可能失败——解析器不“智能跳过”，它按规范必须检查 DTD 是否可访问
Java SAX/DOM 解析器对 standalone 的实际处理差异
OpenJDK 的 com.sun.org.apache.xerces.internal.parsers.SAXParser 严格遵循 XML 1.0 规范：遇到 standalone="yes" + 外部 DTD 声明，且无法定位 DTD 文件，立刻终止解析。而某些老版本 Android SAX（如 API 28 前）会静默忽略该属性，造成行为不一致。
使用场景：你打包一个 XML 配置文件进 jar，想确保它脱离 DTD 也能加载 —— 不能只改 standalone="yes"，还必须移除 DOCTYPE 中的外部引用，或把 DTD 内容合并进内部子集。
- DOM 解析器（
DocumentBuilder）默认开启 DTD 加载，需显式调用setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false) - SAX 解析器（
XMLReader）要禁用外部加载，得设setFeature("http://xml.org/sax/features/external-parameter-entities", false) - 哪怕
standalone="yes"，只要DOCTYPE存在且含外部标识符，Xerces 就会尝试打开网络或文件系统路径 —— 这可能触发安全策略拒绝或超时
standalone 和外部 DTD 的兼容性陷阱
最常踩的坑：以为删掉 DTD 文件、只留 standalone="yes" 就万事大吉。其实只要 DOCTYPE 声明还写着 SYSTEM "foo.dtd"，解析器就会去找这个路径 —— 无论你有没有真用到里面定义的任何东西。
性能影响很小，但兼容性风险高：Node.js 的 libxmljs 在 standalone="yes" 下遇到外部 DTD 直接 throw；Python 的 xml.etree.ElementTree 则完全无视 standalone 属性（它本来就不支持 DTD 解析）。
- 真正安全的做法：删除整行
DOCTYPE声明，或改成内联形式，例如]> - 如果 DTD 含条件节（
）或参数实体，standalone="yes"会直接非法 —— 这些特性只能出现在外部 DTD 中 - HTTP 服务返回 XML 时若带
standalone="yes"，但响应头Content-Type没设charset，某些客户端解析器可能因编码推断失败连带误判 standalone 状态
怎么验证你的 XML 是否真的满足 standalone="yes"
别靠肉眼检查。用命令行工具快速验：Linux/macOS 下跑 xmllint --noout --nonet --standalone yes your.xml。如果报错，说明要么有外部 DTD 引用，要么内部子集用了禁止的语法（比如 %pe; 参数实体引用）。
注意：--nonet 是关键，它阻止 xmllint 访问网络加载 DTD；去掉它，就算 standalone="no"，也可能因 DTD 不可达而失败 —— 这和 standalone 本身无关，是网络依赖问题。
- Java 里可用
SAXParserFactory.newInstance().newSAXParser()配合DefaultHandler捕获SAXParseException，但必须先关掉外部加载，否则异常来源不明确 - VS Code 的 XML 插件（如 Red Hat XML）会在编辑时标红
standalone="yes"+ 外部 DTD 的组合，但它不校验内部子集合法性 - 如果你的构建流程生成 XML，别在模板里硬写
standalone="yes"—— 应由生成逻辑判断是否真没引用外部 DTD，再动态写入
最容易被忽略的是：很多工具（比如 XSLT 转换器、Swagger Codegen 输出的 XML 示例）会自动生成 standalone="yes"，但保留原始 DTD 引用，结果一上线就崩。这属性不是装饰，它是一份契约，签了就得履约。
