Expat解析器初始化失败主因是输入流开头非法（如BOM、空格），需确保传入UTF-8字节流且无前置内容；流式解析须设buffer_text=True并分块调用Parse(chunk, isfinal)，文本处理需手动累积，禁用ElementTree混用以防内存暴涨。
Expat 解析器初始化失败：xml.parsers.expat.ExpatError 一上来就报错
Expat 不会自动加载或校验 XML 声明，只要遇到格式不合法的开头（比如 BOM、空格、注释前置），就会立刻抛 xml.parsers.expat.ExpatError。不是你的 XML “内容”有问题，而是流还没进解析器，头就歪了。
- 确保输入源是纯 UTF-8 字节流（不是
str），且开头无 BOM：data.encode("utf-8")，别传open(...).read() - 避免用
StringIO或BytesIO包裹后二次读取——Expat 的Parse()要求一次性喂入完整 buffer，或配合buffer_text=True分块喂（见下一条） - 若 XML 来自网络响应，检查
response.content是否含 HTTP 头残留或 gzip 未解压
流式解析卡在 Parse()：如何分块喂数据而不崩
Expat 本身不支持“边读边解析”的 IO 迭代，所谓“流式”是指你控制数据块供给节奏，但必须显式管理 buffer 和解析状态。关键在 buffer_text=True 和 buffer_size 配合。
- 初始化解析器时加参数：
parser = xml.parsers.expat.ParserCreate(encoding="utf-8", buffer_text=True) - 每次调用
parser.Parse(chunk, False)，第二个参数设为False表示“这不是最后一块” - 最后一块调用
parser.Parse(last_chunk, True)，触发收尾校验 -
buffer_size不是缓冲区大小，而是内部文本节点缓存阈值（默认 8192），调大可减少字符串拼接开销，但不解决流控逻辑
回调函数拿不到完整文本：为什么 CharacterDataHandler 被反复触发
Expat 对文本节点不做合并，哪怕 <p>hello</p> 这种简单结构，也可能被拆成多次 CharacterDataHandler 调用——尤其当文本跨 CDATA、实体、换行或嵌套标签边界时。
- 不要在
CharacterDataHandler里直接处理业务逻辑；先累积到临时变量，等对应EndElementHandler触发时再统一取值 - 如果只关心某个特定标签的文本（如
<title>），用栈记录当前路径：self.path.append(name)入栈，self.path.pop()出栈，再判断self.path == ["root", "title"] - 注意：Expat 不解析实体（如
CharacterDataHandler收到的是原始字符序列，需自行替换
和 xml.etree.ElementTree 混用导致内存暴涨
Expat 是纯 C 实现、零对象分配的 SAX 式解析器，而 ElementTree 默认构建完整树。一旦你在 Expat 回调里偷偷调用 ET.fromstring(chunk)，等于把流式优势全丢掉，还多扛两份内存压力。
立即学习“Python免费学习笔记（深入）”；
- 别在
StartElementHandler里尝试用ET解析子片段——子片段未必是良构 XML，且 Expat 已经在帮你做语法分析了 - 如果真需要某段 XML 片段转为 Element，先用字符串切片提取（靠 start/end 标签位置），再喂给
ET.fromstring()，但要意识到这已脱离流式初衷 - 验证场景下，优先用 Expat 自带的
ExternalEntityRefHandler控制外部 DTD 加载，比ET的resolve_entities=False更底层、更省资源
Expat 的“流式”本质是控制权移交：它不帮你记状态、不缓存节点、不猜测意图。所有路径跟踪、文本聚合、错误恢复，都得你自己在回调里用几行变量搞定——写起来像写汇编，但跑起来真快。
