Visual C++原生读写XML：不装三方库用MSXML搞定解析与生成

简介：Visual C++环境下使用纯原生C++代码解析与读写XML文件的完整源代码工程，面向希望在Windows平台不依赖第三方库处理XML的开发者。工程涉及DOM解析、SAX事件驱动、节点遍历与属性获取、XML特殊字符转义、序列化输出和错误处理等关键环节，并提供多份XML样例文件，整体流程从文档加载、节点遍历到序列化保存均有对应示例，便于对照理解XML底层机制。压缩包共18个文件，包含7个cpp源文件、5个头文件、3个xml示例、Visual Studio工程配置（sln/vcproj）及txt说明，整体仅46KB，目录结构精简、定位清晰。已有189人学习下载，适合初涉XML解析或想深入理解C++文件I/O与DOM模型的读者，也可作为课程设计或工具开发的参考起点。通过阅读和改造这套代码，可掌握不借助外部库完成XML文档创建、查询、修改、保存的完整思路，同时积累文件流处理与异常处理的实践技巧。

1. Visual C++ 不装三方库读写 XML：这个方案到底能干什么

接过一个老工程，里面还得用 Visual C++ 维护，Win32 桌面程序，功能里有一项是把 config.xml 读进来改几个节点再存回去。一开始想引 TinyXML，后来一看这项目从 Visual C++ 6.0 时代传下来的，头文件和字符集设定跟现代写法纠缠不清，引三方库反而要处理一堆连带问题。后来发现一个绕开所有麻烦的路子：直接用 Windows 系统自带的 MSXML 组件，通过 COM 接口做 XML 解析读写，代码全部写在当前工程里，不需要安装任何三方库，也不需要给客户机器单独装和 redistributable 有关的运行库。这个方案在 VC6 到 VS2022 上都成立，只要 Windows 还在，这套源代码就能编译能运行。这篇就把怎么搭、怎么读、怎么写、哪里容易翻车一次讲透。

2. 为什么选 MSXML 而不是 TinyXML：原生方案的真实边界

2.1 原生方案到底是什么：COM 接口背后的 XML 引擎

很多人一听“不装三方库”，第一反应是“自己写一个 XML 解析器”，那是把简单问题做复杂了。Windows 从 IE5 时代开始就内置了一个完整的 XML 解析引擎，叫 MSXML，一路演进到 6.0 版本，文件是 msxml6.dll，Win7 以后系统自带。Visual C++ 里只要包含 msxml2.h，再链接 ole32.lib 和 oleaut32.lib，就能直接以 COM 方式调用它，这套接口从 Visual C++ 6.0 到 VS2022 没有本质变化。

MSXML 能做的事比多数人以为的多：DOM 树的加载和遍历、XPath 1.0 查询、XSLT 转换、SAX2 流式解析、Schema 校验。日常说的“解析读写 XML 文件”，用它的 DOM 部分就完全覆盖了。整个过程不需要下载任何 SDK 扩展，不需要编译第三方源码，也不需要注册额外的 COM 组件，因为 msxml6.dll 本身就是操作系统的一部分。

这里要分清一个概念：MSXML 是系统组件，和网络上经常搜到的那种 microsoft visual c++ redistributable 运行库不是一回事。VC++ 运行库解决的是你程序依赖的 C/C++ 运行时，而 MSXML 解决的是 XML 文本到内存对象的转换。走原生 MSXML 这条路，发布程序时不用惦记“客户的机器上有没有装那玩意”，这对做小工具和内部系统的人来说是巨大的省心事。

2.2 和第三方库的取舍：什么时候该换方向

选 MSXML 不等于所有场景都无脑用它。它的对立面是 TinyXML、pugixml 这类纯 C++ 跨平台库，两者各有各的主场。我常年在 Windows 桌面程序里用 MSXML，在跨平台服务和嵌入式工具里用 pugixml，界限还是清楚的。

