不能用 xml.etree.ElementTree.parse() 直接加载超大XML，因为它将整个文件载入内存构建DOM树，2GB文件可能占用6–8GB内存，引发MemoryError；应改用xml.sax或iterparse()配合clear()和remove()进行流式解析。
为什么不能用 xml.etree.ElementTree.parse() 直接加载超大XML？
因为 parse() 会把整个XML文件读入内存构建成树状结构，一个 2GB 的 XML 文件可能占用 6–8GB 内存，触发 MemoryError 或让系统卡死。它适合几百MB以内、结构清晰的小文件，不是为流式设计的。
真正能应对 GB 级 XML 的只有两类方案：基于事件的 xml.sax 和基于迭代的 xml.etree.ElementTree.iterparse()。前者更轻量但编码稍繁琐；后者更 Pythonic，但必须手动清理已处理节点，否则内存照样涨。
iterparse() 必须配合 root.clear() 才有效
iterparse() 表面是“边读边解析”，但如果不主动释放已处理节点，内部 root 会不断累积子元素，最终和 parse() 一样爆内存。
关键操作是：在处理完某个完整业务单元（比如一个 <record></record>）后，调用其父节点的 clear()，并显式删除已无用的子引用：
- 用
events=("start", "end")启动iterparse() - 记录
start事件时的tag和elem，用于识别业务块起始 - 遇到对应
end事件时，立刻处理该elem，然后调用elem.clear() - 更重要的是：调用
elem.getparent().clear()（如果存在父节点），或定期对 root 调用root.clear()
context = ET.iterparse(filename, events=("start", "end"))
context = iter(context)
event, root = next(context) # 获取根节点
for event, elem in context:
if event == "end" and elem.tag == "record":
process_record(elem) # 自定义处理逻辑
elem.clear() # 清空当前 record 的子节点
# 防止 root 不断膨胀
if elem.getparent() is not None:
elem.getparent().remove(elem)
SAX 解析更适合只提取字段、不依赖嵌套结构的场景
xml.sax 是纯事件驱动，没有 DOM 树，内存恒定在几 MB 级别，适合日志提取、ETL 中的字段抽取等任务。但它不保存上下文，遇到嵌套同名标签（如多层 <item></item>）时，需自己用栈维护层级状态。
典型坑点：
- 忘记在
startElement()中调用attrs.getValue("attr_name")而直接用attrs["attr_name"]—— 会抛KeyError - 在
characters()中直接拼接文本，却没考虑 CDATA 或换行缩进，导致空白字符污染字段 - 没重置临时缓冲区（如
self._current_text = ""），导致不同元素的文本串在一起
性能与兼容性：Python 3.9+ 推荐优先用 iterparse() + defusedxml
iterparse() 在 CPython 下比 SAX 快 20–30%，且语法更贴近日常 Python。但注意：标准库的 xml.etree.ElementTree 存在 XXE 漏洞风险，生产环境务必替换为 defusedxml.ElementTree.iterparse()。
立即学习“Python免费学习笔记（深入）”；
安装：pip install defusedxml
使用时只需改导入：
from defusedxml.ElementTree import iterparse它会自动禁用外部实体、限制递归深度，避免解析恶意构造的超深嵌套 XML 导致栈溢出。
流式解析真正的难点不在语法，而在“何时清、清多少、清完还剩什么”。哪怕只漏掉一次 elem.clear() 或 parent.remove(elem)，内存就可能线性增长。调试时建议用 psutil.Process().memory_info().rss 实时监控，而不是等 OOM 才发现。
