简介：一份面向 Visual C++ 开发者的 XML 解析与读写原生源码包，强调无需安装任何第三方库即可编译运行，特别适合希望深入理解 XML 底层解析机制、愿意脱离框架依赖的 C/C++ 学习者，也适合需要在轻量级工程中快速集成 XML 读写能力的开发者参考。压缩包共 18 个文件、约 46KB，涵盖 7 个 C++ 源文件、5 个头文件、3 个 XML 样例文件，同时附有解决方案、项目工程配置与文本说明文档，源码、工程骨架与样本数据相互配套，可直接编译运行验证。已有 189 人浏览学习。内容围绕 DOM 节点遍历、属性读取、元素创建与追加、文本转义、序列化输出以及格式校验等 XML 处理完整流程展开，配合示例数据便于实际跑通并观察读写结果。整体体积小、模块边界清晰，既可作为原生 XML 编程的入门模板，也能在此基础上快速改造为轻量级数据交换组件。
1. 不装三方库，Visual C++读写XML到底靠什么
很多人一听到“Visual C++读写XML”，第一反应是去找TinyXML、Xerces-C++，或者NuGet上拉一个包，其实Windows系统目录里早就躺着一个能跑十几年的原生解析器——MSXML。它在系统里以COM组件形式存在，从VC++ 6.0时代就有，到现在的Visual Studio 2022都不需要额外安装三方库，也不存在Redistributable缺失的问题，直接调COM接口就能完成解析和序列化。这篇笔记就围绕“纯原生源代码”这个思路，讲清楚怎么用MSXML在VC++项目里读写XML，以及不想依赖第三方库时，哪些坑值得提前避开。适合那些需要快速集成、交付环境不能随意装运行时、或者被三方库许可证折腾过的开发者。
2. 用MSXML实现XML读取：从加载DOM到遍历节点的完整代码
2.1 为什么选MSXML而不是自己写解析器
在开始写代码之前，先回答一个最容易被问的问题：既然标题强调“纯原生源代码”，为什么不干脆自己写一个解析器？我见过不少同事用fgetc加状态机去啃XML，最后都在换行折叠、CDATA和实体转义上撞墙。一个合法的XML里可以出现<![CDATA[<not-tag>]]>这样的整段文本，也可以出现中这样的数字字符引用，自己的状态机很难把所有情况覆盖完，而且一旦遇到非UTF-8编码的输入，往往连第一个<?xml声明都读不对。
MSXML是Windows操作系统自带的COM组件，从Windows 2000之后的系统里都有它，不了解它的人总觉得这是“又引入一个依赖”，其实它本来就系统级存在。Visual C++项目里用#import指令就能引用它的类型库，不需要下载任何SDK包，也不需要在目标机器上装运行时，这正好符合“不装三方库”的约束。更重要的是，它原生支持XPath，能用一句selectSingleNode定位到几十层深的节点，这是手写解析器短期内赶不上的能力。
选型上我一般分两步：如果项目只需要读取、修改、另存XML，且文件在几十MB以内，DOM最合适，API简单、修改方便；如果文件超过百MB，或者要求边读边丢弃已经处理过的节点，再上SAX流式解析。下面的代码主要围绕DOM展开，因为这是日常最高频的场景。
2.2 初始化COM与加载XML文件的最小代码
先写一个最基础的加载函数。这里用#import <msxml6.dll>生成智能指针，代码看起来干净，也不用到处写Release。
#include <windows.h> #include <comdef.h> #import <msxml6.dll> using namespace MSXML2; bool LoadXmlFile(const wchar_t* filePath, IXMLDOMDocumentPtr& doc) { HRESULT hr = doc.CreateInstance(__uuidof(DOMDocument60)); if (FAILED(hr)) { printf("CreateInstance failed: 0x%08X\n", hr); return false; } doc->async = VARIANT_FALSE; VARIANT_BOOL ok = doc->load(_variant_t(filePath)); if (ok != VARIANT_TRUE) { IXMLDOMParseErrorPtr err = doc->parseError; printf("load failed: code=%ld line=%ld pos=%ld reason=%ls\n", err->errorCode, err->line, err->linepos, (wchar_t*)(_bstr_t)err->reason); return false; } return true; }CreateInstance(__uuidof(DOMDocument60))创建的是MSXML6.0的DOMDocument对象。__uuidof从#import生成的头文件里拿到CLSID，运行时会向COM注册表查询并创建实例。如果你用的是VC++ 6.0或者目标系统很老，可以把msxml6.dll改成msxml3.dll，并把DOMDocument60改成DOMDocument30，其余代码几乎一致。async必须设为FALSE，否则load可能立即返回而解析还在后台进行，下一个语句就开始访问空文档。
doc->load()接收的是_variant_t，这里传入文件路径。它内部会根据文件头BOM和XML声明自动识别编码，所以UTF-8、UTF-16、GB2312都能正确处理。返回的VARIANT_BOOL为TRUE才表示解析成功。失败时从parseError里拿错误码、行号和原因，这个信息后面调试会一直用到。
调用前务必初始化COM线程模型：
int main() { CoInitialize(NULL); // 每个使用COM的线程都要调用 IXMLDOMDocumentPtr doc; if (LoadXmlFile(L"test.xml", doc)) { printf("loaded OK\n"); } CoUninitialize(); return 0; }CoInitialize(NULL)默认把当前线程设为单线程单元（STA）。如果是在工作线程里解析，建议改用CoInitializeEx(NULL, COINIT_MULTITHREADED)，并且别忘了在函数末尾CoUninitialize()。这个初始化很容易漏，漏掉后CreateInstance会返回REGDB_E_CLASSNOTREG，让你误以为是MSXML没装好，其实是COM没启动。
2.3 遍历节点、读取属性与文本的写法
加载成功只是第一步，更常用的是把整棵树扫一遍。下面这个递归函数会打印每个元素、属性和文本节点，代码里用的都是DOM标准属性，不依赖具体文件名。
void WalkNode(IXMLDOMNodePtr node, int depth) { if (!node) return; if (node->nodeType == NODE_ELEMENT) { _bstr_t name = node->nodeName; for (int i = 0; i < depth; ++i) wprintf(L" "); wprintf(L"<%ls>\n", (wchar_t*)name); IXMLDOMNamedNodeMapPtr attrs = node->attributes; if (attrs != NULL) { for (long i = 0; i < attrs->length; ++i) { IXMLDOMNodePtr attr = attrs->item(i); _variant_t v = attr->nodeValue; v.ChangeType(VT_BSTR); _bstr_t attrVal = v.bstrVal; for (int j = 0; j < depth + 1; ++j) wprintf(L" "); wprintf(L"attr: %ls = %ls\n", (wchar_t*)(_bstr_t)attr->nodeName, (wchar_t*)attrVal); } } IXMLDOMNodeListPtr children = node->childNodes; for (long i = 0; i < children->length; ++i) { WalkNode(children->item(i), depth + 1); } } else if (node->nodeType == NODE_TEXT) { _variant_t v = node->nodeValue; v.ChangeType(VT_BSTR); _bstr_t text = v.bstrVal; if (text.length() > 0) { for (int i = 0; i < depth; ++i) wprintf(L" "); wprintf(L"text: %ls\n", (wchar_t*)text); } } }判断nodeType是最稳妥的方式，因为文本节点的nodeName返回的是#text，直接拿名称过滤会漏掉空白节点。attributes只对元素节点有效，但这里已经用NODE_ELEMENT保护了。属性节点的值是_variant_t，不能直接交给_bstr_t，先ChangeType(VT_BSTR)再取bstrVal，否则在64位编译下可能读取到错误的偏移量。这个细节我建议直接固化到自己的代码模板里，省得每次踩一遍。
如果你只需要某一层的节点，不需要递归，可以用childNodes配合item(i)来遍历。要注意MSXML里的IXMLDOMNodeList下标从0开始，和C++的习惯一致。
2.4 常用查询接口：selectNodes与XPath
以前我手写查找函数时，每次都要递归判断节点名，后来发现MSXML自带XPath，一句就能取代几十行循环。
void QueryItems(IXMLDOMDocumentPtr doc) { IXMLDOMNodeListPtr list = doc->selectNodes(_bstr_t(L"//item[@enabled='1']/name")); for (long i = 0; i < list->length; ++i) { IXMLDOMNodePtr nameNode = list->item(i); _bstr_t nodeText = nameNode->text; wprintf(L"name: %ls\n", (wchar_t*)nodeText); } }这里//item表示任意深度下的item节点，[@enabled='1']是属性过滤，/name取子节点。selectNodes返回的是所有匹配节点组成的集合，selectSingleNode只返回第一个。如果你的XML里带了命名空间，比如根节点写了xmlns="http://example.com/ns"，直接写//item会查不到任何内容。这时候需要先设置selectionNamespaces：
doc->setProperty(_bstr_t(L"SelectionNamespaces"), _variant_t(L"xmlns:ns='http://example.com/ns'")); // 然后用带前缀的XPath IXMLDOMNodePtr node = doc->selectSingleNode(_bstr_t(L"//ns:item[@ns:id='1001']"));setProperty必须在执行查询之前调用，命名空间前缀随便起，只要映射到正确的URI就行。MSXML对XPath的大小写是敏感的，Item和item是两个不同的路径，属性名也区分大小写，这个和在浏览器里写XPath的习惯不太一样，我在第一次用老生成的数据时吃过亏。
3. 原生写XML：构建节点、序列化到文件的三条路径
3.1 创建DOMDocument并构建根节点
读会了就得会写。很多项目里“写XML”不是把一段字符串直接丢进文件，而是要修改配置然后保存回去。用DOM创建文档和节点的顺序有讲究，先建文档，再建声明，最后建根元素。
IXMLDOMDocumentPtr doc; doc.CreateInstance(__uuidof(DOMDocument60)); IXMLDOMNodePtr decl = doc->createProcessingInstruction( _bstr_t(L"xml"), _bstr_t(L"version=\"1.0\" encoding=\"UTF-8\"")); doc->appendChild(decl); IXMLDOMElementPtr root = doc->createElement(_bstr_t(L"config")); doc->appendChild(root); IXMLDOMElementPtr item = doc->createElement(_bstr_t(L"item")); item->setAttribute(_bstr_t(L"id"), _variant_t(1001)); root->appendChild(item);createProcessingInstruction的第一个参数固定是xml，第二个参数是声明字符串，注意这里的引号要写成转义后的\"。声明节点必须通过appendChild挂在文档节点下，而且位置必须是第一个，否则输出文件不符合“先声明后根元素”的规范。createElement只能创建没有父节点的元素，最后用root->appendChild(item)把它挂到根下。DOM的好处是孩子顺序完全由append的顺序决定，不用手动维护标签闭合。
这段代码里我没有手动拼<config>之类的字符串，原因是MSXML会自动做转义。手动拼容易漏掉&和<，后面解析时会报“无效字符”之类的错误，排查半天才发现是数据本身带了特殊符号。
3.2 添加子节点、属性、文本的API顺序
给元素添加文本有两种做法，它们的副作用不一样，许多教程没提过这个区别。
// 方式一：创建文本节点后追加，适合混合内容 IXMLDOMTextPtr text = doc->createTextNode(_bstr_t(L"单价<100")); item->appendChild(text); // 方式二：直接设置text属性，会替换该元素下所有子节点 item->Puttext(_bstr_t(L"替换后的内容"));方式一借助createTextNode，文本里的<会被序列化成<，读回来时又是原始字符，这个过程MSXML自动完成。方式二Puttext是快捷方法，适合只保留纯文本的叶子节点。如果元素下面已经有子元素，先用Puttext会把它们全冲掉，所以要在没有其他子节点时使用。需要同时设置多个子节点或文本节点时，老老实实用appendChild按顺序加。
添加属性时要注意setAttribute的第二个参数是VARIANT，你可以传整数、字符串、布尔值。传字符串时必须包成_bstr_t，否则编译器会把它当成const wchar_t*之外的类型，导致匹配到错误的重载。写成item->setAttribute(_bstr_t(L"id"), _variant_t(1001))大家都能看懂，但如果传的是宽字符串，最好写成item->setAttribute(_bstr_t(L"name"), _variant_t(_bstr_t(L"demo")))，避免隐式转换的意外。
3.3 保存到文件的编码选择：UTF-8与GB2312
保存是写XML最直接的成败点。我遇到过很多次，代码里怎么写的都对，保存完中文全变问号，最后发现是XML声明编码和文件实际存储编码不一致。
HRESULT hr = doc->save(_variant_t(L"output.xml")); if (FAILED(hr)) { printf("save failed: 0x%08X\n", hr); }save到文件路径时，MSXML会读取文档里XML声明中的encoding属性，并按这个编码去写文件。所以只要在createProcessingInstruction里写了encoding="UTF-8"，保存出来的就是UTF-8。如果你写的是encoding="GB2312"，它会用系统代码页转成GB2312。没有声明时，MSXML会按系统默认ANSI代码页处理，在简体中文系统上可能是GBK，一旦换到英文系统保存，中文就乱了。
注意：
save到文件时会根据XML声明写编码，所以创建文档时就要把encoding写对。
还有一个容易被忽略的点：doc->xml属性返回的是UTF-16字符串。如果你在调试时把它直接写进一个ANSI文件，中文内容会变成类似“浣犲ソ”的乱码。所以不要拿xml属性绕过save自己去写文件，除非你明确知道自己在做编码转换。save方法自己处理编码，是性价比最高的做法。
3.4 流式写入：SAXXMLWriter与手动拼字符串的取舍
DOM适合中小型文档，但如果要生成几十万行的订单文件，把所有节点都建立为COM对象内存会很可观。MSXML还提供了一个SAX风格的写入器SAXXMLWriter，它不建DOM树，而是把开始标签、文本、结束标签逐段输出。这个方向需要自己管理状态的推进，代码量明显增加，常见做法是封装一个小类，在回调里把接收到的内容写到自己的std::wstring缓冲区。但说实话，如果只是写文件而不是做复杂转换，多数项目直接用DOM加save就够了，性能瓶颈通常在编码转换和磁盘IO，而不在DOM节点分配。
有一种情况我建议直接拼字符串：XML结构固定、数据量小、且要求零COM依赖的嵌入式或测试环境。比如生成一个只有两三个节点的简单配置：
std::wstring BuildConfigXml(const std::wstring& value) { std::wstring xml = L"<?xml version=\"1.0\" encoding=\"UTF-8\"?>\r\n"; xml += L"<config>\r\n"; xml += L" <value>"; xml += EscapeXml(value); xml += L"</value>\r\n"; xml += L"</config>\r\n"; return xml; }这里的EscapeXml需要自己实现，替换&、<、>、"和'。你自己拼字符串省掉了COM对象创建，但对转义、编码、换行风格都要负责。我不建议把这种方法用在无法预见内容的场景里，因为遇到注释、CDATA、处理指令时，手拼代码很快变成一团乱麻。标题既然写的是“纯原生源代码”，我更倾向于把它理解为“用系统自带的MSXML来读写，而不是非得自己解析”。
4. 纯原生实现的边界：大文件、编码、字符集与性能
4.1 大文件为什么不要用loadXML：内存与栈的坑
loadXML和load是两回事。loadXML接收一个包含完整XML文本的BSTR，也就是说你要先把整个文件读进内存，再传给MSXML，MSXML又会在内存里建立DOM树，等于文件数据被复制了两次。一个20MB的文件用ANSI读入变成40MB的宽字符，DOM树节点再膨胀几倍，轻松超过200MB。在小内存机器上，这种膨胀是你肉眼可见的卡顿来源。
我一般处理超过100MB的XML时改用SAX读取。MSXML的SAX2接口和Java里那套很像，注册一个内容处理器，在startElement和characters回调里处理当前节点，处理完就扔。这样内存里永远只有当前层级。代价是API使用复杂度高不少，且不能随机访问节点。如果你只需要提取某些字段，而不是修改后保存，SAX是稳妥选择。
下面是最小的SAX回调骨架，重点是告诉你接口签名，实际使用时还要实现所有纯虚函数才能编译：
class XmlHandler : public ISAXContentHandler { public: HRESULT STDMETHODCALLTYPE startElement( const wchar_t* /*namespaceURI*/, int /*namespaceURILength*/, const wchar_t* localName, int localNameLength, const wchar_t* qName, int qNameLength, ISAXAttributes* /*attributes*/) override { wprintf(L"start: %.*s\n", qNameLength, qName); return S_OK; } // startPrefixMapping, endElement, characters, ignorableWhitespace, // processingInstruction, documentLocator, resetState // 这些接口都要按声明实现并返回S_OK };用ISAXXMLReader的putContentHandler挂接上面的实例，然后parseURL或parse输入流。这个方案相比DOM省掉的是节点对象占用的内存，但你的处理函数里如果大量保存数据，内存也可能涨回去。所以SAX适合“读了就处理，处理完就丢”的流水线场景。
4.2 读写时最常见的编码翻车点：BOM、UTF-16、转义
先说BOM。MSXML从文件加载时，会读文件最前面的几个字节判断编码。UTF-8的EF BB BF它是认的，UTF-16的FF FE或FE FF它也认。但如果你用程序生成的XML文件没有BOM，同时文件里也没有<?xml encoding="...">声明，MSXML默认按UTF-8还是系统ANSI处理，这是一个历史包袱。稳妥做法是无论手动拼字符串还是用DOM创建，都明确写上encoding="UTF-8"，这样不依赖BOM。
再说UTF-16。loadXML接受的是BSTR，BSTR本身是UTF-16（Windows宽字符）编码。如果你从磁盘读到一个UTF-8的字节流，直接强转成const wchar_t*塞给loadXML，就会把每个字节对当成一个字符，中文直接变成乱码。正确做法是：要么用load传文件路径，要么自己把UTF-8字节流转成UTF-16的宽字符串，再调loadXML。许多“MSXML中文乱码”的求助帖，根源就在这里。
还有一个隐藏的坑是宽窄字符混合。MSXML的API全是宽字符，如果你项目里用了char*保存文件名或数据，必须用MultiByteToWideChar转成wchar_t*再传入。尤其是UTF-8的数据，直接赋值给_bstr_t会按ANSI转，得到的宽字符串是错的。我习惯封装一个Utf8ToWString的小函数，把所有外部输入统一成宽字符串后再交给MSXML。
转义问题容易被忽略的是CDATA。CDATA区块里的内容不需要转义<和&，但]]>这个字符序列仍然不允许出现。如果你用createCDATASection创建CDATA，内容里一旦包含]]>，序列化时会自动拆分或报错。另外属性值不能包含未转义的空白符和引号，DOM的setAttribute会帮你转义，但如果你用put_text设置文本再把它当属性导出，可能会漏掉。
4.3 性能对比：DOM、SAX、手动解析的实测结论
我没有办法在这里给出一个公认的数字，因为性能依赖文件结构、节点数量、编码和机器，但一个经验结论值得说：DOM在节点数小于10万时，解析耗时通常在几十毫秒到几百毫秒，而手动写的状态机如果只提取一个字段，可能只要几毫秒；一旦遇到大文件，DOM的浪费成倍放大，SAX则能保持平稳的内存曲线。
具体的取舍可以看这张表：
| 方案 | 内存 | 随机访问 | 修改XML | 适用场景 |
|---|---|---|---|---|
| DOM | 较高 | 支持 | 支持 | 配置文件、中小型数据交换 |
| SAX | 低 | 不支持 | 不支持 | 日志、大文件、流式处理 |
| 手写解析 | 最低 | 看实现 | 很难 | 固定结构、格式严格可控 |
看起来手写解析很诱人，但它的开发成本不只是写一个忽略空格的扫描器，还要处理实体表、CDATA、注释、DTD，甚至数字字符引用。我见过有人写了两个月解析器，结果遇到一个<!DOCTYPE声明就直接废了。选择手写解析之前，先确认你的输入集永远不会出现这些情况。
4.4 何时值得自己写一个极简解析器
有一种场景我会毫不犹豫地推荐手写：工具链里的“伪XML”。比如某些老旧系统输出的日志类似<record><time>2024-01-01</time><name>test</name></record>，没有命名空间、没有CDATA、没有实体，一行一条，格式严格。这时候用DOM建树反而是杀鸡用牛刀，用一个正则或者简单的字符串查找就能提取time和name。
但即使写极简解析器，也要处理两个基本问题：一个是被提取的值里可能包含<或&，必须验证它们不会破坏提取逻辑；另一个是文件里如果出现跨行的文本，使用逐行读取会出错。我会先把整个文件读进内存，然后逐个找<和>的索引，用std::wstring::find循环取子串。这种方法没有尝试处理自闭合标签和嵌套，所以只能用于扁平结构。最后还要在代码里留注释，说明这个解析器不能用于生产环境的通用XML，避免后来人拿它去解析任意文件。
5. 避坑指南：Visual C++读写XML的常见问题与排查
5.1 CreateInstance返回REGDB_E_CLASSNOTREG
现象：用MSXML6创建DOMDocument60时，CreateInstance返回0x80040154，中文错误信息是“没有注册类”。
原因：最常见不是MSXML没装，而是当前线程没有初始化COM。MSXML是COM组件，必须先CoInitialize。另一个次要原因是系统太老，Windows XP SP2之前没有MSXML6，或者安装的精简版系统把MSXML组件去掉了。
解决：在调用CreateInstance前先调用CoInitialize(NULL)，并检查返回值。如果确认初始化还不行，改用MSXML3：#import <msxml3.dll>，并把__uuidof(DOMDocument60)替换成__uuidof(DOMDocument30)。注意MSXML3和MSXML6的ProgID都不一样，代码里不要混用。
5.2 程序退出时内存不释放或卡住
现象：程序反复创建DOM文档处理XML，长时间运行后内存只升不降；或者退出时在COM对象释放阶段卡住几秒。
原因：DOM节点对象和文档对象存在循环引用，比如你取了doc->documentElement之后，又把这个元素挂到了另一个文档下，或者把节点的ownerDocument缓存到全局变量，导致引用计数无法归零。智能指针虽然能自动释放，但循环引用依然会让对象在全局析构阶段才被回收。
解决：用完节点后主动置空，尤其是全局或成员变量。nodePtr = NULL; docPtr = NULL;顺序上先释放子节点再释放文档。不要在函数退出前保留IXMLDOMElementPtr等局部智能指针的副本。另外，加载后立即把async设为FALSE也能避免后台线程持有文档引用。
5.3 解析后取到的文本前面带空格或乱码
现象：使用node->text读取元素内容，发现结果里混入了缩进的换行和空格；或者从属性值取出的字符串在转换为wchar_t*后显示乱码。
原因：text属性返回的是该元素下所有文本节点连接后的结果，包括格式化用的空白文本节点，例如<a>\n <b>x</b>\n</a>，在a元素上取text会得到“\n x\n”。乱码则是_variant_t转BSTR时没有ChangeType(VT_BSTR)直接读了bstrVal，或者把_bstr_t当成了窄字符输出。
解决：只对叶子元素调用text，或用node->childNodes->length判断是否没有元素子节点；对于属性值，先v.ChangeType(VT_BSTR); _bstr_t val = v.bstrVal;再使用。输出宽字符串用wprintf(L"%ls")，不要用printf("%s")，MSXML里全是宽字符。
5.4 保存文件后中文变成问号
现象：代码在调试窗口里看到节点内容都是中文，doc->save(_variant_t(L"out.xml"))写完，再用记事本打开变成“????”。
原因：XML声明没有写encoding，MSXML默认按系统ANSI代码页写文件。在简体中文系统上是GBK，记事本按UTF-8打开就会乱码；或者声明里写了encoding="UTF-8"，但实际系统代码页不是UTF-8，MSXML在编码转换时用替代字符填了问号。
解决：把声明写成version="1.0" encoding="UTF-8"，并确保保存路径文件本身没有以UTF-16的wchar_t字节直接写入。如果你自己用CFile写文件，要把宽字符串转成UTF-8字节再写，不要直接写wchar_t数组。最简单的验证方法：用十六进制编辑器看文件头，UTF-8无BOM时头部是3C 3F 78 6D，即<?xm，不应该出现FF FE字节序标记。
5.5 XPath查询结果为空，换一种写法又能查到
现象：同样的XML，用//item查不到，但用/*/*能查到；或者带属性过滤时结果为空。
原因：XML根节点声明了默认命名空间，所有子节点都属于某个URI，而XPath里的无前缀名称匹配的是空命名空间，所以查不到。这是XML解析最常见的边界问题，不是MSXML的bug。
解决：先打印根节点documentElement->namespaceURI，确认有值后，调用doc->setProperty(_bstr_t("SelectionNamespaces"), _variant_t(L"xmlns:def='" + 命名空间URI + L"'"));，然后用//def:item来查询。注意命名空间URI可能带单引号，赋值时如果字符串包含单引号，外层用双引号，否则会被解析器截断。
5.6 DLL里调用MSXML导致宿主进程崩溃
现象：在DLL里封装了一个XML读写函数，宿主程序调用了几次之后崩溃，或者第一次调用成功第二次就内存访问冲突。
原因：DLL加载时使用了静态链接的CRT，而宿主程序用的是另一套CRT，两边在释放COM字符串、BSTR时内存堆不一致。还有一种可能是DLL没有在DllMain里初始化COM，而是让每个导出函数自己CoInitialize，多个线程进来就乱了。
解决：DLL里尽量使用动态链接到MD运行时的配置；在每个导出函数内部自己CoInitializeEx，并配对CoUninitialize。如果DLL和宿主都调用了MSXML，不要把IXMLDOMDocumentPtr作为跨模块接口返回给宿主，而是封装成不透明指针。这个问题和MSXML本身关系不大，但表现为“在DLL里解析XML不稳定”，容易被甩锅给解析器。
6. 进阶调试与验证：用日志和最小用例锁定XML解析问题
6.1 写一个XML样本自检工具
当你手头有一批XML要解析，与其在业务代码里到处打日志，不如先写一个十几行的自检工具，把每个文件的结构和错误信息一次性输出。这个工具的核心就是前面第2章的WalkNode，再加一个统计节点数的计数器。
void DumpXmlFile(const wchar_t* path) { IXMLDOMDocumentPtr doc; if (!LoadXmlFile(path, doc)) return; wprintf(L"root: %ls\n", (wchar_t*)(_bstr_t)doc->documentElement->nodeName); WalkNode(doc->documentElement, 1); }如果文件很多，用FindFirstFile遍历目录，对每个文件调用DumpXmlFile，把输出重定向到日志文件。通过这种方式，我能在几秒内发现哪批文件里混入了非标准节点，或者哪个文件的编码和预期不符。自检工具的作用不是修bug，而是让你在修改主业务前知道输入到底长什么样，避免带着错误的假设排查。
6.2 用parseError定位错误行列
解析失败时，parseError里的line和linepos直接指向出错行列，但很多人只看了reason。reason经常是英文的“The character '', hexadecimal value 0x… cannot be normalized”，没有行列时根本不知道是哪个字符。这段代码可以放在所有load失败后：
IXMLDOMParseErrorPtr err = doc->parseError; wprintf(L"errorCode: %ld\n", err->errorCode); wprintf(L"line: %ld, linepos: %ld\n", err->line, err->linepos); wprintf(L"reason: %ls\n", (wchar_t*)(_bstr_t)err->reason); wprintf(L"sourceText: %ls\n", (wchar_t*)(_bstr_t)err->srcText);srcText返回出错行附近的原文，如果是一大行压缩的XML，这一行会很长，但至少能看到出错位置前后的片段。我习惯把这个错误转成字符串，拼进日志模块，而不是用printf输出到控制台，因为服务场景下控制台不存在。
6.3 一个教训
去年我维护过一个导出工具，反复出现“XML加载失败”的错误，当时只打印了错误码但没打行列，花了很长时间怀疑是MSXML版本问题。后来把line和linepos打出来，才发现是某个用户把属性值里的&写成了中文全角符号，导致XML格式不合法。从此之后我给自己定了一个规矩：任何load失败的地方，至少记录errorCode、line、linepos、srcText四样东西，少了任何一样都可能把排查方向带偏。这个习惯救过我很多次，也希望帮到你。
本文还有配套的精品资源，点击获取
