xml中所有&必须转义为&，否则标准解析器会报错；转义责任在生成方，应使用标准库序列化而非手动替换，避免双重转义或误改cdata/注释。
XML解析时遇到&报错：必须转义
XML里直接写&（比如price=10¤cy=USD）会触发解析失败，错误通常是org.xml.sax.SAXParseException: The entity "xxx" was referenced, but not declared或类似Invalid character in entity name。这不是编码问题，是XML语法强制要求——&在XML中是实体起始符，后面必须跟合法实体名（如&）或xx;数字引用。
- 所有
&必须写成&，哪怕它出现在属性值、文本内容、注释里 - 别依赖“看起来能过”：某些宽松解析器（如部分浏览器DOM解析）可能容忍未转义
&，但标准XML解析器（DocumentBuilder、lxml.etree、xml.etree.ElementTree）一律拒绝 - 如果XML来自外部系统（如API响应、日志导出），不能假设对方已转义；务必在解析前校验或预处理
用正则替换&风险高，优先走XML生成逻辑
手动用str.replace('&', '&')看似简单，但极易出错：可能误改CDATA块、注释、已有实体（比如把&变成&），导致双重转义。真正安全的做法，是从源头确保XML被正确序列化。
- 用标准库生成XML：Python用
xml.etree.ElementTree的tostring()、Java用Transformer、JS用DOMParser + XMLSerializer，它们自动处理&转义 - 若必须拼接字符串（不推荐），只对动态插入的文本内容调用对应语言的转义函数：
xml.sax.saxutils.escape()（Python）、StringEscapeUtils.escapeXml11()（Apache Commons Lang）、DOMImplementation.createDocument()（JS） - 避免对整个XML字符串做全局
replace——无法区分上下文，是多数线上故障的根源
ElementTree解析报ParseError: not well-formed的典型诱因
Python用户最常撞上的就是xml.etree.ElementTree.ParseError: not well-formed (invalid token)，十有八九是&没转义。但要注意，这个错误也可能由其他非法字符引发，比如控制字符（\x00-\x08）、未闭合的CDATA、BOM头等。
- 先用
file.read()[:200]检查报错位置附近的原始内容，确认是不是&直连字母/数字（如&id=1） - 用
xml.parsers.expat.ExpatError捕获更细粒度的错误位置（行号、列号） - 临时加一层容错：用
lxml.etree.fromstring(xml_bytes, parser=lxml.etree.XMLParser(recover=True))可跳过部分错误继续解析（仅调试用，生产环境禁用）
前后端协作时&转义责任必须明确
常见甩锅场景：前端说“后端给的XML没转义”，后端说“前端没按XML规范解析”。根本矛盾在于职责模糊。XML作为数据格式，转义责任在**生成方**，而非消费方。
- 后端输出XML时，必须保证所有文本内容、属性值中的
&已转为&；这是XML规范底线，不是可选项 - 前端收到XML后，直接交给标准解析器即可，无需二次转义或清洗——否则可能破坏本已正确的实体（如
<） - 若中间经过JSON中转（如
{xml: "..."}），注意JSON本身不处理XML转义，&仍需在嵌入前转义
最麻烦的情况是XML嵌套在另一个XML里（如SOAP Body里的XML字符串），这时需要双重转义：& → & → &。这种嵌套层级容易漏判，建议用专用工具校验结构合法性，别靠肉眼数&。
