xml本身不能运行脚本，它只是纯数据格式；所谓“执行”实为外部程序解析时主动操作，风险源于解析器配置不当（如开启外部实体），而非xml规范本身。
XML 文件本身不能运行脚本，也不具备执行能力
XML 是一种纯数据格式，和 JSON、YAML 一样，只负责结构化地描述信息。它没有解析器内置的执行逻辑，也不会自动触发 eval、exec 或任何系统调用。所谓“XML 运行脚本”，其实是外部程序（比如浏览器、Java 应用、Python 脚本）在读取 XML 后，根据其中内容主动去执行某些操作——责任不在 XML，而在读它的代码。
为什么有人觉得 XML “能执行脚本”？常见误解来源
这种错觉通常来自几个典型场景，本质都是 XML 被当成了“配置+指令”的混合体：
- 某些老版 Web 应用（如早期 IE）支持
XML Data Islands，配合javascript:协议或内联<script></script>标签，但那是浏览器的扩展行为，不是 XML 规范的一部分 - 构建工具（如 Apache Ant）用 XML 写构建流程，
<exec></exec>标签看起来像在“执行”，实则是 Ant 解析到该标签后调用 Java 的Runtime.exec() - 攻击者利用 XXE（XML External Entity）注入，让 XML 解析器去加载外部 DTD，间接触发 HTTP 请求或读取本地文件——这属于解析器实现缺陷，不是 XML 本身有执行能力
哪些解析器/环境容易误踩“执行”陷阱？
真正危险的点，不在于 XML 是否能执行，而在于你用的解析器是否默认开启高风险功能：
- Python 的
xml.etree.ElementTree默认安全，但xml.dom.minidom或第三方库如lxml若启用load_dtd=True或resolve_entities=True，可能触发 XXE - Java 的
DocumentBuilder若未禁用外部实体（setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)），会解析恶意 DTD - PHP 的
simplexml_load_string()在旧版本中默认开启实体解析，libxml_disable_entity_loader(true)才算兜底
示例：一个看似无害的 XML 片段，在错误配置的解析器下可能读取 /etc/passwd：
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <data>&xxe;</data>
安全读取 XML 的底线操作
只要你不主动把 XML 当成代码来“执行”，它就是安全的数据容器。关键在解析端控制：
- 永远关闭外部实体解析：对
lxml用etree.XMLParser(resolve_entities=False)；对 Java 用setFeature("http://xml.org/sax/features/external-general-entities", false) - 避免使用已知不安全的解析方式，比如 PHP 的
DOMDocument::loadXML()不加防护就直接传入用户输入 - 如果 XML 来源不可信，优先考虑白名单字段校验，而不是依赖“过滤 script 标签”这类表面手段——XML 里根本不需要
<script></script>就能搞事
真正复杂的地方从来不是“XML 怎么写”，而是你用的那行 parse() 调用背后，到底打开了多少解析器的隐藏开关。
