XML命名空间前缀重复时，解析器按最后声明的URI生效，导致元素识别失败；需检查前缀-URI映射唯一性、用API查实际URI、避免手动拼接、合并前重命名前缀；lxml中find()和xpath()对命名空间处理不同，须显式传入namespaces字典，且默认命名空间需用空字符串键；JAXB需正确配置@XmlSchema的namespace与elementFormDefault；ElementTree默认不解析xmlns，tag名含URI前缀，应使用本地名匹配或换lxml。
XML 解析时 xmlns 前缀重复导致元素识别失败
多个命名空间声明用了相同前缀（比如都用 ns），但指向不同 URI，解析器会按最后声明的生效，前面的被覆盖——这不是 bug，是 XML 规范行为。常见于拼接 XML 片段、动态生成或合并第三方接口返回内容时。
- 检查所有
xmlns:xxx声明，确认前缀和 URI 的映射是否唯一；不要依赖“先写先生效” - 用
getNamespaceURI("xxx")（Java DOM）、root.nsmap.get("xxx")（lxml）等方法实际查当前生效的 URI，别只看源码字符串 - 避免手动拼接带
xmlns的字符串；改用 API 添加命名空间（如Element.set("xmlns:ns", "http://a.com")） - 如果必须合并片段，先统一重命名前缀（如把所有
ns改成ns1、ns2），再合并
lxml 中 find() 和 xpath() 对命名空间敏感但处理方式不同
find() 默认不支持前缀，除非传入 namespaces 字典；而 xpath() 必须显式注册命名空间才能用前缀。不一致容易漏配，查不到节点还误以为数据丢了。
-
find(".//ns:tag", namespaces={"ns": "http://example.com"})—— 字典键是前缀，值是完整 URI -
xpath("//ns:tag", namespaces={"ns": "http://example.com"})—— 参数名和结构一样，但xpath()不接受默认命名空间（xmlns="..."）自动绑定 - 如果 XML 有默认命名空间（
xmlns="http://default.com"），必须在字典里用空字符串键：{"": "http://default.com"}，否则//tag也匹配不到 - 错误现象：返回空列表，但
etree.tostring(root)看起来结构完全正常
Java JAXB 解组时 @XmlSchema 的 namespace 和 elementFormDefault 配合问题
类上没配对好这两个属性，会导致字段反序列化为空，尤其当 XML 元素带前缀但 Java 类没声明对应命名空间时。
-
@XmlSchema(namespace = "http://a.com", elementFormDefault = XmlNsForm.QUALIFIED)表示所有元素都要带命名空间前缀才认；设为UNQUALIFIED则忽略前缀直接按本地名匹配 - 如果 XML 是
<ns:root xmlns:ns="http://a.com"><ns:item>val</ns:item></ns:root>，而 Java 类没加@XmlSchema或设了UNQUALIFIED，item就不会被赋值 - 包级注解必须放在
package-info.java，不是随便一个类上加就行；IDE 有时不提示这个文件缺失 - 调试时用
Unmarshaller.setEventHandler()捕获ValidationEvent，比单纯看 null 值更快定位哪个字段挂了
Python xml.etree.ElementTree 默认不处理命名空间，但可手动剥离前缀
它压根不解析 xmlns，所有带前缀的 tag 名（如 {http://a.com}item）会被转成带花括号的字符串，直接写 "item" 肯定找不到。
- 最简方案：预处理 XML，用正则删掉所有
xmlns:xxx="..."和xxx:前缀（仅限你完全信任输入且无歧义场景） - 标准做法：用
iterparse()+ 手动收集start-ns事件建映射表，再对每个 tag 做name.split("}")[-1]取本地名 - 更稳的是换
lxml，它原生支持命名空间字典，ET的兼容 API 也能用，没必要硬扛原生限制 - 注意：
find("item")在ET下永远不匹配<ns:item>，哪怕你删了声明——因为解析后 tag 已是{http://...}item
命名空间冲突的本质不是语法问题，而是「前缀只是别名，URI 才是身份」这个约定没被所有环节尊重。最容易被忽略的是：XML 文本里看着一样的前缀，在不同上下文（不同元素、不同文档片段）可能指向完全不同 URI，而解析器只认 URI，不记前缀历史。
