SAX解析可避免GB级XML内存爆炸，应优先用xml.sax只提取必要字段，用栈维护路径；lxml.iterparse适合分块处理，需及时clear()和remove()；映射逻辑须与解析器分离，注意编码与非法字符处理。
用 SAX 解析避免内存爆炸
GB 级 XML 文件不能用 xml.etree.ElementTree.parse() 或 lxml.etree.parse() 直接加载——它们会把整个文档树载入内存，极易触发 MemoryError 或系统 OOM Kill。SAX 是唯一可行的起点，它基于事件流，内存占用恒定（通常仅几 MB）。
实操建议：
- Python 中优先用标准库
xml.sax，无需额外依赖；若需 XPath 式过滤，再考虑lxml.sax配合自定义ContentHandler - 不要在
startElement里缓存完整节点结构，只提取你真正需要的字段（如id、timestamp），其他一律跳过 - 遇到嵌套深、路径长的结构（如
<root><a><b><c><value>...</value></c></b></a></root>），用栈维护当前路径，避免字符串拼接判断 - 如果目标是转成 CSV 或写入数据库，直接在
endElement触发行级写入，别攒成大列表
按需提取子树：用 lxml.iterparse() 做轻量“分块”
lxml.iterparse() 不是全量加载，但比 SAX 更易控制粒度——它边读边构建局部元素，适合提取特定标签块（如每个 <record></record>）。关键在 events=('start', 'end') 和及时调用 elem.clear()。
常见错误现象：iterparse 后不清理，内存仍持续上涨，和普通 parse() 差别不大。
实操建议：
- 只监听
'end'事件，等一个完整<record>...</record>收尾后再处理，此时elem是闭合节点 - 处理完立即调用
elem.clear()，并手动删除其所有子引用：elem.getparent().remove(elem)（尤其当父节点还很大时） - 避免对
elem调用etree.tostring()——这会复制整棵子树；改用elem.findtext('field')或elem.attrib.get('id')直接取值 - 若 XML 有命名空间，必须在
iterparse前用etree.register_namespace()，否则find()失效
映射逻辑别写死在解析器里
把字段提取规则（比如 “<user></user> 下的 name 映射到 full_name”）硬编码进 ContentHandler 或 iterparse 循环，会导致后续加字段、换目标格式（JSON/Parquet/DB）时反复改解析逻辑，极易出错。
推荐做法是分离「定位」和「转换」：
- 定义一组路径规则，例如：
{'full_name': './/user/name/text()', 'created_at': './/meta/@ts'}，用lxml.xpath()执行（注意：只在已提取的<record></record>子树上调用，非全文） - 转换函数单独写，如
def parse_timestamp(s): return datetime.fromisoformat(s.replace('Z', '+00:00'))，解析器只负责传参 - 用
csv.DictWriter或sqlite3.execute('INSERT INTO ...', row_dict)接收统一字典，不关心字段怎么来的
别忽略编码与非法字符
GB 级 XML 常混杂编码声明不一致（如文件标 encoding="GBK" 但实际含 UTF-8 字节）、BOM、控制字符（\x00–\x08）、未转义 & 或 。SAX 会直接抛 <code>xml.sax.SAXParseException，iterparse 可能静默跳过或崩在 tostring。
实操建议：
- 打开前先用
file.seek(0); file.read(4)检查 BOM，用chardet.detect()粗略猜编码，再用codecs.open(..., encoding=xxx, errors='replace')强制解码 - 预处理阶段用正则剔除零宽字符：
re.sub(r'[\x00-\x08\x0b\x0c\x0e-\x1f]', '', line)（注意别破坏 XML 结构） - 对疑似非法字段值（如
text()返回None），补默认值或记录日志，别让单条脏数据中断整个流程 - 用
lxml.XMLParser(recover=True)替代默认解析器，它能容忍多数格式错误（但别依赖它修坏数据）
最麻烦的从来不是解析速度，而是某天发现第 12,345,678 条记录里有个 <note>cost & profit</note> 没转义，而你的映射逻辑把它切成了两个字段——这种问题只有在数据落地后才暴露，且无法回溯原始位置。留好原始行号（SAX 的 locator.getLineNumber()）和报错上下文，比优化 20% 解析时间重要得多。
