嗨，我之前处理超大XML文件的时候也踩过标准库xml.etree.ElementTree（以下简称ET）这个iterparse的坑，太懂你这种内存一直涨的崩溃感了！

为什么内存会线性增长？ #

你现在用了elem.clear()、del elem甚至手动调用gc.collect()，但还是压不住内存，核心原因是标准库的ET.iterparse默认会保留元素的父节点引用——哪怕你清空了当前<record>节点的内容、删除了elem变量，它的父节点（比如包裹所有record的上层容器节点）依然持有这个节点的引用，这些没被彻底断开的引用会让GC根本没法回收这些内存，处理的节点越多，累积的无效引用就越多，内存自然就线性涨上去了。

怎么改进？ #

我给你几个针对性的优化点，亲测有效：

1. 只监听必要的事件

你的代码里同时监听了start和end事件，但实际上你只需要在<record>节点的end事件时处理数据，完全可以把iterparse的events参数改成只监听"end"，这样能减少一半的节点创建操作，一开始就能降低内存基线。

2. 彻底断开父节点引用

处理完<record>节点后，除了elem.clear()，还要主动让它的父节点移除对它的引用——这样就能彻底切断整个树结构对这个节点的关联，GC才能真正回收它的内存。

3. 优化GC调用频率

手动调用gc.collect()太频繁（比如每25000次就调用）反而会增加性能开销，建议把频率调高到50000甚至100000次，或者让Python的自动GC来处理，除非你能明显看到内存有小幅度的波动需要压制。

修改后的代码示例 #

把你的核心处理逻辑改成这样：

import xml.etree.ElementTree as ET
import zipfile
import gc

def process_big_xml(path_to_zip, path_to_xml):
    with zipfile.ZipFile(path_to_zip, "r") as z:
        with z.open(path_to_xml) as file_streamed:
            # 只监听"end"事件，减少不必要的节点创建
            context = ET.iterparse(file_streamed, events=("end",))
            processed_lines = 0
            for event, elem in context:
                if elem.tag == "record":
                    # 这里写你的数据处理逻辑
                    # ...
                    processed_lines += 1
                    
                    # 先清空当前节点的内容
                    elem.clear()
                    # 找到父节点并移除当前元素，彻底断开引用
                    parent = elem.getparent()
                    if parent is not None:
                        parent.remove(elem)
                
                # 调整GC调用频率，降低性能开销
                if processed_lines % 50000 == 0:
                    gc.collect()

关于lxml的补充 #

你说用lxml内存没问题但慢很多，大概率是你没用到lxml的高效处理API——比如lxml的iterparse可以配合clear()和remove()做更极致的内存优化，而且lxml的C扩展本身是比标准库快的，可能是你的处理逻辑在lxml里写得不够高效（比如用了纯Python的循环而不是lxml的内置方法）。不过如果你更在意性能，用标准库ET做上面的优化后，应该能在内存和速度之间找到平衡。

备注：内容来源于stack exchange，提问作者keyboardNoob