XML命名空间（Namespace）是W3C为了解决标签命名冲突而设计的一套机制。简单来说，它给XML中的元素和属性加了一个限定范围，让同名的标签在不同的范围里互不干扰。理解命名空间，是读懂很多配置文件、Web服务描述文档、数据交换格式的前提，比如Spring的配置文件、Maven的pom.xml、SOAP报文，里面到处都是命名空间的影子。
为什么需要命名空间：标签冲突问题
先设想一个很常见的场景。假设你在写一份订单系统与物流系统对接的XML数据，订单部分有一个name标签表示客户姓名，物流部分也有一个name标签表示快递公司名称。两套词汇表单独使用都没问题，可一旦合并在同一个文档里，解析程序就懵了：这个name到底是谁家的？
<order>
<name>张三</name> <!-- 客户姓名 -->
<shipping>
<name>顺丰速运</name> <!-- 快递公司 -->
</shipping>
</order>上面这个例子问题还不太严重，毕竟结构上能区分。但如果两个第三方模块定义了完全相同结构的标签，含义却完全不同，仅靠结构区分就彻底失效了。XML本身只要求文档格式良好（well-formed），并不要求标签名全局唯一，因此必须有一套机制从语法层面消除歧义，这就是命名空间诞生的原因。
命名空间的思路来源于Java的包机制和C++的namespace，本质上是把一个短标签名映射到一个全局唯一的标识符上。这个标识符通常采用URI的形式，因为URI具有天然的全局唯一性，由域名所有者保证不会重复。
xmlns属性：声明命名空间的语法
XML中使用xmlns属性来声明命名空间，语法上有两种形式。第一种是带前缀的声明，格式为xmlns:前缀名=URI，声明之后，文档中可以用"前缀:标签名"的方式引用该命名空间下的元素。
<root xmlns:ord="http://ipipp.com/order"
xmlns:ship="http://ipipp.com/shipping">
<ord:name>张三</ord:name>
<ship:name>顺丰速运</ship:name>
</root>第二种是默认命名空间，直接写xmlns=URI，不带前缀。声明之后，该元素及其所有未加前缀的子元素都归属于这个默认命名空间。默认命名空间的好处是可以让大部分标签省去前缀，文档更简洁。
<order xmlns="http://ipipp.com/order"> <name>张三</name> <amount>99.00</amount> </order>
有几点细节容易被忽略。第一，命名空间的URI只是一个唯一标识符，解析器不会真的去访问这个地址，它甚至可以不是一个真实存在的网址，写成urn:my:company:order这样的URN形式也完全合法。第二，前缀只是局部别名，真正决定元素身份的是URI本身，也就是说前缀可以随便起名，两个前缀指向同一个URI，元素就被认为是同一个命名空间下的。第三，声明命名空间的那个元素自身如果使用了对应前缀，它也在该命名空间内，声明的作用域覆盖该元素及其全部后代。
属性与命名空间：默认命名空间不管属性
这是命名规则中最容易搞错的一点：默认命名空间只作用于元素，不作用于没有前缀的属性。也就是说，即使你声明了默认命名空间，元素上不带前缀的属性依然属于"无命名空间"状态，除非显式给属性加前缀。
<order xmlns="http://ipipp.com/order"
xmlns:meta="http://ipipp.com/meta">
<name meta:source="APP" source="WEB">张三</name>
</order>上面的例子中，source属性不带前缀，它不属于任何命名空间，而meta:source属于meta命名空间。两者名字看似相同，实际上是两个完全不同的属性，可以共存于同一个元素上。这个设计看似奇怪，但它是W3C规范明确规定的，目的是保持与早期无命名空间XML文档的兼容性。
还有一个特殊的前缀xmlns本身，它被绑定到一个固定的命名空间上，用于声明其他命名空间，你不需要也不能手动声明它。
解析器如何处理命名空间：代码实战
理解概念之后，最好用代码验证一遍。以Java自带的DOM解析为例，如果启用了命名空间感知模式，就可以通过命名空间URI加本地名的组合来精确查找元素，彻底避免同名歧义。
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
// 开启命名空间感知，默认是关闭的
factory.setNamespaceAware(true);
Document doc = factory.newDocumentBuilder()
.parse(new File("order.xml"));
// 用命名空间URI加本地名查找，两个name不会混淆
NodeList names = doc.getElementsByTagNameNS(
"http://ipipp.com/order", "name");
System.out.println("订单name数量: " + names.getLength());注意setNamespaceAware(true)这一行，如果不设置，DOM会把ord:name当成一个整体标签名处理，命名空间信息全部丢失，很多初学者在这里踩坑。开启之后，getNodeName()返回带前缀的原始名称，而getLocalName()返回去掉前缀的本地名，getNamespaceURI()返回所属命名空间的URI。
在使用XPath时同样需要关注命名空间。如果文档中的元素带有命名空间，XPath表达式里的标签名也必须绑定命名空间才能匹配到，否则表达式看似正确却永远查不到结果。
XPath xpath = XPathFactory.newInstance().newXPath();
// 建立前缀到URI的映射关系
SimpleNamespaceContext ctx = new SimpleNamespaceContext();
ctx.bindNamespaceUri("ord", "http://ipipp.com/order");
xpath.setNamespaceContext(ctx);
// XPath中用前缀引用带命名空间的节点
Node node = (Node) xpath.evaluate(
"/ord:order/ord:name", doc, XPathConstants.NODE);
System.out.println(node.getTextContent());实际项目中的命名空间实践建议
在实际开发中，命名空间的使用有一些约定俗成的习惯值得遵循。首先，URI虽然没有解析器去访问，但建议使用你实际控制的域名路径，比如http://ipipp.com/schema/order，这样团队其他成员可以通过这个地址找到对应的文档说明或XSD定义，Spring的schema机制就是这么玩的，通过命名空间URI映射到本地的XSD文件。
其次，前缀命名要见名知义且保持一致。同一个命名空间在项目的不同文档中最好使用相同前缀，比如约定ord代表订单、cfg代表配置，避免出现同一份文档里同一URI使用了三四个不同前缀的混乱局面。虽然语法上合法，但会严重降低可读性。
最后，要不要使用默认命名空间需要权衡。纯数据类、只含一套词汇的文档，用默认命名空间更干净；而混合多套词汇、嵌套复杂的文档，带前缀的形式反而更清晰，一眼就能看出每个标签属于哪个模块。此外，在编写XSD校验文件时，targetNamespace必须与实例文档中声明的命名空间URI严格一致，一个字符都不能差，这也是集成联调阶段常见的错误来源。掌握了这些要点，命名空间就从一种令人困惑的语法负担，变成了组织XML结构、隔离模块词汇的有力工具。