1. 先聊清楚2025年了为啥还要正经学 XML先把话放在前面如果你只在 JSON 和 YAML 里打转那你很可能低估了 XML 在现实世界里扎根的深度。我做 Python 开发这么多年真正促使我沉下心把 XML 从头到尾捋一遍的不是教科书而是接连几个项目里遇到的硬骨头对接德国某 PLC 时要从一大堆 XML 描述文件里抠从站配置、处理医学影像报告里带命名空间的 XML 报文、还有帮同事调试 Altium 离线插件装不上时那个XML parse error——这些场景跟“前端传个 JSON”完全不是一个量级它们要求的不是“能跑”而是精确、健壮、不挑食。XML 全称是可扩展标记语言Extensible Markup Language它和 JSON 最大的区别在于XML 是一种元语言你可以用它定义自己的标签语言。这意味着它天生适合描述结构极其复杂、约束极其严格的领域数据——比如金融报文FIX/ISO 20022、医疗标准HL7 CDA、工业自动化EtherCAT 从站 XML、PLC 工程配置、出版行业DocBook / TEI、甚至微软 Office 的.docx和.xlsx本质都是 XML 打包。换句话说只要你还得跟这些行业打交道Python 的 XML 处理就不是“会不会”的问题而是“够不够硬”的问题。这篇文章不打算讲那种“先装 lxml然后三行代码解析”的速成帖。我要做的是把 Python 标准库和 lxml 里真正常用的 XML 操作一整套捋清楚从文档结构、解析方式、命名空间这个最容易翻车的坑到流式解析超大文件、生成符合 Schema 的 XML、再到实际调试中的各种诡异报错。内容比较密集建议顺着读也可以根据目录直接跳到你需要的那一节。顺便说一声这篇文章用 Python 3.10 环境验证过所有代码均可在标准库xml.etree.ElementTree和第三方lxml上直接运行。两个库我会混着用但会明确说明什么场景用哪个。你不用担心版本兼容问题这两个库在 Python 3.6 之后的行为基本稳定。2. 动手前的底层认知XML 到底是怎么组织的2.1 一棵树而不是一列数据如果你用 JSON 习惯了“字典套列表、列表套字典”第一次看到 XML 可能会有种“这玩意儿怎么这么啰嗦”的感觉。但一旦你想明白它是一种树形结构的文本表达理解成本立刻降下来。看这段再简单不过的 XML?xml version1.0 encodingUTF-8? device iddev-001 nameServo Drive/name vendorInovance/vendor parameters param namespeed unitrpm1500/param param nametorque unitNm3.2/param /parameters /device把标签展开看它就是一棵树根节点device它有一个属性iddevice下面有三个子节点name、vendor、parametersparameters又往下挂了一个节点列表每个param有name和unit两个属性标签内部是文本1500、3.2这里出现 XML 的四个核心组成标签Tag、属性Attribute、文本Text、层级结构Hierarchy。任何 XML 操作说穿了就是在处理这四样东西之间的关系。2.2 文本和子节点远比想象中微妙新手最容易懵的一个点是一个元素里既有文本又有子节点怎么办比如description This servo supports protocolEtherCAT/protocol and protocolCANopen/protocol. /description严格来说description这个元素的.text是\n This servo supports\n 两个protocol子元素穿插在文本中间。ElementTree 会用tail属性记录某个子元素“之后”的文本也就是protocol的 tail。这个细节在生成 XML 或者做文本提取时特别容易踩坑后面我会专门讲到。2.3 有了 lxml 为什么还要学标准库 ElementTree很多教程一上来就推荐lxml这没错lxml确实快、功能全、支持 XPath 1.0 和 XSLT。但我强烈建议你先摸熟标准库的xml.etree.ElementTree后面简称 ET理由有三点零依赖任何 Python 环境自带不受网络和权限限制够用绝大多数日常解析、查找、修改、回写场景ET 都能胜任逻辑一致ET 的 API 设计非常像“Pythonic 的 DOM”你学懂了 ET再切 lxml 基本属于平移成本而 lxml 的优势在于解析速度和 XPath 表达能力适合复杂文档、超大文件、生产环境性能敏感型任务。所以我的建议是默认用 ET遇到性能瓶颈或复杂查询再升级 lxml而不是一上来就引入重武器。3. 解析 XML从文件、字符串到网络请求3.1 从文件解析先写个最常用的例子。假设上面那段设备 XML 存在device.xml里import xml.etree.ElementTree as ET tree ET.parse(device.xml) root tree.getroot() print(root.tag) # device print(root.attrib) # {id: dev-001} print(root.find(name).text) # Servo Drive这里有三个关键概念ET.parse(source)接收文件路径或文件对象返回一个ElementTree对象它代表整棵文档树.getroot()拿到根元素Element.find(tag)在直接子节点里找第一个匹配的标签找不到返回None注意find只找直接子元素不会递归查找。想递归找得用iterfor elem in root.iter(param): print(elem.attrib[name], elem.text)这条会输出speed 1500和torque 3.2因为它会把param上所有的后代节点全部捞出来。iter还有个常用玩法是不传参数那就遍历整棵树的所有节点。3.2 从字符串解析很多时候 XML 不是以文件形式存在而是接口返回的字符串。要用ET.fromstringxml_str devicenameServo Drive/name/device root ET.fromstring(xml_str) print(root.find(name).text)fromstring直接返回根元素没有tree包装。这意味着你如果需要用到tree.write()得自己ET.ElementTree(root)再包一层。3.3 从网络请求解析一个很容易犯的编码错误从 HTTP 接口拉 XML 时很多人会这么写import requests resp requests.get(https://example.com/device.xml) root ET.fromstring(resp.text) # 运气好能过运气不好就乱码问题出在编码上。resp.text是 requests 根据响应头猜测编码后解码出的字符串而 XML 文件第一行的encodingUTF-8或者其他编码才是正文真正使用的编码。万一响应头没给charsetrequests 可能猜成ISO-8859-1结果中文全变乱码。正确处理方式是用字节流resp requests.get(https://example.com/device.xml) resp.encoding utf-8 # 或者根据 XML 声明动态决定 root ET.fromstring(resp.content) # content 是 bytesET 能自动识别 XML 声明的编码ET.fromstring接收bytes时会根据 XML 声明里的 encoding 自动解码比直接传字符串靠谱得多。这个细节我至少见过三个同事栽过值得记住。3.4 常见解析异常有哪些解析 XML 最常见的异常是xml.etree.ElementTree.ParseError。它会在标签不闭合、编码错误、非法字符等情况下抛出。一个实用的调试技巧是捕获异常后打印出行号和内容片段from xml.etree.ElementTree import ParseError try: root ET.fromstring(xml_str) except ParseError as e: print(f解析失败: {e}) # 例如: not well-formed (invalid token): line 3, column 10通过异常信息里的行号和列号基本能定位到问题位置。如果你拿到一份 XML 怎么都解析不过优先用文本编辑器VSCode、Notepad打开看是不是标签没闭合、属性值少了引号、或者混入了非法控制字符。这些在 XML 里都是致命的。4. 查找与提取find、findall、iter 与 XPath4.1 三种查找方式的取舍ElementTree 提供三个层级递进的查找接口方法查找范围返回类型适用场景find(tag)直接子元素单个 Element 或 None找指定字段findall(tag)直接子元素列表遍历同层同名节点iter(tag)所有后代生成器深度递归查找举一个具体场景你要从一段 PLC 配置 XML 里提取所有axis节点的name属性names [elem.attrib.get(name) for elem in root.iter(axis)]如果你只关心某个group下的axis可以先用find定位到 group再在它的范围内itergroup root.find(.//group[idg2]) if group is not None: names [elem.attrib.get(name) for elem in group.iter(axis)]这里.//group是 XPath 的相对路径写法表示在整个树里递归查找group。idg2是属性过滤条件。4.2 XPath 其实不用专门学但要会用这几个很多人一听 XPath 就头大其实在日常 XML 处理里掌握几个模式就够了.//tag递归找所有tag.//tag[attrvalue]找所有tag且要求attr属性等于某值tag1/tag2从当前节点向下找直接的tag1/tag2路径.//tag[attr]找所有带attr属性的tag这些在 ET 里都支持不需要引入 lxml。ET 的 find 方法默认支持有限版 XPath也称为 ElementPath能用属性选择、子路径、通配符。但不支持完整的 XPath 1.0 函数比如contains()、text()也不支持索引[1]这种写法之外的复杂轴。真遇到复杂查询再上 lxml 的xpath()方法。from lxml import etree root_l etree.fromstring(xml_bytes) # 完整 XPath 语法 nodes root_l.xpath(.//param[contains(name, speed)])4.3 从 XML 提取数据到 Python 数据结构实际项目里把 XML 转成字典或对象是高频需求。一个通用的小函数可以这样写def elem_to_dict(elem): 把 ElementTree 的 Element 转成字典。重复子节点会聚合成列表。 result {} for child in elem: if len(child) 0: # 叶子节点存 text value child.text or if child.tag in result: if not isinstance(result[child.tag], list): result[child.tag] [result[child.tag]] result[child.tag].append(value) else: result[child.tag] value else: sub elem_to_dict(child) if child.tag in result: if not isinstance(result[child.tag], list): result[child.tag] [result[child.tag]] result[child.tag].append(sub) else: result[child.tag] sub return result注意这个函数丢掉了属性信息如果你想保留属性可以把child.attrib一并合入。工业场景里经常遇到的 XML 转 CSV/Excel基本都是这样先把树拍平再交给 pandas。5. 命名空间新手翻车重灾区也是实战分水岭5.1 为什么标签名带着前缀如果你解析过实际行业的 XML大概率会遇到这种ns0:FDC xmlns:ns0http://www.siemens.com/Simatic/XML/FDC ns0:Header ns0:TimeStamp2024-05-20T10:00:00/ns0:TimeStamp ns0:JobIDJOB-001/ns0:JobID /ns0:Header /ns0:FDC其中的ns0是命名空间前缀namespace prefix真正的标识符是http://www.siemens.com/Simatic/XML/FDC这个 URI。XML 设计者用命名空间来避免不同标准合并时标签名撞车。说白了它就像编程语言里的包名——仅写TimeStamp可能跟另一套标准里的TimeStamp重名加上命名空间就能区分。5.2 直接 find 的结果是 None为什么大多数新手在这个地方卡住root.find(Header) # 返回 None因为带命名空间的文档里元素的实际标签名是{http://www.siemens.com/Simatic/XML/FDC}Header而不是Header。ET 内部把命名空间 URI 放在花括号里作为 tag 的一部分。你可以打印一下确认root[0].tag # {http://www.siemens.com/Simatic/XML/FDC}Header所以查的时候必须带上完整的 URIns http://www.siemens.com/Simatic/XML/FDC root.find(f{{{ns}}}Header)5.3 用通配符偷懒但要小心副作用一个常见技巧是借用{*}忽略命名空间root.find(.//{*}TimeStamp)这在 ET 里是合法的.递归查找所有命名空间下的TimeStamp。但如果文档里存在多个命名空间下同名标签通配符会把它们混在一起可能取到不想要的那个。所以我建议只在快速调试时用通配符正式代码写全 URI。5.4 注册命名空间避免输出时出现 ns0这里必须说一个 ET 的反直觉坑。如果你用ET.fromstring读了一个带命名空间的文档然后修改、再tree.write()写出去大概率会看到输出里出现一堆ns0:前缀。原因是 ET 默认给未注册的命名空间自动生成ns0、ns1这样的前缀。解决方法是在写之前注册命名空间ET.register_namespace(fdc, http://www.siemens.com/Simatic/XML/FDC)这会告诉 ET遇到这个 URI请用fdc前缀。注册之后写出的 XML 就干净多了。如果是用 lxml默认会保留输入时的前缀这块体验好很多也是生产环境我更倾向 lxml 的原因之一。6. 生成 XML从零构造与修改回写6.1 手动构建一棵树有些场景需要你从业务数据生成 XML而不是解析已有文件。用 ET 构建一棵树的常规操作是root ET.Element(device, {id: dev-002}) name ET.SubElement(root, name) name.text Stepper Drive param ET.SubElement(root, param, {name: current, unit: A}) param.text 1.5 tree ET.ElementTree(root) tree.write(device_out.xml, encodingutf-8, xml_declarationTrue)这里几个要点ET.Element(tag, attrib)创建节点ET.SubElement(parent, tag, attrib)直接挂在父节点下文本赋值给.texttree.write()时务必指定encoding和xml_declaration否则可能写出没有 XML 声明的文件其他系统解析会出问题6.2 缩进和美化输出ET 在 3.9 之后提供了ET.indent(tree)可以格式化输出不用再手动拼缩进字符串了ET.indent(tree, space , level0) tree.write(device_out.xml, encodingutf-8, xml_declarationTrue)space参数控制缩进单位默认两个空格。输出效果是标准的层级缩进这在给别人看调试文件、或者做 diff 对比时非常有用。6.3 修改已有 XML 再回写解析→修改→回写是日常高频操作。比如你要把所有param的unit从rpm改成RPMtree ET.parse(device.xml) root tree.getroot() for param in root.iter(param): if param.attrib.get(unit) rpm: param.attrib[unit] RPM ET.indent(tree) tree.write(device_new.xml, encodingutf-8, xml_declarationTrue)这里有个细节修改文本内容时要注意子元素的tail如果你把带子元素的节点的.text整体替换可能会把子元素之间的文本覆盖掉。稳妥的做法是先想清楚你要操作的是哪个粒度。6.4 控制空元素自闭合还是不闭合ET 写出时默认把没有内容的空元素写成empty /。有些下游系统不认自闭合标签非得要empty/empty。这个可以通过short_empty_elementsFalse控制tree.write(out.xml, encodingutf-8, xml_declarationTrue, short_empty_elementsFalse)这个参数在对接某些老旧工业软件时非常关键一次我们对接某个检测设备对方解析器就是认死理只认成对标签改这一个参数就解决了。7. 生产级选择lxml 的硬核优势与典型用法7.1 什么时候必须用 lxml虽然标准库 ET 很能打但遇到以下情况我建议直接上 lxml文件超过几百 MBET 解析会非常吃内存需要完整 XPath 或 XSLT需要 Schema 校验XML Schema / RelaxNG需要保留原文档的注释、处理指令、DTD 等细节对解析速度有极高要求lxml 的 API 和 ET 非常接近迁移成本低from lxml import etree tree etree.parse(device.xml) root tree.getroot()7.2 用 XPath 提取多条件数据lxml 的.xpath()方法返回的是列表支持完整 XPath 1.0 语法。例如nodes root.xpath(.//param[unitrpm and position()1])这个例子里我用position()取了第一个匹配项。类似这种在 ET 里做起来很别扭在 lxml 里一行搞定。7.3 用 Schema 校验 XML工业对接场景里你的程序拿到 XML 后第一件事应该是“验货”。lxml 支持 XML Schema 校验from lxml import etree schema_doc etree.parse(device_schema.xsd) schema etree.XMLSchema(schema_doc) parser etree.XMLParser(schemaschema) try: root etree.fromstring(xml_bytes, parser) print(校验通过) except etree.XMLSyntaxError as e: print(校验失败:, e.error_log.last_error)这里的error_log.last_error包含错误行号、列号和具体原因调试效率非常高。说实话我后来处理 EtherCAT 从站 XML、Altium 插件配置这些场景全靠 Schema 校验在报错之前就拦截了一大批问题。7.4 流式解析超大文件有一种让人头疼的典型场景日志导出的 XML 有 1GB直接ET.parse()会把内存吃满机器卡死。这时要用迭代解析。ET 自带iterparselxml 也有对应实现import xml.etree.ElementTree as ET events [] for event, elem in ET.iterparse(huge_log.xml, events(start, end)): if event end and elem.tag record: # 处理单条 record process_record(elem) # 处理完就清掉避免累积 elem.clear()关键点是elem.clear()每处理完一个子树把它从内存中释放这样整棵树不会全部驻留内存。实测下来1GB 的 XML 用这种方式处理内存占用能控制在几十 MB 级别。iterparse的events参数可以监听start、end两个阶段。start是遇到开始标签时触发end是遇到闭合标签时触发。对大多数逐条处理场景用end就够了此时该元素的所有子节点都已经解析完毕。8. 大型 XML 的高效遍历iterparse 的参数细节8.1 root 参数别乱用ET.iterparse还有一个可选参数root可以指定从某个根标签开始监听。在某些场景下能减少一层if判断for event, elem in ET.iterparse(big.xml, events(end,), root(batch,)): if elem.tag record: ...它的含义是只有该元素在batch这个根下时才处理。但要注意root标签本身也会触发事件所以判断条件还是要写。8.2 控制事件流避免重复处理一个常见的坑用start和end同时监听时同一个元素会触发两次事件。如果处理逻辑里有副作用比如写库必须用event字段区分。反复踩过坑之后我的习惯是只监听end除非确实需要在闭合前拿到部分数据。8.3 巧妙利用 clear 与内存释放的组合elem.clear()只清空子元素和内容但父元素内部的某些缓存仍在。要彻底释放可以parent elem.getparent() if parent is not None: parent.remove(elem)在 lxml 里getparent可用ET 标准库的 Element 没有getparent方法只能靠自己在遍历时维护父节点引用或者用iterparse的回调里直接清叶子节点。这块算是两库的一个明显差异写通用代码时要注意。9. 常见坑位与调试经历那些让我抓狂又长记性的细节9.1 标签大小写不兼容XML 是区分大小写的。Device和device是两个完全不同的标签。这个规则跟 HTML 不一样HTML 标签不区分大小写但 XML 严格区分。写查找逻辑时一定要确认原文档的实际大小写最好直接打印tag检查。9.2 非法字符与编码炸弹从 Excel 复制内容到 XML 里常混入不可见控制字符比如\x00到\x08这些在 XML 1.0 里是不合法的。解决方案有两个读入前清洗字符串或者用 lxml 的解析器做容错parser etree.XMLParser(recoverTrue) # 跳过非法字符不中断 root etree.fromstring(xml_bytes, parser)recoverTrue是救命选项遇到非法字符会自动忽略而非报错终止。但这也意味着可能丢失部分数据所以仅用于应急不能作为常规方案。更稳妥的是源头清洗import re def clean_xml_text(text): # 移除 XML 1.0 不允许的控制字符 return re.sub(r[\x00-\x08\x0b\x0c\x0e-\x1f], , text)9.3 解析器安全防止 XXE 攻击一个必须强调的安全点如果解析的 XML 来自不可信来源一定要禁用外部实体解析否则可能被 XXEXML External Entity攻击读取服务器本地文件。标准库 ET 默认不解析外部实体相对安全。但 lxml 默认会需要手动关闭parser etree.XMLParser(resolve_entitiesFalse, no_networkTrue) root etree.fromstring(xml_bytes, parser)这条建议适用于所有接触外部输入的 Python 服务。不要觉得“我们内部系统不会有人攻击”之前某个对接供应商的系统里就有人偷偷在 XML 里塞了file:///etc/passwd的实体引用虽然没造成实际危害但看到报错时确实惊出一身汗。9.4 Altium 插件报错里那个XML parse error的启示热词里有一条 “altium 离线安装插件报错信息 xml parse error (expecting publishername but f”这其实是 XML 解析器的典型报错格式期望某个关键字/标签但遇到了别的内容。它的深层原因通常是 XML 文件头部声明与正文内容不匹配、或者版本不兼容导致标签名变化。处理这类问题我的排查顺序是用文本编辑器打开 XML看开头是否有 BOM 或不可见字符检查 XML 中是否混入了中文引号、中文逗号这类全角符号确认版本字段是否被改成了目标软件不认识的格式如果文件太大先截取片段用ET.fromstring单独验证这个思路同样适用于绝大多数“XML parse error”类报错。9.5 常见问题速查表现象原因解法find返回 None有命名空间tag 实际带 URI 前缀用{namespace}tag或{*}tag写出 XML 多了ns0:未注册命名空间用register_namespace注册中文乱码编码解码不一致用resp.content而不是resp.text内存暴涨一次性解析了超大文件用iterparseclear()解析报错行号不准文件里有 BOM 或特殊字符先用文本编辑器清洗接口返回解析失败上游返回的是 HTML 或其他格式先打印前 200 字符肉眼判断标签名带冒号是命名空间前缀不是普通标签不要直接当普通 tag 处理10. 从标准库到 lxml 的迁移实战如果你已经用 ET 写了一版解析代码现在要切换到 lxml最需要记住三处差异ET.Element对应lxml.etree.Element用法基本一样ET.SubElement对应lxml.etree.SubElement但 lxml 的 Element 额外有.xpath()、.getparent()、.getroottree()等方法一个实用的迁移技巧是在代码开头只替换 import 语句并给解析器加一层工厂函数try: from lxml import etree USE_LXML True except ImportError: import xml.etree.ElementTree as etree USE_LXML False这样模块内部既能用统一的etree.parse、etree.fromstring语义又能让代码在标准库环境下也能跑。不过要注意lxml 和 ET 的内部行为在tail、注释节点、DTD 处理上有差异迁移后必须重新跑一遍测试用例。11. 几个拿来即用的真实场景小配方11.1 配方一把 XML 转成 pandas DataFrame这个需求太常见了。我经常处理设备日志、PLC 配置点表它们往往埋在重复的 XML 节点里import pandas as pd import xml.etree.ElementTree as ET root ET.fromstring(xml_bytes) records [] for elem in root.iter(param): records.append({ name: elem.attrib.get(name), unit: elem.attrib.get(unit), value: elem.text }) df pd.DataFrame(records)思路是先把树“拍平”成字典列表再交给 pandas。如果字段很多可以配合前面的elem_to_dict批量转换。11.2 配方二批量修改 XML 里某个属性的值比如要批量把所有设备的vendor改成统一名称root ET.parse(devices.xml).getroot() for vendor in root.iter(vendor): vendor.text Unified Vendor Co., Ltd.11.3 配方三从 XML 提取信息并生成新 XML在对接工单系统时常常需要从上游 XML 提取关键字段再组装成下游格式。这个可以用f-string直接拼字符串但对于复杂结构建议还是用SubElement逐层构建至少能避免引号转义地狱。out_root ET.Element(Response) status ET.SubElement(out_root, Status) status.text OK data ET.SubElement(out_root, Data) for item in source_root.iter(item): node ET.SubElement(data, Item, {id: item.attrib[id]}) ET.SubElement(node, Value).text item.text11.4 配方四配置文件的 XML 解析封装实际项目里我习惯用类封装 XML 配置读取方便复用class XmlConfig: def __init__(self, path): self.tree ET.parse(path) self.root self.tree.getroot() def get_text(self, tag_path, default): elem self.root.find(tag_path) return elem.text if elem is not None else default def get_all(self, tag_path): return [e.text or for e in self.root.findall(tag_path)] def set_text(self, tag_path, value): elem self.root.find(tag_path) if elem is not None: elem.text str(value) def save(self, pathNone): ET.indent(self.tree) self.tree.write(path or config.xml, encodingutf-8, xml_declarationTrue)这样业务代码里就不用到处写解析逻辑了。12. 调试技巧大赏没有调试不了的 XML12.1 打印整棵树快速看清结构写完解析代码后第一件事永远是打印结构而不是上来就在节点里找来找去。一个简单粗暴的调试函数def dump_tree(elem, indent0): print( * indent elem.tag, elem.attrib, repr(elem.text)) for child in elem: dump_tree(child, indent 1)或者直接用 ET 内置的ET.dump(elem)它会打印元素及其所有子元素的层级结构。12.2 拿到报错先看行号列号无论 ET 还是 lxml解析报错都会给出行号和列号。比如not well-formed (invalid token): line 5, column 12这个行列号是从 1 开始计的定位到文本编辑器后重点看那一行有没有非法的引号、尖括号、以及缩进是不是用了混排的 tab 和空格。XML 对空白字符不敏感但标签内部的属性值引号必须是英文半角。12.3 用格式化工具辅助定位在调试阶段我经常把 XML 先粘贴到格式化工具里。格式化之后标签对应关系一目了然。如果格式化都报错那说明源头数据就有问题根本还没到 Python 出手的地步。12.4 XPath 调试三板斧调试 XPath 时最常用的办法是先在 Python 里小范围验证# 先确认某个路径存在 node root.find(.//div[classsection]/h3) print(node) # 如果找不到缩小范围搜索 all_tags [e.tag for e in root.iter()] print(set(all_tags)) # 看看实际有哪些标签拿到实际标签名之后再回头修正路径。这条思路帮我节省了大量瞎猜时间。13. 个人经验什么时候用 XML什么时候用 JSON最后说说我这些年形成的一个技术决策习惯。XML 和 JSON 不是替代关系它们各自有适用的场景。我的判断标准是数据结构高度递归、多重嵌套且行业里有成熟 Schema 标准选 XML数据扁平、自描述、面向 Web API选 JSON需要XSLT 转换、Schema 校验、跨系统语义互认选 XML追求极致简单、性能敏感、团队熟悉度优先选 JSON最常见的错误是Web 前后端接口场景硬上 XML结果前端解析起来痛苦不堪反过来工业集成场景硬用 JSON然后又发现没有 Schema 校验、没有命名空间隔离数据约束全靠写代码“自觉”。在 Python 里这两个格式的解析难度差距并不大。真要说难难度在于“你能不能把你手里的数据结构跟你对接的那套行业标准的语义正确对应起来”。XML 只是工具理解它的树形组织和命名空间规则才是进阶的关键。如果你现在正准备处理 EtherCAT 从站 XML、医疗 HL7、金融报文、CAD 工具配置这类场景这篇文章里的内容基本够用了。剩下的大头是你们行业特有 Schema 的具体语义那部分只能靠实际文档积累Python 操作层面你已经不需要再担心什么了。