判断依据很直接：如果程序只在 Windows 上跑，而且 XML 文件要“读出来、改掉、存回去”，MSXML 的成熟度没有对手，改动 XML 树是它 DOM 的原始功能，直接 createElement、appendChild、put_text 再 save，一步到位。如果代码要搬到 Linux，或者只想解析一个固定格式的小配置，那 TinyXML 系列确实更轻，前提是你接受“把第三方源码带进工程”这个事实。

本标题说的是 Visual C++ 工程、不装三方库、要解析读写，三项条件都命中 MSXML 的舒适区。下面的代码就是我实际搭这套东西的最小骨架，照着在 VS 里新建一个 Visual C++ 工程就能跑。

3. 读 XML 的最小工程：建工程、初始化 COM、取节点值

3.1 建工程与初始化 COM：三个调用先做对

在 Visual Studio 里新建一个“Windows 桌面应用程序”空项目，或者用控制台工程都行，字符集设置不影响，但建议直接使用 Unicode 字符集，后面宽字符接口会省很多事。源码开头固定加这几行：

#include <windows.h> #include <msxml2.h> // MSXML 的接口和 CLSID 定义 #include <comdef.h> // _bstr_t、_variant_t 等 COM 辅助类型 #include <tchar.h> #pragma comment(lib, "ole32.lib") #pragma comment(lib, "oleaut32.lib")

这三行 include 加上两行 pragma，就是整个工程对“外部依赖”的全部要求。msxml2.h 是从 Visual C++ 自带的 SDK 里来的，不需要你从网上下载任何东西。

调用 MSXML 之前必须先初始化当前线程的 COM 环境，然后在创建 DOM 对象时指定用 MSXML 6.0。最小可跑的读文件逻辑如下：

