xmldocument.createelement必须显式传入命名空间uri才创建带命名空间元素；不传则默认无命名空间，不继承根节点xmlns声明；带前缀需用三参数重载createelement(prefix, localname, Namespaceuri)。
XmlDocument.CreateElement 传入命名空间参数才生效
不传命名空间 URI，CreateElement 永远只创建无命名空间的元素，哪怕文档根节点已声明 xmlns。这是最常被误解的一点——命名空间不是靠“继承”或“默认”自动应用的。
必须显式传入命名空间 URI 字符串，且该 URI 必须与目标 Schema 中定义的完全一致（字符级相等，大小写敏感）。
-
CreateElement("foo")→<foo></foo>（无命名空间） -
CreateElement("foo", "http://example.com/ns")→<foo xmlns="http://example.com/ns"></foo> - 如果文档已有前缀绑定（如
xmlns:ns="http://example.com/ns"），仍需传 URI，不能传"ns:foo"
带前缀的元素名要拆开：本地名 + 命名空间 URI + 可选前缀
CreateElement 不接受带冒号的字符串（如 "ns:foo"）。前缀只是序列化时的显示提示，真正起作用的是命名空间 URI 和本地名。
若希望生成 <foo xmlns:ns="http://example.com/ns"></foo>，得用三参数重载：CreateElement("ns", "foo", "http://example.com/ns")。第一个参数是前缀（可空），第二个是本地名，第三个是 URI。
- 前缀参数可为
NULL或空字符串，此时不生成前缀，但元素仍属该命名空间 - 前缀不参与命名空间匹配，仅影响输出格式；同一 URI 下多个不同前缀是合法的
- 如果文档中未声明该前缀，
XmlDocument会自动在最近父节点插入xmlns:ns="..."
appendChild 后命名空间可能“丢失”或错乱
把带命名空间的元素插入到一个已有命名空间声明的父节点下，有时会发现前缀消失、URI 被重复声明，甚至子元素意外继承了错误的默认命名空间。
根本原因是 XmlDocument 在序列化时按需插入 xmlns 属性，而它只看当前节点及其祖先是否已声明相同 URI——不关心你“想不想显示前缀”。
- 避免手动拼接前缀字符串；始终用
CreateElement的三参数版本控制归属 - 插入前检查父节点的
NamespaceURI，确保父子命名空间逻辑一致 - 若父节点有默认命名空间（
xmlns="..."），子元素不传 URI 就会被归入该空间——这往往不是你想要的
用 CreateElement 创建带命名空间的子元素时，别忽略父节点的 NamespaceURI
很多 bug 出现在动态构建嵌套结构时：父元素用了命名空间 A，子元素却忘了传 URI，结果子元素被当成无命名空间节点，XSD 验证直接失败。
安全做法是，只要父元素有非空 NamespaceURI，子元素也应显式使用相同 URI（除非语义上确实属于另一空间）。
- 获取父节点命名空间：
parentNode.NamespaceURI（注意不是GetAttribute("xmlns")） - 子元素创建示例：
doc.CreateElement("child", parentNode.NamespaceURI) - 如果父节点命名空间为空（
null或""），而子元素需要命名空间，必须显式传入——不能省略
实际写的时候，最容易漏掉的是第三步里对父节点命名空间的检查和复用。一不留神，XML 看起来格式正确，但 XmlSchemaSet 验证就报 The element 'xxx' has invalid child element 'yyy'——因为命名空间不匹配，连类型都对不上。