根本原因是Office COM组件注册依赖版本、位数和安装状态，x64程序调x86 Office、未安装或Click-to-Run版禁用COM、权限不足均致0x80040154错误。
为什么 C++ 直接调用 Office COM 接口容易崩溃或报错 0x80040154
根本原因是 Office 的 COM 组件注册依赖于具体版本、位数（x86/x64）和安装状态，CoInitialize 后调用 CoCreateInstance 失败时，常见错误码 0x80040154（CLASS_NOT_REGISTERED）不是代码写错了，而是：
– 当前进程架构（如 x64 程序）试图加载 x86 版 Office 注册表项（反之亦然）；
– Office 未安装，或仅安装了 Click-to-Run 版本（如 Microsoft 365），其 COM 接口默认被禁用；
– 缺少管理员权限导致无法访问某些注册表路径（尤其在 Win10/11 UAC 严格模式下）。
验证方式：运行 oleview.exe（Windows SDK 工具），在 “File → View TypeLib” 中尝试打开 C:\Program Files\Microsoft Office\root\Office16\MSWORD.OLB（路径依版本而异），打不开即说明类型库不可用。
如何用 C++ 安全创建 Excel.Application 对象并写入单元格
必须显式指定 CLSID 和接口 IID，并检查每一步返回值。不能跳过 QueryInterface 或忽略 HRESULT。
HRESULT hr = CoInitialize(nullptr);
if (FAILED(hr)) { /* 处理初始化失败 */ }
IDispatch* pExcel = nullptr;
hr = CoCreateInstance(uuidof(Excel::Application),
nullptr,
CLSCTX_LOCAL_SERVER,
uuidof(IDispatch),
reinterpret_cast>(&pExcel));
if (FAILED(hr)) { / 检查 hr 值，0x80040154 表示未注册 */ }
// 获取 Workbooks 集合
IDispatch* pWorkbooks = nullptr;
hr = pExcel->InvokeMember_ByName(L"Workbooks", DISPATCH_PROPERTYGET, &pWorkbooks);
// 新建工作簿
IDispatch* pWorkbook = nullptr;
hr = pWorkbooks->InvokeMember_ByName(L"Add", DISPATCH_METHOD, &pWorkbook);
// 获取 ActiveSheet
IDispatch* pSheet = nullptr;
hr = pExcel->InvokeMember_ByName(L"ActiveSheet", DISPATCH_PROPERTYGET, &pSheet);
// 写入 A1 单元格
VARIANT varRow, varCol, varValue;
varRow.vt = VT_I4; varRow.lVal = 1;
varCol.vt = VT_I4; varCol.lVal = 1;
varValue.vt = VT_BSTR; varValue.bstrVal = SysAllocString(L"Hello from C++");
DISPID dispidCells = 0;
OLECHAR* szCells = L"Cells";
pSheet->GetIDsOfNames(IID_NULL, &szCells, 1, LOCALE_USER_DEFAULT, &dispidCells);
DISPPARAMS params = {0};
params.rgvarg = &varValue;
params.rgdispidNamedArgs = nullptr;
params.cArgs = 1;
params.cNamedArgs = 0;
IDispatch* pRange = nullptr;
hr = pSheet->Invoke(dispidCells, IID_NULL, LOCALE_USER_DEFAULT,
DISPATCH_PROPERTYGET, ¶ms, &varValue, nullptr, nullptr);
// 注意：实际需先调用 Cells(Row,Col)，再对 Range.Value 属性赋值 —— 此处仅为示意链路
关键点：
– 必须用 CLSCTX_LOCAL_SERVER（而非 CLSCTX_INPROC_SERVER），因为 Excel 是 out-of-process COM 服务；
– 所有 IDispatch::Invoke 调用都要配对 SysFreeString 和 VariantClear；
– InvokeMember_ByName 是封装函数，非系统 API，需自行实现或使用 ATL 的 CComDispatchDriver。
立即学习“C++免费学习笔记（深入）”；
读取 Word 文档文本内容时为何 GetText() 返回空字符串
常见于未正确获取 Document.Content 或忽略 Selection 上下文。Word 的 COM 模型中，纯文本提取不能直接调用 Range.Text 而不先设置有效范围。
- 必须确保文档已打开且
Document对象有效（Documents.Open返回非 null） -
Content是一个Range，但其Text属性只在前台可见或显式刷新后才稳定；更可靠的方式是：Range.Copy()+GetDataObject()->GetData()（走剪贴板）或遍历Paragraphs集合 - 若文档含复杂格式（表格、文本框），
Content.Text会跳过这些区域 —— 实际需用StoryRanges枚举所有故事（main text、header、footer、textboxes）
最小可行读取逻辑：
IDispatch* pDoc = nullptr;
hr = pDocs->InvokeMember_ByName(L"Open", DISPATCH_METHOD, &pDoc,
vtPath); // vtPath 是 BSTR 文件路径
IDispatch* pContent = nullptr;
hr = pDoc->InvokeMember_ByName(L"Content", DISPATCH_PROPERTYGET, &pContent);
BSTR bstrText = nullptr;
hr = pContent->InvokeMember_ByName(L"Text", DISPATCH_PROPERTYGET, &bstrText);
// 此时 bstrText 才是真实文本，需用 SysFreeString 释放
ATL 和 #import 两种方式哪个更适合生产环境
#import 更轻量但隐藏风险：
– 自动生成的头文件（如 msword.tlh）把所有接口暴露为 C++ 类，看似方便，但一旦 Office 升级（如从 Office 2019 切到 Microsoft 365），__uuidof 可能失效或方法签名变更，编译不报错、运行时报 DISP_E_UNKNOWNNAME；
– #import 默认启用 raw_interfaces_only，绕过智能指针，需手动 AddRef/Release，极易内存泄漏。
ATL 方案（CComPtr + CComDispatchDriver）更可控：
– 所有 COM 调用都显式检查 HRESULT；
– 接口生命周期由智能指针管理；
– 可配合 AtlModuleLoadLibrary 动态加载类型库，规避硬编码路径。
真正棘手的是：Office COM 不支持多线程并发调用（即使是 STA 模式）。所有操作必须在同一个线程完成，且不能跨 CoUninitialize 边界复用对象 —— 这一点，无论用哪种封装都会出问题。
