处理TB级XML须用流式解析（SAX/StAX），配合分块定位、直写存储与多进程分治，杜绝DOM加载，核心是“流式+定位+直写+分治”。
处理TB级XML文件不能靠常规DOM解析，必须用流式解析（SAX或StAX）配合内存控制、分块处理和并行化策略。
用SAX或StAX做流式解析，不加载全文到内存
SAX是事件驱动、只读、单向遍历，内存占用恒定（通常几MB）；StAX支持拉模式，更易控制解析节奏。两者都不构建完整树结构，适合超大文件。
- Java推荐用StAX（javax.xml.stream），可跳过无关节点、提前终止、按需读取特定标签
- Python用xml.sax或lxml.iterparse（后者更灵活，支持clear()释放已处理元素）
- 避免xml.etree.ElementTree.parse()或minidom——它们会把整个XML载入内存，TB级直接OOM
按逻辑块切分+定位解析，跳过无用区域
TB级XML常有固定结构（如日志流水、交易记录），可结合字节偏移或边界标记分段处理，不逐行扫描。
- 预扫描文件，记录每个
起始位置（用二进制搜索或内存映射+正则匹配起始标签） - 用RandomAccessFile（Java）或mmap（Python）跳转到指定偏移，局部解析一段
- 对含命名空间或嵌套深的XML，优先用localName而非tagName匹配，减少字符串开销
边解析边写入目标存储，避免中间对象堆积
解析结果不缓存为Python dict/Java List，而是直写数据库、Parquet文件或Kafka，让I/O与CPU流水线并行。
- 每解析N条记录（如10000条）批量提交一次，减少事务/网络开销
- 用pandas.DataFrame.to_parquet()（列存压缩）替代CSV，节省磁盘和后续分析时间
- 若需索引查询，解析时同步写入SQLite或ClickHouse，利用其原生XML函数辅助校验
必要时用多进程分片，但慎用多线程
XML解析本身是CPU密集型且GIL敏感（Python）或存在锁竞争（Java SAX Handler），多线程收益低；多进程更适合物理分片。
- 将TB文件按字节范围切为多个50GB子文件（确保切在后），各进程独立解析
- 用GNU split -b或自定义脚本切分，避免破坏标签完整性
- 主进程只负责调度和合并结果，不参与解析——避免成为瓶颈
基本上就这些。核心是放弃“加载-处理”思维，转向“流式+定位+直写+分治”。工具只是手段，关键是根据XML实际结构设计解析路径——比如带id属性的扁平记录，比深度嵌套的配置类XML容易处理得多。
