iterparse 比 parse 快因流式解析、常驻内存仅当前路径节点，但易内存爆炸；须在 end 事件中及时 clear() 并移除父引用，禁用 DTD/外部实体，注意 Python 3.12+ 的 BOM 和 events 显式要求。
iterparse 为什么比 parse 快，但容易内存爆炸
因为 iterparse 不是一次性加载整个树，而是边读边触发事件（start、end），理论上常驻内存只存当前路径上的节点。但很多人一不留神就写成“收到 start 就 append 到列表”，结果越积越多，最后 OOM。
- 必须在
end事件里及时调用elem.clear()，否则父节点一直持有子节点引用，GC 清不掉 -
iterparse返回的是 (event, elem) 元组，elem是实时的 Element 对象，不是快照 —— 同一个对象会被反复复用，不能缓存引用 - 如果需要保留某些字段，建议只提取文本或属性值（
elem.text、elem.get('id')），别存elem本身
如何安全提取特定标签（比如 <record></record>）并释放内存
目标不是“解析全部”，而是“流式捞出 record，处理完立刻丢”。关键在事件类型判断 + 精准清理。
- 监听
end事件，而不是start：只有end时elem才完整，且子节点已闭合 - 遇到
end且elem.tag == 'record'时处理数据，然后立刻调用elem.clear() - 同时对
elem的父节点调用elem.getparent().remove(elem)（可选，但更保险，尤其嵌套深时） - 别忘了在循环外显式删除
root引用：root = None，避免 lxml 内部缓存残留
for event, elem in etree.iterparse(file_path, events=('start', 'end')):
if event == 'start' and elem.tag == 'record':
# 可以提前设个标志，但不要在这里取数据
pass
elif event == 'end' and elem.tag == 'record':
process_record(elem) # 只读取需要的字段
elem.clear() # 必做
if elem.getparent() is not None:
elem.getparent().remove(elem)遇到 XMLSyntaxError: Premature end of data 怎么办
这不是编码问题，是 iterparse 对文件流太敏感：它假设 XML 完整、结构闭合。GB 级文件若被截断、压缩未解压、或网络传输中途断开，就会崩在这儿。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 先用
head -c 1000000 big.xml | tail（Linux）或 PowerShell 的Get-Content -Tail 100看末尾是否闭合了根标签 - 确认文件是纯文本 XML，不是 .gz/.zip 包裹的 ——
iterparse不自动解压，得先用gzip.open或zipfile.ZipFile解包再传给它 - 如果 XML 带 DTD 或外部实体，禁用解析器扩展：
etree.XMLParser(resolve_entities=False, no_network=True)
Python 3.12+ 中 iterparse 的兼容性注意点
新版 CPython 对 XML 解析器底层做了调整，iterparse 在某些边界场景行为更严格。
立即学习“Python免费学习笔记（深入）”；
- 不再容忍开头 BOM 字节（
\ufeff），会直接报XMLSyntaxError；打开文件时加encoding='utf-8-sig' -
events参数必须显式指定，不能省略，默认只返回end；老代码漏写events=('start', 'end')可能逻辑错乱 - 大文件下
iterparse的 CPU 占用略升，建议配合buffer_size=65536（默认 16KB）提升吞吐，但别超过 1MB，否则内存波动明显
实际跑 GB 文件时，最常卡住的不是语法，是“以为清了内存，其实没清干净”——elem.clear() 后还要确认父节点没偷偷留着引用，这点连 lxml 文档都写得含糊。
