etree.fromstring 直接传 bytes 会报错，因为它默认将输入视为 str 而非 bytes，导致内部用系统默认编码 decode 时出错；正确做法是显式指定 encoding 的 XMLParser。
etree.fromstring 为什么直接传 bytes 会报错
因为 etree.fromstring 默认把输入当字符串（str），不是字节（bytes）。如果你传的是 b'<root><a>1</a></root>'，它会在内部尝试用系统默认编码（比如 cp1252）去 decode，一碰到非 ASCII 字符或声明了 UTF-8 编码的 XML 就崩，典型错误是 UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0 或解析出乱码。
常见场景：HTTP 响应体、文件读取结果、socket 接收数据，这些原始来源基本都是 bytes。
- 别写
etree.fromstring(b'<xml></xml>')—— 这是错的 - 正确做法是显式指定编码，或先转
str再解析（但有风险） - 更稳的方式是用
etree.fromstring(xml_bytes, parser=etree.XMLParser(encoding='utf-8'))
如何安全解析带编码声明的 XML 字节流
XML 声明如 <?xml version="1.0" encoding="UTF-8"?> 是给解析器看的，但 etree.fromstring 不会自动读取它来决定解码方式 —— 它只认你传的 parser 参数。如果字节流里声明了 GBK，但你没配 parser，就可能解错。
- 始终显式创建带
encoding的etree.XMLParser，哪怕你“确定”是 UTF-8 - 编码必须和实际字节流匹配，不能靠猜；不确定时先用
chardet.detect()探测（但注意它不保证 100% 准确） - 示例：
parser = etree.XMLParser(encoding='utf-8'); root = etree.fromstring(xml_bytes, parser=parser) - 别依赖
xml_bytes.decode('utf-8')后再传给fromstring—— 中间 decode 失败就中断了，不如让 lxml 在 parser 层处理
和 etree.parse 的关键区别在哪
etree.parse 能直接读文件路径或 file-like object（比如 io.BytesIO），它内部会自己处理编码声明；而 etree.fromstring 是纯内存解析函数，不做任何 I/O 或编码推断。
立即学习“Python免费学习笔记（深入）”；
-
etree.parse('file.xml')→ 自动识别声明里的 encoding，并按需 decode -
etree.fromstring(open('file.xml', 'rb').read())→ 不识别声明，必须配 parser - 想用
fromstring但又想复用声明逻辑？先把字节流喂给io.BytesIO，再用parse：etree.parse(io.BytesIO(xml_bytes)) - 性能上，
fromstring略快一点（少一层封装），但差别微乎其微，别为这点优化牺牲健壮性
容易被忽略的 BOM 和空格问题
Windows 记事本保存的 UTF-8 文件常带 BOM（b'\xef\xbb\xbf'），HTTP 响应头有时也混入空白字符。这些字节出现在 XML 开头时，会让 fromstring 报 XMLSyntaxError: Document is empty 或 Start tag expected —— 因为解析器看到的不是 ，而是 BOM 或空格。
- 不要手动切片删 BOM（比如
xml_bytes[3:]），BOM 可能不存在，也可能不是 UTF-8 的 - 稳妥做法是用
etree.XMLParser(recover=True)，它会跳过开头非法字符（但仅限于真正无害的前置垃圾） - 更推荐在解析前标准化输入：
xml_bytes.strip()可去掉首尾空白，但 BOM 需要专门处理：xml_bytes.decode('utf-8-sig').encode('utf-8')（注意这会强制 decode/encode，仅适用于确定是 UTF-8 类编码）
真正麻烦的从来不是语法，是那些没报错但解析错节点、漏掉属性、或者看似正常实则编码错位的情况 —— 它们往往在测试环境不暴露，上线后才出问题。
