Python ElementTree 查找 XML：标签看起来叫 item，为什么 find 仍返回空
看到的短名字，不是完整身份
从接口拿到一份 XML，肉眼能看到 item，代码 root.find("item") 却返回 None，很容易先怀疑编码或文件没有读完整。如果元素声明了默认命名空间，解析后的标签身份包含命名空间 URI 和局部名称。查找只提供短名字，就相当于在询问另一个没有命名空间的元素。
本文使用 Python 3.12.14 的 ElementTree，代码保存为 demo.py 即可运行。输入是写在程序里的固定 XML，不读取外部文件。示例特意让元素、普通 id 属性与带前缀的 m:id 同时出现，以免把对元素成立的默认命名空间规则错误套到属性上。
检查解析结果，再写查询
ElementTree 会把带命名空间的名称展开为大括号包围的 URI 加局部名，例如 {urn:demo:stock}item。你可以直接用这种完整名称查找，也可以提供一个自选前缀到 URI 的映射。查询中的 s 并不需要在原文出现；它是代码这一侧的别名，真正匹配的依据仍是 URI。
AI概念示意图：外形相同的元素携带不同命名空间标记，普通属性保留自己的无前缀身份。图片不是XML编辑器截图。
import xml.etree.ElementTree as ET
xml = """<catalog xmlns="urn:demo:stock" xmlns:m="urn:demo:meta">
<item id="local-A" m:id="remote-A">
<name>茶杯</name>
</item>
</catalog>"""
root = ET.fromstring(xml)
ns = {"s": "urn:demo:stock", "meta": "urn:demo:meta"}
assert root.find("item") is None
item = root.find("s:item", ns)
assert item is not None
assert item.tag == "{urn:demo:stock}item"
assert item.get("id") == "local-A"
assert item.get("{urn:demo:meta}id") == "remote-A"
name = item.findtext("s:name", namespaces=ns)
assert name == "茶杯"
renamed = ET.fromstring(xml.replace("xmlns:m=", "xmlns:z=")
.replace("m:id=", "z:id="))
other = renamed.find("s:item", ns)
assert other is not None
assert other.get("{urn:demo:meta}id") == "remote-A"
print("expanded:", item.tag)
print("ids:", item.get("id"), item.get("{urn:demo:meta}id"))
print("name:", name)同叫 id 的属性可以并存
输出包含 expanded: {urn:demo:stock}item、ids: local-A remote-A 和 name: 茶杯。普通 id 没有前缀，因此直接通过 item.get("id") 读取；m:id 则要用其命名空间展开名。默认命名空间适用于所在范围内的无前缀元素，不会自动附着到无前缀属性。这正是例子中两个 id 不冲突的原因。
最后一个断言把原文前缀 m 换成 z，但保持 URI 不变，结果依旧读到 remote-A。这说明前缀只是局部写法，不适合拿来当稳定业务身份。若上游换了前缀而 URI 未变，按 URI 查询的代码可以继续工作；若 URI 真变了，应当按协议版本变化来处理，而不是悄悄忽略。
别为了查到数据就删掉命名空间
把所有标签的大括号部分剥掉虽然方便，却可能把两个不同词汇表中的同名元素合并。订单号和物流号都叫 id 时，错误读取会看起来十分合理。更稳妥的是记录预期 URI，为每种词汇表设置查询别名，并在必需元素缺失时显式失败。示例用 is not None 判断存在性，避免把元素是否有子节点与是否找到混为一谈。
ElementTree 的查找表达式只实现有限的 XPath 子集，不应直接搬入任意复杂 XPath。解析成功也不等于符合业务结构：数量、必填字段、允许的命名空间仍需另做验证。面对来源不可信的 XML，应查阅所用解析器的安全限制并限制输入规模；本地固定样本只用于验证名称解析，不证明一套外部文档接收流程已经安全完整。
调试日志可以先打印 root.tag、目标元素的 tag 和属性键列表，再与接口约定逐项对照，而不是不断尝试不同路径。示例只查根节点的直接子元素；若真实文件多包了一层容器，即使命名空间写对，也需要调整查找层级。把结构问题和名称问题分开验证，能避免为了命中一条结果就把查询放宽到整个文档，误取另一段业务记录中的同名字段。最终还应核对条目数量，确认没有因为层级或筛选条件丢失记录。
