C++配合libxlsxwriter向Excel批量插入图片的实践与踩坑

做报表自动化久了，你会发现一个很尴尬的中间地带：数据、公式、格式都好说，文本一填、样式一刷就完事；一旦需求里出现“把现场照片塞进Excel对应行”，常规套路基本全哑火。我最近在手写一个设备点检报告生成工具，C++主程序，输出是标准XLSX，前面几千条记录跑得稳稳的，卡在插图上整整折腾了一个下午。试过在单元格里写图片路径，客户打开看到一行文字；试过用十六进制流硬拼XLSX的XML结构，弄到一半自己都觉得荒谬；最后老老实实把libxlsxwriter接进CMake工程，半小时内把图片稳稳嵌进了工作簿。

这篇文章就是把那段经历完整复盘一遍。如果你也正打算在C++项目里用libxlsxwriter向Excel表格插入图片，用的是CMake + VS2019这种Windows开发环境，那这篇内容正好能帮你绕过我踩过的坑。我会从工具选型、环境准备、CMake接入、核心代码到报错排查逐步展开，尽量把每个“为什么”都讲清楚。

1. 为什么我的Excel插图片需求最终选了libxlsxwriter

1.1 需求事由：程序化生成带照片的巡检表格

先说清楚我要做的事。现场设备巡检工具每天会产出一批图片，比如设备外观、仪表读数、异常部位特写，另外还有一条数据库记录，里面是巡检时间、设备编号、结果状态。我需要的产物是一份Excel报告，每条设备一行，图片直接嵌在对应单元格右侧或者固定列位置，发给别人看的时候不用同时带一个几百MB的图片文件夹。

这里有个本质矛盾：Excel本身支持的图片插入操作是交互式的，或者通过COM接口在Office环境里驱动Excel进程去做。但我的程序运行环境不保证装Office，服务器上更不可能为了生成报表去装载Excel程序。所以方案的底线就是：不依赖Excel应用程序，直接生成符合XLSX规范的二进制文件。

文本、数字、公式这些内容用轻量XML表示还简单，图片则牵扯到文件内的媒体部件、关系文件、绘图XML，手写根本不可维护。于是问题的核心就变成了：找一个能原生处理这些内部结构的C/C++库。

1.2 对比过的不完美方案

在最终锁定libxlsxwriter之前，我认真评估过好几条路线，也不全是技术栈不适合，很多是授权或者运行环境的问题。

• Excel COM/OLE自动化：通过C++调用COM接口操作Excel。缺点很明显——目标机器必须安装Excel，且要经历进程创建、加载、写入、保存、释放的沉重流程。在服务器批处理场景下，开一个Excel进程去处理几百条记录，稳定性和速度都是灾难。仅适合少量、本机、有Office环境的交互工具。
• Apache POI：Java生态处理Office文件的利器。如果你整个项目就是Java服务的辅助模块，POI是最佳选择之一。但我的主体项目是C++，为一个报表模块引一个JVM进去，换算成本和团队维护负担完全不划算。
• libxl：老牌的C++读写Excel库，功能全面，文档完善，从很早就支持图片插入。问题在授权，商业使用需要按开发者数购买License，个人和小团队练手无所谓，但公司项目走采购流程会比较重。
• 直接用zip库手动改XLSX：XLSX本质上是一个ZIP容器，理论上可以写一段代码把图片塞进xl/media/、补上xl/worksheets/_rels/sheet1.xml.rels里的Relationship，再改xl/worksheets/sheet1.xml加入<drawing>节点。我试过为一张图手动修改文本结构，能行，但代码里充斥着硬编码的XML碎片，任何列顺序调整或单元格合并都会让你头皮发麻。做研究可以，做产品不行。

libxlsxwriter吸引我的点很明确：它是纯C库，对C++项目来说包含头文件就能用；没有Office依赖，渲染出的是标准XLSX文件；MIT授权，商用没有心理负担；支持图片插入、图表、条件格式、数据透视表这些高级功能。加上它的API风格非常直白，基本看函数名就知道要干什么。对于“C++ + Excel插入图片 + 批量化生成”这个需求，它几乎是当前最优解。

2. VS2019+CMake环境准备：先把那两个高频报错解决掉

2.1 安装与版本组合

