Element.prefix在HTML中无效，仅XML文档中可能有效；HTML解析器会丢弃命名空间信息，可靠标识是namespaceURI与localName。
Element.prefix 在 HTML 编辑器里基本没用
HTML 解析器（Blink/WebKit/Gecko）根本不管 prefix 属性。你用 document.createElementNS("http://www.w3.org/1999/xhtml", "html:div") 创建的节点，element.prefix 可能返回 "html"，但一旦插入到 document.body 或用 innerHTML 渲染，所有命名空间信息立刻被丢弃——html:div 变成 <div>，xmlns:html 消失，prefix 变成 null。
这不是 bug，是 HTML 规范明确要求的行为：HTML DOM 不支持命名空间前缀语义，只保留标签名和属性值。
- 在纯 XML 文档（
application/xmlMIME type）中解析时，prefix才可能有效 - 在 HTML 页面里动态操作 XML 片段，必须全程用
DOMParser+XMLSerializer隔离处理，不能混入 HTML DOM 树 -
element.prefix无法用于生成或校验输出格式；它只是解析时的副产品，且不可靠
想让编辑器输出带前缀的 XML？别碰 prefix，用 namespaceURI + localName
真正可控的是元素的 namespaceURI 和 localName。例如：<ns:item xmlns:ns="http://example.com/ns"> 对应的节点，element.namespaceURI === "http://example.com/ns"，element.localName === "item"。这是 W3C 标准定义的稳定标识，不依赖前缀。
编辑器要生成带前缀的 XML 字符串，得自己维护前缀映射表（比如 { "ns": "http://example.com/ns" }），然后在序列化时按规则插入 xmlns:ns 声明，并把 {http://example.com/ns}item 替换为 ns:item。
立即学习“前端免费学习笔记（深入）”；
- 浏览器原生没有“带前缀序列化” API；
XMLSerializer.serializeToString()输出的是无前缀的 QName（如<item xmlns="http://example.com/ns">） - 若需固定前缀（如强制输出
ns:item而非默认命名空间），必须手写序列化逻辑或借助lxml（Python）等外部库 - 不要试图通过设置
element.setAttribute("xmlns:ns", "...")来“修复”前缀——HTML 解析器会忽略它，XML 解析器只认声明位置（父元素）
ElementTree 的 register_namespace() 为什么在浏览器里不生效
ET.register_namespace() 是 Python xml.etree.ElementTree 模块的机制，只影响 ET.tostring() 的输出行为。浏览器里没有这个 API，也没有等价替代。JS 环境下不存在“注册命名空间前缀”这一概念。
如果你在前端项目里混用了 Python 后端生成的 XML 模板，要注意：后端用 register_namespace("ns", "http://...") 生成的 ns:item，前端 JS 读取时仍需用 getElementsByTagNameNS("http://...", "item") 查找，不能用 getElementsByTagName("ns:item")。
-
getElementsByTagNameNS()第一个参数必须是 URI，不是前缀；第二个参数是localName，不是带冒号的完整名 -
querySelector("ns\:item")在某些浏览器里可能“碰巧”工作，但不符合标准，且无法匹配命名空间属性 - HTML 编辑器里嵌入 XML 内容，最稳妥方式是作为字符串字段存取，不走 DOM 解析→修改→序列化流程
实际能用的方案就两条
要么彻底隔离 XML 处理（DOMParser → 修改节点 → XMLSerializer → 字符串回填），要么放弃前缀、只用 URI + localName 做逻辑判断。前者性能差但语义保真，后者轻量但输出不可控。
真正容易被忽略的点是：命名空间前缀只在序列化阶段有意义，且仅由生成方单方面决定。同一个 URI，在不同系统里可能对应 ns、gml 或 ns0，只要 URI 一致，就是同一命名空间——前缀本身没有语义价值。