HRESULT hr = CoInitializeEx(nullptr, COINIT_APARTMENTTHREADED); if (FAILED(hr)) { // 如果线程已经在 STA 模式，这里会返回 RPC_E_CHANGED_MODE // 常见做法：继续往下走，因为说明 COM 已经被初始化过 } IXMLDOMDocument2* pDoc = nullptr; hr = CoCreateInstance(CLSID_DOMDocument60, nullptr, CLSCTX_INPROC_SERVER, IID_IXMLDOMDocument2, (void**)&pDoc); if (FAILED(hr) || pDoc == nullptr) { // 0x80040154 表示类未注册，见后面避坑章节 } VARIANT_BOOL bSuccess = VARIANT_FALSE; _variant_t vPath(L"C:\\config\\app.xml"); hr = pDoc->load(vPath, &bSuccess); if (bSuccess != VARIANT_TRUE) { IXMLDOMParseError* pErr = nullptr; pDoc->get_parseError(&pErr); // 从这里拿错误码和错误描述，排错全靠它 }

逐行解释几个关键参数。CoInitializeEx 的第一个参数是保留指针，传 nullptr；第二个参数 COINIT_APARTMENTTHREADED 表示当前线程用单线程套间，适合还要创建窗口、处理消息的 UI 线程。如果线程只做后台计算、不碰 UI，可以改成 COINIT_MULTITHREADED，但 MSXML6 在 MTA 模式下某些接口行为会有差异，对配置文件场景没影响。

CoCreateInstance 的参数里，CLSID_DOMDocument60 告诉系统“我要创建 MSXML 6.0 的 DOM 对象”；CLSCTX_INPROC_SERVER 表示只加载进程内组件，MSXML 就是这类组件，写错会报没有权限。接口 ID 用 IID_IXMLDOMDocument2，这是 MSXML 6.0 支持的、带 XPath 和命名空间扩展的主接口；如果你在老一点的头文件里只看到 IID_IXMLDOMDocument，那是 MSXML 3.0 级别的接口，也能用，但 selectSingleNode 等方法的签名不同，后面代码要对齐接口版本。

load 方法的第一个参数是 VARIANT 类型，可以传文件路径的宽字符串，也可以传 IUnknown 指针指向一个流对象。这里直接传 _variant_t 构造出的宽字符路径最省事。第二个参数 bSuccess 是真正的成功标志，注意一个反直觉的事实：即使文件不存在或 XML 语法错误，load 返回的 HRESULT 往往还是 S_OK，必须检查 bSuccess 才能确定解析成没成。

提示：bSuccess 判断是新手最常漏的一步。只看 hr 的值，你会得到一个“看起来成功但啥也没加载”的 DOM 对象。

3.2 取节点值和属性：selectSingleNode 是主力

DOM 加载完成后，取节点值有两个思路：一是用 GetElementsByTagName 按标签名取集合再遍历，二是用 selectSingleNode 直接写 XPath 表达式定位。做配置读写，强烈建议用后者，定位精确、代码短、改动时只改路径字符串。

IXMLDOMNode* pNode = nullptr; _bstr_t xpath(L"/config/database/host"); hr = pDoc->selectSingleNode(xpath, &pNode); if (SUCCEEDED(hr) && pNode != nullptr) { BSTR bstrValue = nullptr; pNode->get_text(&bstrValue); // 取出 <host> 标签内部的文本 std::wstring wValue = bstrValue ? bstrValue : L""; SysFreeString(bstrValue); // BSTR 必须手动释放 // 读属性：例如 <port timeout="30"> 里的 timeout IXMLDOMElement* pElem = nullptr; if (SUCCEEDED(pNode->QueryInterface(IID_IXMLDOMElement, (void**)&pElem))) { VARIANT vAttr; VariantInit(&vAttr); pElem->getAttribute(_bstr_t(L"timeout"), &vAttr); if (vAttr.vt == VT_BSTR) { std::wstring wAttr = vAttr.bstrVal; } VariantClear(&vAttr); pElem->Release(); } pNode->Release(); }

这段代码里有三个值得说清的点。第一，selectSingleNode 的 XPath 以 / 开头表示从根节点算起，/config/database/host 会精确匹配三层嵌套；如果中间某层存在命名空间，这个路径会失效，原因在第 5 章讲。第二，get_text 返回的 BSTR 是 COM 字符串，用完必须 SysFreeString，否则每读一个节点就泄漏一点内存；这个接口的调用频率一高，泄漏会肉眼可见地涨。第三，getAttribute 返回的是 VARIANT 联合体，因为 XML 属性在 DOM 里没有类型信息，MSXML 默认把它当字符串返回，也就是 vAttr.vt 极大概率是 VT_BSTR；不要幻想能直接拿 int，统一按字符串处理，自己再解析成整数最稳。

如果你的工程是老式多字节字符集，上面 std::wstring 要转回窄字符串才能写进 CString 或 char 数组。常见做法是用 WideCharToMultiByte 显式转换，不要靠编译器隐式转，很容易转出乱码：

char buf[256] = {0}; WideCharToMultiByte(CP_ACP, 0, wValue.c_str(), (int)wValue.size(), buf, sizeof(buf) - 1, nullptr, nullptr);

第 3.1 节的初始化代码加上这一节的查询代码，合起来就是“读 XML 文件并取出目标节点值”的全部内容。想验证成果，打一个断点看 wValue 的值，或者把它 printf 出来。

3.3 加载失败时如何拿到真正的原因

碰到 load 之后 bSuccess 是 FALSE，别急着怀疑代码写错。先用 DOM 对象自带的 parseError 接口把错误详情拉出来，这是 MSXML 排错最重要的入口：

IXMLDOMParseError* pErr = nullptr; pDoc->get_parseError(&pErr); if (pErr) { long errCode = 0; BSTR bstrReason = nullptr; pErr->get_errorCode(&errCode); pErr->get_reason(&bstrReason); // 输出 errCode 和 bstrReason，通常会把第几行第几个字符写清楚 SysFreeString(bstrReason); pErr->Release(); }

XML 语法错误的提示一般很直白，比如“结束标记不匹配”“缺少分号”。最让我头疼的反而是那些语法完整但语义不符合预期的失败，比如路径对不上、节点名大小写不一致，这些不会触发 parseError，静默返回空节点，只能靠 XPath 本身的写法去反推。

4. 写 XML 的完整动作：改节点、加节点、存盘与新建

4.1 修改已有节点并保存：三步走

读和写用的是同一个 DOM 对象，这是 MSXML 的优势，不用额外维护“解析出来的数据结构”和“待写回的 XML 文本”。改一个值、加一个节点，最后统一 save。

// 第一步：定位要改的节点 IXMLDOMNode* pHost = nullptr; pDoc->selectSingleNode(_bstr_t(L"/config/database/host"), &pHost); if (pHost != nullptr) { pHost->put_text(_bstr_t(L"192.168.1.100")); pHost->Release(); } // 第二步：在 database 节点下新增一个 backup 节点 IXMLDOMNode* pDb = nullptr; pDoc->selectSingleNode(_bstr_t(L"/config/database"), &pDb); if (pDb != nullptr) { IXMLDOMElement* pNewElem = nullptr; pDoc->createElement(_bstr_t(L"backup"), &pNewElem); pNewElem->put_text(_bstr_t(L"240")); IXMLDOMNode* pAppended = nullptr; pDb->appendChild(pNewElem, &pAppended); // pAppended 是加入后的实际节点，ComPtr 场景下用不到可以直接 Release if (pAppended) pAppended->Release(); pNewElem->Release(); pDb->Release(); } // 第三步：存盘 _variant_t vSavePath(L"C:\\config\\app.xml"); hr = pDoc->save(vSavePath);

put_text 这个方法有个隐藏行为：如果目标节点还没有文本子节点，它会自动生成一个；如果原来有多个文本子节点，它会把它们合并成一份再替换。对常规配置节点来说，这是最省心的写值方式。

createElement 只是创建一个游离在文档树之外的元素对象，必须再用 appendChild 挂接到某个父节点下，它才算真正进入了 XML 结构。注意 appendChild 的返回值是一个指向实际挂接后节点的指针，引用计数有增加，不用了就释放。这里有个细节：先 createElement 还是先 appendChild 都行，但文本内容要在 appendChild 之前设置好，因为一旦挂上树，后续再 put_text 会触发一遍 DOM 事件通知。

save 的参数同样是 VARIANT，传文件路径即可。save 成功与否看 HRESULT 就够，它不像 load 那样有“静默失败”的问题。常见失败原因是路径目录不存在、文件被占用没有写权限。

4.2 从零新建一个 XML 文件：声明、根节点、保存

有些场景下源文件不存在，程序需要自己生成一份全新的 XML。这时不能在 load 之后的空文档上加节点，而要用 createProcessingInstruction 先写入 XML 声明，再创建根元素。顺序错了，生成的 XML 会在开头的声明之前出现空白或乱序，部分严格解析器会拒绝读取。

IXMLDOMDocument2* pDoc = nullptr; CoCreateInstance(CLSID_DOMDocument60, nullptr, CLSCTX_INPROC_SERVER, IID_IXMLDOMDocument2, (void**)&pDoc); IXMLDOMProcessingInstruction* pPi = nullptr; pDoc->createProcessingInstruction( _bstr_t(L"xml"), _bstr_t(L"version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\""), &pPi); IXMLDOMNode* pRoot = nullptr; pDoc->appendChild(pPi, &pRoot); IXMLDOMElement* pConfig = nullptr; pDoc->createElement(_bstr_t(L"config"), &pConfig); pDoc->appendChild(pConfig, &pRoot); // 继续往 pConfig 下挂子节点，方式同 4.1 的 appendChild pDoc->save(_variant_t(L"C:\\output\\config.xml"));

createProcessingInstruction 的两个参数中，第一个是目标名，必须是 xml（大小写敏感）；第二个是完整的声明内容，包括版本和编码。这里把 encoding 写死为 UTF-8，save 出来的文件就是 UTF-8 编码。如果你漏掉 encoding，MSXML 会按 UTF-16 输出，文件体积直接翻倍不说，下游用文本编辑器打开全是乱码。这个坑我踩过一次，后来养成的习惯是新建文件的声明一律显式写 encoding。

4.3 保存时的格式与编码控制

很多人在 MSXML 里做完修改，save 一看，整个文件的缩进全乱了。这其实是没理解 MSXML 的行为：DOM 保存时默认不做“美化排版”，节点之间的空白文本节点如果当初没保留，保存出来就是一坨紧凑的 XML。解决办法是在 load 之前设置 PreserveWhitespace 属性：

_variant_t vPreserve(true); pDoc->setProperty(_bstr_t(L"PreserveWhitespace"), vPreserve);

这个属性必须早于 load 设置才有意义，因为空白文本节点是在解析阶段决定的，加载完成后补设不会改变已构建的树。对人工维护的配置文件来说，保留缩进很重要，否则每次程序保存后，同事打开 XML 发现格式全乱，体验极差。

另外还有一个色彩细节：MSXML6 保存 UTF-8 编码的文件时，有时会带 BOM（文件头三个字节 EF BB BF）。老旧的解析程序、某些 shell 脚本对 BOM 敏感，会把它当内容读进去。如果下游反馈“第一行第一个字符解析失败”，先检查文件头是不是多了 BOM。处理方式有两种：要么自己在 save 后打开文件前三个字节判断并过滤，要么在 XML 声明里不写 encoding，让 MSXML 按 UTF-16 输出，但你大概率不想用 UTF-16。多数情况接受带 BOM 的 UTF-8 就行，现代工具都能识别。

5. 原生 XML 解析的常见问题排查：五个亲历翻车现场

5.1 程序在别人机器上启动就报 0x80040154

现象：代码在自己机器上跑得欢，发给同事或拷到客户机器上，一执行到 CoCreateInstance 就崩，错误码 0x80040154，含义是“类没有注册”。

原因：这台机器没有 msxml6.dll，或者它的 MSXML 版本比你开发机上低。Win7 之后 MSXML6 是系统自带的，但早期经过精简的 Windows XP、部分 Windows Server 或企业定制的镜像里，这个组件可能被裁剪掉。

解决：创建 DOM 对象前，先尝试 MSXML 6.0，失败后回退到 3.0 的 ProgID，用 CLSIDFromProgID 动态取类 ID。这套代码要写在 CoCreateInstance 之前，而不是直接在 CoCreateInstance 里写死 CLSID_DOMDocument60。

CLSID clsid; HRESULT hr = CLSIDFromProgID(_bstr_t(L"MSXML2.DOMDocument.6.0"), &clsid); if (FAILED(hr)) { hr = CLSIDFromProgID(_bstr_t(L"MSXML2.DOMDocument.3.0"), &clsid); } if (FAILED(hr)) { // 到这里说明系统连 MSXML3 都没有，提示用户补装或换机器 } IXMLDOMDocument2* pDoc = nullptr; hr = CoCreateInstance(clsid, nullptr, CLSCTX_INPROC_SERVER, IID_IXMLDOMDocument2, (void**)&pDoc);

顺带说一句，这个问题和 VC++ 运行库 redistributable 是两回事，别混在一起查。你程序里如果用了 ATL 或 MFC，那确实要求机器上装了对应版本的 VC++ 运行库；但 MSXML 的 COM 注册问题，排查方向是组件服务里的 msxml6.dll 是否存在。这一条区分开，能省下半天的排查时间。

5.2 XML 里的中文全部变成乱码

现象：XML 文件里明明写着“数据库连接成功”，程序读出来变成一串“鏁版嵁搴”之类的乱码，或者写回文件后中文内容面目全非。

原因：绝大多数情况是编码转换链断裂。典型场景是：先用 C 标准库 fopen/fread 把整个文件读成 char* 字节流，然后直接把这个窄字符串塞给 loadXML 方法。XML 文件明明是 UTF-8 编码，你读进来的是一个一个 UTF-8 字节，而 loadXML 收到窄字符串后会按当前系统 ANSI 代码页转换，中文 Windows 上是 GBK，字节流被错误解码，自然乱码。

解决：不要中间插一脚去读字节流，直接把文件路径传给 load 方法，让 MSXML 自己根据 XML 声明里的 encoding 处理字节解码。如果确实需要 loadXML 字符串形式，先把读到的字节流按 XML 声明的编码转成宽字符串，再将宽字符串转成 BSTR 传给 loadXML：

// 读取 UTF-8 文件字节流后，先转成 UTF-16，再交给 loadXML std::string utf8Content = ReadAllBytes("config.xml"); int wideLen = MultiByteToWideChar(CP_UTF8, 0, utf8Content.c_str(), (int)utf8Content.size(), nullptr, 0); std::wstring wideContent(wideLen, L'\0'); MultiByteToWideChar(CP_UTF8, 0, utf8Content.c_str(), (int)utf8Content.size(), &wideContent[0], wideLen); pDoc->loadXML(_bstr_t(wideContent.c_str()), &bSuccess);

这一条是“源码能编译、运行不报错、结果全错”的典型代表，排错难度高，因为没有任何异常信息。建议从一开始就统一：文件路径和 XML 内容全部走宽字符，窄字符只存在于从磁盘读字节流的那个边界。

5.3 selectSingleNode 死活取不到值，XML 里明明有

现象：XPath 路径看着没问题，selectSingleNode 返回 nullptr，或者 selectNodes 拿到 0 个节点。把路径缩短一层能拿到，写完整路径就为空。

原因：多数是命名空间在作怪。如果 XML 根节点带 xmlns 属性，比如<config xmlns="http://example.com/schema">，那么它内部所有节点在 XPath 视角里都归属于这个默认命名空间。你写的/config/database/host里的 config 和实际树里的 config 不是同一个命名空间限定名，自然匹配不上。MSXML 的 XPath 实现对这种“路径字符串前缀背后映射到哪个命名空间”的判断，依赖一个叫 SelectionNamespaces 的全局设置。

解决：加载文档后、执行 XPath 之前，把文档里用到的默认命名空间前缀映射注册进去：

_variant_t vNs(L"xmlns:cfg='http://example.com/schema'"); pDoc->setProperty(_bstr_t(L"SelectionNamespaces"), vNs); // 路径改为使用前缀 IXMLDOMNode* pNode = nullptr; pDoc->selectSingleNode(_bstr_t(L"/cfg:config/cfg:database/cfg:host"), &pNode);

不要试图逃避命名空间问题：有的 XML 文件没有显式 xmlns，但内部引用了外部 schema，同样会给 XPath 带来影响。判断方法很简单，记事本打开 XML，看根节点标签里有没有 xmlns 字样，有就必定需要设置 SelectionNamespaces。

5.4 修改保存后文件像没写过，或者文件被锁死

现象：save 调用返回成功，但打开 XML 文件一看，改动根本没进去；反过来还有一种现象是 save 报错，说文件正在被另一个进程使用。

原因：第一种情况通常是路径问题。save 方法如果传的是相对路径，比如_variant_t(L"config.xml")，它写的是进程当前工作目录下的文件，和你脑子里想的“工程目录下的 config.xml”很可能不是同一个。你打开了 A 目录的文件，把改动写到了 B 目录，自然“像没写过”。第二种情况更隐蔽：修改节点后，持有节点接口的指针没有释放，DOM 对象引用计数没有归零，save 试图覆盖文件时被系统判定为文件占用。MSXML 加载文件后不会独占文件，但你这个进程内如果还有流对象没关闭，同样会锁。

解决：所有 selectSingleNode / createElement / appendChild 拿到的接口指针，用完立即 Release；save 之前把可能仍持有节点引用的临时变量都清掉。路径一律用完整绝对路径，或者在工程里封装一个 GetAppConfigPath() 函数统一拼路径，不要在代码里散布相对路径字符串。查锁文件时可以用 Process Explorer 搜文件名看看确实是哪个进程握着句柄。

5.5 load 明明返回成功，XML 却啥也没解析出来

现象：load 不报错，bSuccess 也判断了没拦住，但紧接着做 selectSingleNode 返回空，整棵树空无一物。折腾半天，最后发现 parseError 里有内容，只是之前没看。

原因：load 方法返回的 HRESULT 只在 COM 调用层面表示“调用这个动作执行了”，真正的解析结果要看第二个参数 VARIANT_BOOL。但有一种更隐蔽的情况：XML 文件本身是空的，或者文件路径指向一个 0 字节文件，此时 load 会返回 S_OK，bSuccess 也是 VARIANT_TRUE，但文档对象里只有一个空壳。还有一种情况是直接用 loadXML 传了一个带 BOM 头的字符串，BOM 被当作第一个字符，导致解析器看到的第一个标记不是 XML 声明而报错。

解决：load 之后立即检查两件事，一是 bSuccess 是否为 VARIANT_TRUE，二是文档对象的 childNodes 数量是否大于 0。排错时永远先抓 parseError，把它打印出来看，里面会有行号和列号，比你盯着屏幕瞎猜有用得多。以下这段配在第 3 章初始化的末尾，相当于给解析加个保险：

if (bSuccess == VARIANT_TRUE) { long nodeCount = 0; IXMLDOMNodeList* pChildren = nullptr; pDoc->get_childNodes(&pChildren); pChildren->get_length(&nodeCount); pChildren->Release(); if (nodeCount == 0) { // 文件存在但内容为空，按空配置处理 } }

6. 把读写代码收进一个类：后续维护少踩一半坑

到这里，读、写、建文件的核心逻辑都齐了，但它们散在一堆全局函数和临时变量里。实际项目里，我一般会把这套逻辑收进一个独立类，让外部调用只有 Load、GetText、SetText、Save 四个方法。类的骨架长这样：

class XmlConfig { public: XmlConfig() : m_spDoc(nullptr) {} ~XmlConfig() {} bool Load(const std::wstring& path) { CoInitializeEx(nullptr, COINIT_APARTMENTTHREADED); HRESULT hr = m_spDoc.CreateInstance(CLSID_DOMDocument60); if (FAILED(hr)) return false; _variant_t vPath(path.c_str()); VARIANT_BOOL ok = VARIANT_FALSE; m_spDoc->load(vPath, &ok); return ok == VARIANT_TRUE; } std::wstring GetText(const std::wstring& xpath) { IXMLDOMNode* pNode = nullptr; m_spDoc->selectSingleNode(_bstr_t(xpath.c_str()), &pNode); if (!pNode) return L""; BSTR val = nullptr; pNode->get_text(&val); std::wstring result = val ? val : L""; SysFreeString(val); pNode->Release(); return result; } bool SetText(const std::wstring& xpath, const std::wstring& value) { IXMLDOMNode* pNode = nullptr; m_spDoc->selectSingleNode(_bstr_t(xpath.c_str()), &pNode); if (!pNode) return false; pNode->put_text(_bstr_t(value.c_str())); pNode->Release(); return true; } bool Save(const std::wstring& path) { HRESULT hr = m_spDoc->save(_variant_t(path.c_str())); return SUCCEEDED(hr); } private: _com_ptr_t<IXMLDOMDocument2> m_spDoc; };

这个类里最大的改动是用 _com_ptr_t 管理 DOM 对象，它会在析构和重新赋值时自动调 Release，省掉那些散落的 pDoc->Release()。_com_ptr_t 是 VC++ 编译器自带的 COM 智能指针，不需要额外库，算原生的一部分。

我的习惯是：所有进出该类的字符串统一用 std::wstring，BSTR 只在方法内转换。这样上层代码永远不用碰 BSTR、VARIANT 这些 COM 类型，换接口时也不用满工程排查类型。至于 MSXML 不适合的极端场景——比如 100MB 以上的超大 XML，或者需要流式处理来压低内存占用，那才轮到考虑 SAX2 或换 pugixml，普通配置文件级别的解析读写，这个类用到退休都够了。

早年我就是图省事，把窄字符路径直接塞进 _variant_t，结果中文路径的配置文件各种诡异报错。后来学乖了：所有路径和字符串在进入 COM 接口前一律转成宽字符，转换只发生在从磁盘读文件那一个边界。这个习惯让我后来几年基本没在 XML 解析上失眠过。方案就这一套，按着搭、按着避坑，应该能帮你省下当初我踩坑用掉的时间，希望帮到你。

本文还有配套的精品资源，点击获取