我的环境是Windows 10专业版，IDE为Visual Studio 2019社区版，编译器是MSVC v142工具集。CMake版本我这里用的是3.24.1，但整体来说3.16以上就足够，我后面在CMakeLists里设置的是cmake_minimum_required(VERSION 3.16)，就是为了让不太新的CMake也能跑。

VS2019的安装有个容易被忽视的细节：安装器里有个“使用C++的桌面开发”工作负载，必须勾选上。很多人在VS里写C#或者Python，装VS的时候只选了.NET负载，等第一次跑CMake才会发现cl.exe完全不存在，随后在编译C++项目时弹出一堆“无法打开包括文件: corecrt.h”之类的错误。如果已经装好VS但缺C++组件，用Visual Studio Installer点“修改”，勾上“使用C++的桌面开发”，同时确认右侧包含“Windows 10 SDK”和“MSVC v142 - VS 2019 C++ x64/x86生成工具”，一般默认会带上。

CMake在Windows下有两种常见分发：一个是安装包安装的独立版，一个是通过Visual Studio自带的CMake组件。独立版的优点是版本更新、命令行随处可用，缺点是一开始没配好PATH就会遇到“无法识别”的报错；VS自带的CMake则需要通过VS的开发者命令行环境才能找到。我这边选择的是独立版CMake，配好PATH之后PowerShell和CMD里都能直接敲cmake。

2.2 “cmake”无法识别的经典排查

如果你在PowerShell或者CMD里输入cmake，返回这段报错：

cmake : 无法将“cmake”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。

这基本就是PATH环境变量的问题，程序没被系统找到。最常见的原因是安装CMake时没有勾选Add CMake to the system PATH for all users，或者当时图省事选了Do not add CMake to PATH。

修复很简单，无非两条路。一是重新运行CMake安装包，在“Install Options”把PATH选项改成第一项“Add CMake to the system PATH for all users”；二是在系统环境变量手动追加CMake安装目录，比如我的是C:\Program Files\CMake\bin，追加后需要重新打开终端才生效。

改完之后建议验证一下：

cmake --version

能打印版本号，说明这一步解决了。很多初学者卡在这里，其实是新开终端窗口前旧进程没有刷新环境变量，所以加完PATH后务必关掉所有PowerShell窗口再重开。

2.3 确认MSVC工具链是否就绪

CMake本身只是构建系统生成器，真正的编译动作还是要交给MSVC。VS2019安装好后，编译器不会自动出现在普通终端PATH里，需要从开始菜单打开x64 Native Tools Command Prompt for VS 2019或Developer PowerShell for VS 2019。在这种环境终端里，cl.exe、nmake.exe这些才能直接找到。

用命令行验证工具链是否正常：

cl

如果看到一堆以Microsoft (R) C/C++ Optimizing Compiler开头的提示信息，说明编译器在。

如果默认的普通CMD里输入cl报“不是内部或外部命令”，也别慌，这不代表没装C++工具链，只是环境变量没加载。我们后面构建时有两个选择：

1. 在开发者终端里执行CMake和构建命令；
2. 在VS2019里直接“打开本地文件夹”，让IDE自己发现CMakeLists.txt并生成CMake缓存。

两种方式各有优势，我个人平时习惯用开发者终端，构建日志看起来更直接，出错信息也能原样复制出来排查；遇到偏图形化操作的时候就用VS的“打开文件夹”模式。后面第5节我会把两条路径都跑一遍。

3. 拿到libxlsxwriter并接入CMake工程

3.1 获取源码的两种方式

libxlsxwriter的官方仓库在GitHub的jmcnamara/libxlsxwriter。我建议直接用git clone拉取源码到工程目录，例如放在项目根目录下的third_party/libxlsxwriter：

git clone https://github.com/jmcnamara/libxlsxwriter.git

如果网络环境让你连GitHub不太顺畅，也可以去Releases页面下载某个稳定版本的ZIP包，解压后同样放进去。仓库本身就带CMakeLists.txt，这意味着我可以用add_subdirectory的方式直接把它拉进我的CMake工程，不需要预先编译安装库文件，这样整个项目在另外一台机器上clone下来之后，只要装好VS和CMake，就能一键构建。

还有一种方式是vcpkg：

vcpkg install libxlsxwriter

然后把vcpkg的toolchain文件传给CMake：

