TreeBuilder 的 start()/end() 不被调用是因为默认未挂载自定义实例，须显式传入 XMLParser(target=YourBuilder())；nsmap 参数（3.8+）可获取前缀映射，但 tag 已展开不可逆；需调用 super().__init__() 并在 close() 中返回根节点。
为什么 TreeBuilder 的 start() 和 end() 不按预期调用？
因为默认 TreeBuilder 实际上不主动调用你重写的 start()/end()，除非你显式传入 builder=YourBuilder() 给 XMLParser——直接传给 ET.parse() 或 ET.fromstring() 是无效的。
常见错误现象：print 在 start() 里没输出，或者节点结构和预期不符；根本原因是 parser 仍在用内置 builder，你的子类完全没被挂载。
- 必须用
XMLParser构造时指定：parser = XMLParser(target=YourBuilder()) -
ET.fromstring(text, parser)和ET.parse(file, parser)才会真正走你的逻辑 - 别试图在
start()里修改self._root后直接返回节点——TreeBuilder的设计是累积构建，返回值会被忽略（Python 3.9+ 文档已明确说明）
如何让 TreeBuilder 支持命名空间前缀解析？
原生 TreeBuilder 不处理命名空间映射，start() 接收的 tag 是展开后的 `{namespace}local` 形式，前缀信息丢失。如果你需要保留 xs:element 这种写法，得自己从 attrib 或外部上下文提取前缀绑定。
使用场景：解析 WSDL、XSD 等强依赖前缀的 XML，且后续要生成带前缀的输出。
立即学习“Python免费学习笔记（深入）”；
-
start()的第三个参数nsmap（Python 3.8+）可拿到当前作用域的前缀→URI 映射字典，但仅当 parser 开启命名空间支持：XMLParser(ns_clean=True) - 低版本需手动扫描
attrib中形如xmlns:xs="http://..."的声明，并维护一个栈式前缀表 - 注意
nsmap是只读快照，不能靠它反推 tag 前缀——tag已被展开，前缀不可逆
TreeBuilder 和 ContentHandler（SAX）选哪个？
如果目标是轻量、流式、内存可控的解析，且不需要随机访问整棵树，TreeBuilder 是更自然的选择；但一旦你要做深度状态管理（比如嵌套条件判断、跨层级校验），SAX 的 ContentHandler 更清晰。
性能与兼容性影响：
-
TreeBuilder构建的是标准Element对象，后续可无缝用find()/iter()，但所有节点都保留在内存中 - SAX 不建树，适合 GB 级 XML，但你需要自己维护栈、记录位置、处理字符数据分片（
characters()可能被多次调用） -
TreeBuilder在 CPython 下由 C 实现加速，比纯 Python SAX handler 快；但自定义逻辑复杂时，C 层回调开销可能抵消优势
自定义 TreeBuilder 时最容易漏掉的初始化细节
TreeBuilder 子类必须显式调用父类 __init__()，否则 start() 返回的节点不会被正确拼接——你会得到一堆孤立节点，close() 返回 None 或意外根节点。
容易踩的坑：
- 忘记
super().__init__(**kwargs)，尤其当你加了自定义参数（如strip_whitespace=True）时 - 重写
close()却没返回最终根节点（必须 return 一个Element，哪怕只是self._root） - 在
start()中抛异常后，end()不再被调用，但close()仍会执行——状态清理逻辑别只放在end()
复杂点在于：TreeBuilder 的生命周期和 parser 强耦合，调试时看不到完整调用栈，出问题往往表现为“某段 XML 消失”或“节点层级错乱”，而不是报错。建议先用最小 XML + print 跟踪 start/end/data/close 四个方法的调用顺序。
