defusedxml 不能直接用于 asyncio 因为其解析器均为同步阻塞式，会阻塞 event loop；需通过 run_in_executor 或 to_thread 在线程池中执行以实现真正并发，同时保留 XXE 等防护能力。
defusedxml 为什么不能直接用在 asyncio 里
因为 defusedxml 所有解析器（比如 defusedxml.ElementTree.parse、defusedxml.minidom.parse）都是同步阻塞的，底层调用 C 库或纯 Python 的 SAX/DOM 实现，会卡住 event loop。你如果在 async def 函数里直接调它，整个协程就“假异步”了——表面是 async，实际线程被 XML 解析独占，其他任务全得等。
常见错误现象：
– CPU 使用率低但响应延迟高（I/O 等着 XML 解完才继续）
– asyncio.wait_for 超时失败，但日志里没看到明显 I/O 阻塞点
– 并发启动 10 个解析任务，耗时 ≈ 单个耗时 × 10，毫无并发收益
怎么安全又真正并发地解析大 XML
核心思路：把耗 CPU 的解析动作挪到线程池里执行，让 event loop 继续跑别的事。同时确保 defusedxml 的防护能力不丢——不能为了并发换成原生 xml.etree.ElementTree，否则 XXE、billion laughs 这类攻击就回来了。
- 用
loop.run_in_executor(None, defusedxml.ElementTree.parse, file_path)，其中None表示使用默认线程池（避免自己管理ThreadPoolExecutor生命周期） - 文件路径必须是本地磁盘路径（
defusedxml不支持 URL 或流式 bytes 直接解析，除非你手动喂给defusedxml.ElementTree.fromstring） - 若 XML 来自 HTTP 响应，先用
aiohttp.ClientSession异步下载到bytes，再用run_in_executor+defusedxml.ElementTree.fromstring解析——注意传入的是bytes，不是字符串 - 别用
defusedxml.minidom做并发解析：它内存占用比 ElementTree 高得多，大文件容易触发 OOM，且线程池中多实例并行时 GC 压力明显
处理超大 XML 文件（>100MB）的实用技巧
ElementTree 全量加载会吃光内存。这时候必须放弃“整个文档 parse 完再处理”，改用事件驱动的 defusedxml.sax，配合 asyncio.to_thread（Python 3.9+）或 run_in_executor 封装 SAX handler。
立即学习“Python免费学习笔记（深入）”；
- 写一个继承
defusedxml.sax.handler.ContentHandler的类，在startElement/characters里提取你需要的字段，边读边存，不保留整棵树 - 不要在 handler 里做 await 操作——SAX 是同步回调，await 会报
RuntimeError: no running event loop；需要的数据先缓存到 list/dict，解析完再统一 await 写 DB 或发消息 - 用
defusedxml.sax.make_parser()替代原生sax.make_parser()，确保禁用外部实体和 DTD 加载 - 如果必须流式解析并实时处理（比如边解析边 yield 结构化记录），把 SAX 封装成异步生成器：在每次关键节点结束时，用
await asyncio.sleep(0)让出控制权，避免长时间霸占线程
并发数设多少才不翻车
不是越多越好。XML 解析是 CPU-bound，线程池默认大小通常是 min(32, os.cpu_count() + 4)。如果你开 100 个并发解析任务，线程池会排队，反而增加上下文切换开销，还可能触发系统级线程创建失败（Linux 默认 RLIMIT_NPROC 有限制）。
- 建议初始并发数 =
os.cpu_count()，观察 CPU 利用率和内存增长；超过 80% 就该降 - 对单个 >50MB 的 XML，别和其他 CPU 密集任务（如 JSON 序列化、加密）共享线程池，单独建一个带
max_workers=2的ThreadPoolExecutor - 用
asyncio.Semaphore控制并发上限比靠线程池更直观，例如：sem = asyncio.Semaphore(os.cpu_count())，每个解析任务前async with sem: - 注意
defusedxml的max_entity_expansions等参数虽能防爆栈，但设太小会导致合法大文件解析失败；建议按样本 XML 的实际 entity 数微调，而非全局硬编码
真正麻烦的从来不是“怎么写 async”，而是“哪个环节该切出去”和“切出去后防护还在不在”。XML 解析这种老派 CPU 密集活儿，async/await 只是调度层，底下的解析器和防护逻辑一点都不能松懈。
