XML命名空间是用URI唯一标识元素/属性词汇表的机制，解决同名异义问题；通过xmlns声明默认或带前缀命名空间，属性默认不属任何命名空间；需显式区分、统一约定URI并启用解析器命名空间支持。
XML命名空间（Namespace）是用来区分不同来源、相同名称的元素或属性的机制，本质是一个URI（通常是URL形式，但不强制要求可访问），用于唯一标识一组标签的“词汇表”。它不解决语义冲突，而是解决**名字重复但含义不同**的问题——比如两个文档都用 `
`，一个指文章标题，一<img src="//public-space.oss-cn-hongkong.aliyucs.com/keji/272.jpg" />个指职位头衔，命名空间就能让解析器知道它们属于不同上下文。
<h3>命名空间怎么声明和使用</h3>
<p>通过 <strong>xmlns</strong> 属性声明，可以是默认命名空间（无前缀）或带前缀的命名空间：</p>
<ul>
<li>
<font color="blue">默认命名空间</font>：`<book xmlns="http://example.com/book">`，该元素及其未加前缀的子元素都属于这个命名空间；</book>
</li>
<li>
<font color="blue">带前缀的命名空间</font>：`<book xmlns:a="http://example.com/book">`，只有带 <code>a:</code> 前缀的元素才属于该命名空间；</book>
</li>
<li>属性默认**不属于**任何命名空间，除非显式用前缀绑定（如 `<book a:lang="zh" xmlns:a="...">`）。</book>
</li>
</ul>
<h3>命名空间冲突的典型场景</h3>
<p>冲突不是XML报错，而是解析时无法准确识别元素归属。常见情况包括：</p>
<ul>
<li>多个Schema或DTD混用，都定义了 `<id>`，但一个表示用户ID，一个表示商品ID；</id>
</li>
<li>合并两个XML文档时，双方都用 `<config>` 作为根，但结构和语义完全不同；</config>
</li>
<li>在XSLT或XPath中查询 `<title>`，却意外匹配到另一个命名空间下的同名元素。
怎么有效解决命名空间冲突
核心思路是**显式区分+一致约定**，而非避免使用：
- 为每个业务域或文档类型分配唯一的命名空间URI（推荐用公司域名+路径，如
https://mycompany.com/ns/invoice）；
- 在文档顶层声明命名空间，并严格按前缀使用（如 `` 和 ``）；
- 解析时（如Java的DOM/SAX、Python的lxml、JavaScript的DOMParser），必须启用命名空间支持，并在XPath或查询中带上前缀或使用
local-name() 等函数；
- 生成XML时，避免省略已声明的前缀——即使有默认命名空间，也建议对关键元素显式加前缀，提升可读性和健壮性。
基本上就这些。命名空间本身不复杂，但容易忽略声明一致性或解析配置，导致“明明写了却没生效”的问题。