cmake -DCMAKE_TOOLCHAIN_FILE=[vcpkg根目录]/scripts/buildsystems/vcpkg.cmake ..

这方式适合你的项目已经把vcpkg作为统一依赖管理工具的场合。但我这次没有走这条路线，因为源码形式集成在调试时看库内部逻辑更方便，而且add_subdirectory方式在需要改库的编译选项时更灵活。

3.2 CMakeLists.txt的组织

我的工程目录结构大概长这样：

ExcelImageDemo/ ├── CMakeLists.txt ├── main.cpp ├── photos/ │ └── dev001.jpg └── third_party/ └── libxlsxwriter/ ├── CMakeLists.txt ├── include/ └── src/

根目录的CMakeLists.txt内容如下：

cmake_minimum_required(VERSION 3.16) project(ExcelImageDemo LANGUAGES C CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 进入 libxlsxwriter 源码目录并参与构建 set(BUILD_TESTING OFF CACHE BOOL "" FORCE) add_subdirectory(third_party/libxlsxwriter) add_executable(ExcelImageDemo main.cpp) # 链接 libxlsxwriter 库 target_link_libraries(ExcelImageDemo PRIVATE xlsxwriter) if(WIN32) target_compile_definitions(ExcelImageDemo PRIVATE NOMINMAX WIN32_LEAN_AND_MEAN) target_compile_options(ExcelImageDemo PRIVATE /utf-8) endif()

几个关键点说明一下：

• LANGUAGES C CXX：因为libxlsxwriter是C库，但我们的主代码是C++，所以CMake工程要把两种语言都启用，否则链接或编译阶段可能出现“无法识别源文件类型”这类问题。
• BUILD_TESTING：libxlsxwriter的CMake脚本里默认可能会加载CTest，加一个OFF的缓存变量可以避免测试模块参与构建，缩短时间。
• 链接目标名：库通过add_subdirectory暴露出来的CMake目标名是xlsxwriter，不区分大小写。如果你把库编译成静态库后单独链接，也可能看到xlsxwriter_static这类目标。可以先构建一下，看ALL_BUILD的输出里实际生成的库名。链接不对会报“无法解析的外部符号”，关于这个后面有专门排查段落。

3.3 静态链接还是动态链接

libxlsxwriter在Windows上用CMake构建时，默认行为是生成一个共享库DLL，但也可以配置成生成静态库。在add_subdirectory之前，可以手动指定：

set(BUILD_SHARED_LIBS OFF CACHE BOOL "" FORCE)

我把这个选项设为OFF，原因很现实：作为一个需要部署到客户环境或者内网服务器的工具，DLL要跟着拷贝，少一个依赖就少一个出问题的入口点。静态库把代码直接揉进exe里，单文件发布，配合MSVC的/MT选项连VC运行时都不用单独带。

不过静态链接需要在CMake里处理好一个细节：MSVC底下链接静态库时需要显式定义XLSXWRITER_STATIC之类的宏，不同库写法不一样。具体到libxlsxwriter，看它的头文件定义，你会在xlsxwriter.h附近发现这样的逻辑：

#if defined(_MSC_VER) && defined(LIBXLSXWRITER_SHARED) #define LXW_API __declspec(dllimport) #else #define LXW_API #endif

也就是说，默认不导出宏时就是按静态链接方式声明的。所以CMake里只要不开BUILD_SHARED_LIBS，主程序这边什么都不用写，直接#include "xlsxwriter.h"即可。

4. 核心代码：把图片真正放进工作表

4.1 数据与图片落位的基本规则

在用API之前，有几个基础概念要先建立：libxlsxwriter的工作流是“工作簿→工作表→单元格/图片对象”。也就是先创建workbook，再往里加worksheet，然后所有的写入操作都基于worksheet句柄。

单元格的定位方式值得强调：Excel里的行和列在这里都是从0开始的。也就是说worksheet_write_string(worksheet, 0, 0, "设备编号", NULL)写入的是A1单元格，(1, 1)是B2。这个0起点和你在VBA里看到的不一样，刚开始容易把人绕晕。我写代码时心里默念“第几行减一，第几列减一”才慢慢习惯。

插入图片对应的函数是worksheet_insert_image和它的升级版worksheet_insert_image_opt。前者只管把图片放到指定的单元格，后者允许额外传入偏移量、缩放比例、URL链接等参数。

函数签名大致如下：

lxw_error worksheet_insert_image(lxw_worksheet *worksheet, lxw_row_t row, lxw_col_t col, const char *filename); lxw_error worksheet_insert_image_opt(lxw_worksheet *worksheet, lxw_row_t row, lxw_col_t col, const char *filename, lxw_image_options *options);

lxw_image_options结构里我经常用的几个字段：

• x_offset、y_offset：图片相对单元格左上角的像素偏移；
• x_scale、y_scale：图片宽高缩放比例，0到1之间就是缩小，大于1是放大；
• url：给图片加超链接。

4.2 一个可编译运行的示例

直接看一个能跑的完整例子。我写了个最简单的程序：创建report.xlsx，Sheet1第一行放“设备编号”和“巡检照片”两个表头，第二行写入一条设备编号，然后在其右侧单元格位置插入一张本地图片。

#include <cstdio> #include "xlsxwriter.h" int main() { lxw_workbook *workbook = workbook_new("report.xlsx"); lxw_worksheet *worksheet = workbook_add_worksheet(workbook, "巡检记录"); // 表头 worksheet_write_string(worksheet, 0, 0, "设备编号", NULL); worksheet_write_string(worksheet, 0, 1, "巡检照片", NULL); // 数据行 worksheet_write_string(worksheet, 1, 0, "DEV-001", NULL); // 设置列宽，让图片有足够显示空间 worksheet_set_column(worksheet, 0, 0, 12, NULL); worksheet_set_column(worksheet, 1, 1, 30, NULL); worksheet_set_row(worksheet, 1, 60, NULL); // 插入图片，放在 B2 单元格，缩小到 50% lxw_image_options options = {0}; options.x_offset = 5; options.y_offset = 5; options.x_scale = 0.5; options.y_scale = 0.5; lxw_error err = worksheet_insert_image_opt(worksheet, 1, 1, "photos/dev001.jpg", &options); if (err != LXW_NO_ERROR) { printf("insert image error: %d\n", err); workbook_close(workbook); return 1; } workbook_close(workbook); printf("report.xlsx 生成成功\n"); return 0; }

这里有一个非常容易翻车的点：workbook_close()必须在所有写入工作完成后再调用。这个函数不只是释放内存，它还负责把所有数据序列化并写入到最终的XLSX文件里。我最早写代码时把它放在插入图片之前，结果生成的文件打开后什么都没显示，还以为是库的问题，查了半天才意识到是函数顺序搞反了。更反直觉的是，workbook_close()之后再用worksheet_*系列API执行任何写入都会在运行时崩溃，因为内部缓冲区已经被回收了。

回头说说图片格式。libxlsxwriter支持的图片格式包括PNG、JPEG、GIF和BMP。实测下来PNG和JPEG最稳，BMP这种老旧格式能插是会插，但图片体积会变得很夸张。如果你在程序里需要从网络或摄像头拿图片，先确保落地成PNG或JPG再传给这个库，别直接塞一个原始BMP。

4.3 控制图片偏移、缩放和锚点

图片插进去后，它在Excel里的显示位置遵循一个“锚定”规则：row和col参数决定图片左上角更靠近哪个单元格，x_offset和y_offset再在这个基础上按像素微调。我用“靠近”这个词是因为Excel内部会把图片定位到离指定单元格左上角最近的位置，不是说死板地贴在那个单元格正中。

缩放比例的设置在实际项目中特别关键。比如我的巡检照片是摄像头拍的，单张分辨率是1920×1080，原尺寸直接插进Excel工作簿，几乎占据整个屏幕，表格翻起来非常难受。我在程序里读取图片尺寸后，统一算一个缩放比，让图片在表格里显示为大概240px宽，计算公式就是：

scale = 目标显示宽度 / 图片原始宽度

240除以1920刚好是0.125，所以x_scale和y_scale都填0.125。这里要注意横纵两个scale必须保持一致，否则图片会被拉伸变形。如果你不想自己算，也可以在程序里写死比例值，但这要求所有图片来源的尺寸一致，否则显示效果会参差不齐。

关于锚点还有一个值得琢磨的点：当用户后续在Excel里手动拖动列宽、插入行时，已经插入的图片可能不会跟着单元格移动，而是停留在原始坐标位置。这是Excel对于浮动对象的默认行为，跟libxlsxwriter无关。如果希望图片和单元格联动，其实Excel有“随单元格移动和大小变化”的选项，但XLSX文件格式层面是否能通过库来设置这个属性，需要看库的更新情况。我在当前版本里没有找到暴露这个开关的API，所以如果你的客户对“图片跟随行高列宽变化”有硬性要求，要先跟他说清楚这个限制，或者用别的方式规避。

5. 实测运行与高频报错排查记录

5.1 命令行构建和VS2019两种编译路径

工程配置好之后，构建方式可以分成命令行和IDE两种。

命令行方式是先创建build目录，用CMake生成VS工程：

mkdir build cd build cmake .. -G "Visual Studio 16 2019" -A x64

如果是在普通PowerShell里执行，大概率会报一个“无法找到Visual Studio实例”之类的问题，这是正常的，因为MSVC的环境变量还没加载。两步走：先用开始菜单打开x64 Native Tools Command Prompt for VS 2019，在里面重新进入build目录，然后直接：

cmake --build . --config Release

构建结束会在build/Release/下生成ExcelImageDemo.exe。注意CMake的默认输出目录结构是{build}/Release/或{build}/Debug/，取决于你指定的--config。如果运行时它找不到photos目录下的图片，先确认你是在哪个目录启动exe的，我习惯把photos文件夹整个放进build目录，或者干脆把图片路径改成绝对路径先验证通。

VS2019方向更省心：用IDE的“打开文件夹”直接选择工程根目录，VS会自动识别CMakeLists.txt并加载CMake缓存。等右下角缓存生成完毕，在“解决方案配置”下拉里选Release-x64，Ctrl+F5就能构建并运行。VS在处理CMake工程时会在out/build下生成自己的build目录，跟命令行build目录互不干扰。

两种方式我实测都能跑通，但如果你像我一样要写脚本批量生成报表，命令行方式明显更适合做定时任务。IDE方式主要用来断点调试。

5.2 链接错误、编码警告和头文件缺失

这条路我一路走下来，遇到的报错其实就那么几类，先列个表：

这里我特别想展开说两个。

第一个是“无法解析的外部符号”。这个报错语气很吓人，其本质是编译阶段函数声明找到了，但链接阶段找不到实现。根因几乎总是CMake没有把生成的库文件和主程序正确关联。如果你用的是add_subdirectory方式，并在根CMakeLists里写了target_link_libraries(ExcelImageDemo PRIVATE xlsxwriter)还是报错，你先去build目录看一眼，libxlsxwriter子目录下实际生成了哪些.lib文件。不同的libxlsxwriter版本，库目标名可能带后缀，比如xlsxwriter_static或者区分Debug/Release的命名。看着实际生成的文件名改CMakeLists就完了。

第二个是编码问题。C++源码在Windows下如果包含中文字符串，比如我上面的示例代码里写"设备编号"、"巡检照片"，MSVC默认把源码按本地代码页GBK去解释。如果文件是UTF-8无BOM保存，编译器可能把中文字符拆解错，轻则乱码，重则C4819警告刷屏。我在CMakeLists里加一行：

target_compile_options(ExcelImageDemo PRIVATE /utf-8)

这会让MSVC强制把源码当作UTF-8处理，中文字面量在内存里也是宽字符编码，跟Excel文本的兼容性更好。这个坑在没有中文内容的项目里不存在，但一旦你写了中文表头，几乎必踩。

5.3 图片不显示、空白和生成文件损坏问题

比编译报错更隐蔽的是“程序成功运行了，文件也生成了，但打开Excel一片空白，一张图都看不到”。

我复盘下来，主要有三个原因。

一是图片文件路径不对。worksheet_insert_image_opt的filename参数是相对路径时，它是相对于程序运行时的当前工作目录去查找的。你用VS2019运行exe时，工作目录往往是build输出目录，而照片在工程根目录的photos下，这时库不会报错，它返回的lxw_error也可能是成功，但生成的XLSX里图片区域是空的。这是因为库遇到读取失败时，内部会跳过媒体文件添加步骤，却不会中断整个workbook的写入。排查方法很简单：在插入图片前用C标准库检查文件是否存在，或者干脆把路径改成绝对路径先验证。

二是图片格式有问题。有些网站下载的JPG文件其实带Alpha通道或者异常的颜色空间，库在解析时会直接放弃。我遇到过一次公司内部系统导出的JPG，Photoshop能打开，Excel也能拖进去，但通过libxlsxwriter插进去就是空白。后来用格式转换工具重编码后才解决。遇到这种情况，建议在程序里预留一个“是否插入图片”的开关，失败时至少能记录日志继续跑，不要整个报表生成中断。

三是没有调用workbook_close()。这个前面说过，我再重复一遍是因为真的容易疏忽。workbook_close()不只是回收内存，它是把所有内部对象序列化并打包成XLSX文件的真正执行动作。只创建workbook不close，生成的文件永远是不完整的ZIP，Excel打开会提示“文件损坏需要修复”。

关于文件损坏我要多唠叨一句。如果程序在workbook_close()之前崩溃或异常退出，那个build目录下可能残留一个半成品文件，下次运行同名文件时有可能被旧文件干扰。建议每次写文件前，要么把旧文件删掉，要么用带时间戳的文件名。

6. 按项目场景总结的经验与进一步玩法

6.1 图片资源和路径管理的细节

实际做项目时，图片往往不是本地静态文件，而是程序从网络下载、从数据库导出或者从摄像头抓取的临时文件。这种情况下，建议统一把所有待插入图片先落地到一个临时目录，生成唯一文件名，比如temp_img_20250115_001.jpg，再传给libxlsxwriter。插入完成、workbook_close()之后，再统一清理临时目录。

这里有个性能相关的问题：如果一张报表要插入几十张甚至上百张图片，文件校验和读取成本会明显上升。worksheet_insert_image_opt在内部需要读取图片头部信息来确认格式和尺寸，整个过程不能并发执行。我实测最多一次插了120张图片，生成时间大约多了3秒，还能接受；但如果你的图片非常大，比如单张5MB以上，建议在插入前统一压缩到合理尺寸，既减小XLSX文件体积，也加快生成速度。

6.2 报表格式优化：行高、列宽与图片对齐

图片插入之后，表格的观感很大程度上依赖行列尺寸的配合。我写的示例代码里已经使用了两个前置设置：

worksheet_set_column(worksheet, 0, 0, 12, NULL); worksheet_set_column(worksheet, 1, 1, 30, NULL); worksheet_set_row(worksheet, 1, 60, NULL);

worksheet_set_column的第三个参数是列宽，单位是字符宽度；worksheet_set_row的第三个参数是行高，单位是磅。这两个值的数值设计直接影响图片显示效果。比如我设置B列宽度30，行高60，图片实际显示高度如果是90像素，它就会溢出到下一行，视觉上不整齐。

一个比较稳的做法是：程序里先读取图片的逻辑尺寸，用缩放比例算出显示尺寸，然后反推需要设置多少行高列宽。这个过程可能带一点试错成分，但比起反复人工调整要高效得多。我最终用的经验公式是：要让图片在表格里的显示宽度大约等于列宽字符数的7.5倍，高度大约等于行高磅数的1.33倍，单位都是像素。公式有了，程序里就能动态算行高列宽。

6.3 现有项目中的一点扩展

跑通这个功能之后，你会发现libxlsxwriter的能力远不止插图。它支持插入图表、合并单元格、单元格格式、公式写入、数据验证，甚至条件格式。我在这个巡检报表项目里又追加了三个功能：第一，给每个车间单独生成一个工作表，并用worksheet_merge_range合并标题行；第二，用worksheet_write_url在表头加一个超链接，指向内部说明页；第三，用chart_series_set_name把巡检合格率做成一个柱状图，直接贴在工作表底部。

这些功能跟图片插入在架构上是同构的：都是先向worksheet注册一个对象，最后由workbook_close()统一写出。理解了图片插入的完整链路之后，其他对象的融入难度会低很多。如果你手头也有类似“C++批量生成带图Excel报表”的需求，沿着这条路走下去，半天就能搭出一个可用的雏形。

回到开头的场景，我最想说的其实只有一句：当Excel的自动化和格式需求超出“纯文本”范围时，不要硬扛，也别第一反应就引入COM依赖。先把libxlsxwriter这类轻量库接入CMake工程试试，很多问题会简单得超出你的预期。