做Excel自动化开发的人迟早会遇到一个绕不过去的坎VBA跑大批量数据时那叫一个慢尤其是几万行循环计算、字符串清洗甚至矩阵运算CPU占用上去了进度就是不动。我第一次碰到这个场景是在做一个模拟项目X的数据处理插件一套蒙特卡洛模拟要在VBA里跑上万次每次还要嵌套三层循环原本预计半小时跑完结果硬生生等了一个下午。后来同事提了一嘴要不把核心计算用C写成DLLVBA只负责入口和界面数据扔给DLL算。这个方案我一开始是犹豫的——毕竟C和VBA的类型系统差异大字符串和内存管理又处处是雷但在实际测过之后我发现这条路完全走得通而且性能提升是数量级的。这篇文章就把我从零开始验证过的方案完整梳理一遍C端怎么编写和导出DLLVBA端怎么声明和调用以及字符串、数组、开方、崩溃这些坑是怎么避开的。适合所有被VBA性能困扰、或者手里有现成C算法想在Office里复用的开发者无论你是第一次接触DLL还是已经写过一些Windows动态库都能从中找到可直接落地的参考。1. VBA调用C DLL到底解决了什么问题1.1 被VBA循环支配的恐惧C帮你终结先看一个最常见的痛点VBA处理大数据时的性能瓶颈。原因并不复杂VBA本质上是一种解释型语言每条语句都要经过解析、字节码生成、再执行的过程更关键的是VBA里的数组访问、字符串拼接在底层做了大量的边界检查和临时对象创建这个开销在循环体里会被放大几十上百倍。举一个我实际测过的例子在一张包含5万条记录的工作表里写一个双层嵌套循环做条件累计统计VBA大概跑了47秒。同样的逻辑用C写成DLL把数组指针传进去后计算耗时不到0.3秒。差距非常大而且数据量越大差距越夸张。C是编译型语言生成的机器指令直接访问内存循环处理5万条记录基本就是毫秒级完成。除了数值计算字符串处理也是重灾区。VBA里用拼接字符串会反复分配内存而C端处理字符串可以预分配缓冲区、原地修改字符性能完全不在一个维度。当然实际项目里不会所有代码都切到C——那样开发成本太高了。正确的思路是只把性能敏感的核心算法下沉到DLLUI、流程控制、用户交互仍然留在VBA里。VBA负责叫外卖C负责炒菜各干各擅长的事。1.2 C代码复用与算法保护的双重收益很多人觉得VBA调用C DLL只是为了性能其实还有两个隐性收益代码复用和算法保护。我先说复用。很多公司内部积累了大量的C基础库比如加密算法、图像识别、数值积分、金融定价模型等等。这些库如果要在VBA里重新实现一遍动辄几千行而且要处理VBA本身的精度限制和语法差异费力不讨好。通过DLL导出函数VBA直接就能调用现成的C能力一行Declare声明加上函数调用就搞定了。算法保护就更实际了。VBA的代码是明文存储的别人打开Excel文件就能直接查看源码即使加了工程密码也很容易被绕过。而C编译出来的DLL是二进制机器码逆向的难度大得多核心算法放在里面相对安全。我以前帮某公司封装过一个定价模型整个模型逻辑全部放进DLLVBA层只能看到函数名和参数列表完全接触不到内部实现。话虽如此也不要神话DLL——它只是一个传统意义上的动态链接库不是什么特殊的魔法工程。VBA调用C DLL和VBA调用Windows API比如user32.dll里的MessageBox在原理上完全一样都是通过导出表找到函数入口按约定把参数压栈然后调用函数。理解了这一点后面遇到的很多问题就都能用这个基础模型去解释。2. 先搞懂Windows DLL的调用原理再动手写代码2.1 动态链接库的导出表与加载机制用大白话讲DLL就是一个包含若干函数的二进制仓库。进程加载DLL时操作系统不会把整个文件一次性映射进内存等待调用而是先读取文件的导出表——这个表专门记录DLL里哪些函数可以被外部程序使用、函数入口点在哪、函数参数是什么样的——然后用一个哈希索引来加速查找。当你在VBA里写Declare Lib MathLib.dll Function... ,VBA会先根据DLL文件名去指定的目录搜索这个DLL文件找到文件后加载它再去导出表里搜索你声明的函数名找到入口点后生成一个调用指令序列。这个机制决定了三个关键事实DLL文件本身要在系统能找到的位置否则直接报找不到DLL的错误。搜索顺序大概是当前工作目录、系统目录比如System32、Path环境变量中的目录。导出函数名必须精确匹配。C的编译器在导出函数时有一套自己的重命名规则C name mangling即在函数名上附加参数类型、命名空间、调用约定等信息生成类似 ?AddYAHHHZ 的修饰符号最终导出表里的名字和你在源码里写的名字很可能是不同的。32位和64位进程只能加载对应位数的DLL。32位的Office进程加载64位DLL加载器会报告这是个无效的Win32应用程序或者直接找不到文件。2.2 extern C与__declspec(dllexport)是标配要在C里导出一个函数最常用的方式是在函数定义前加上extern C和__declspec(dllexport)。extern C的作用就是告诉编译器这个函数按C语言的方式导出不要做C的名字修饰。C语言的导出规则相对简单在32位平台下通常只在函数名前加下划线前缀在64位平台下直接就使用原始函数名因此VBA这边声明字符串会好写很多。举个例子不加extern C的C源文件里Add函数导出后的名字可能是?AddYAHHHZ这种乱七八糟的字符串加了extern C后就成了_Add832位stdcall或者直接Add64位。不管你用不用extern C只要保持两边名字一致都能调用但为了省事我强烈建议在DLL里统一用extern C包裹所有导出函数。代码长这样// MathLib.h #ifndef MATHLIB_H #define MATHLIB_H #ifdef MATHLIB_EXPORTS #define MATHLIB_API __declspec(dllexport) #else #define MATHLIB_API __declspec(dllimport) #endif extern C { MATHLIB_API double __stdcall Add(double a, double b); MATHLIB_API double __stdcall ComputeMean(double* data, int count); MATHLIB_API void __stdcall ToUpperW(wchar_t* input, wchar_t* output, int bufSize); MATHLIB_API int __stdcall SumIntArray(int* data, int count); } #endif注意这里的MATHLIB_EXPORTS宏在C工程里定义它让头文件知道当前是导出模式外部VBA调用时不需要这个宏。许多专业项目都会这么做其实是为了在同一个头文件里兼容DLL的编写端和调用端。2.3 __stdcall还是__cdecl调用约定不是随便选的调用约定决定了函数参数如何传递、由谁来清理栈空间。这个话题很枯燥但选错了程序就直接崩。绝大多数情况下VBA的Declare默认假设函数使用stdcall约定32位平台C端如果不用__stdcall而是默认的cdecl32位下你会遇到栈不平衡导致的崩溃或因为导出名不匹配cdecl导出为_Addstdcall导出为_Add8而报找不到入口点。两者的区别我整理成了表格调用约定参数入栈方式栈清理方32位导出名示例64位默认情况__stdcall从右往左压栈被调函数DLL内部_Add8默认使用该约定__cdecl从右往左压栈调用方VBA层_Add默认使用该约定64位Windows有一个设计上的好消息x64平台上只有一种统一的调用约定__stdcall和__cdecl的差异被抹平了。所以如果你的目标是64位Office这个细节不用太纠结但32位环境下你必须注意。其实还有一个更稳妥的方案在C工程里用.def文件来导出函数可以完全控制导出名根本不管编译器怎么修饰。这一点我在下一节详细讲。2.4 位数匹配规则与VBA7/PtrSafe很多人在网上抄借鉴代码结果在自己的Excel一运行就报找不到DLL入口点怎么查都查不出原因——因为没检查Office位数。VBA调用DLL有一个铁律Office进程位数必须和DLL位数一致。32位的Excel只能加载32位的DLL64位的Excel只能加载64位的DLL。这没法混用是Windows加载器的硬性规定。怎么查看你的Office是32位还是64位打开Excel依次点击文件→账户→关于Excel弹出的窗口里明确写着32位或64位。或者在VBA编辑器里运行时执行#If VBA7 And Win64 Then Debug.Print 64-bit Office #Else Debug.Print 32-bit Office #End If与此同时VBA7的语法也要求你在Declare声明中加PtrSafe关键字才能真正在64位下运行。PtrSafe的含义是这些指针在64位下是安全的不写PtrSafe64位Office会直接报编译错误。如果你需要让一段VBA代码同时兼容32位和64位Office标准写法是#If VBA7 Then Private Declare PtrSafe Function Add Lib MathLib.dll (ByVal a As Double, ByVal b As Double) As Double #Else Private Declare Function Add Lib MathLib.dll (ByVal a As Double, ByVal b As Double) As Double #End If这套条件编译模板我基本每个项目都直接用省得以后在别人机器上出幺蛾子。3. 手写一个真实可用的C DLL并在VBA里跑起来3.1 创建C工程与编译配置以Visual Studio为例新建一个动态链接库(DLL)项目或者创建空项目后手动设置。关键配置步骤项目属性→常规→配置类型选动态库(.dll)。项目属性→高级→字符集建议选使用Unicode字符集对应C里宽字符处理。在预处理器定义里加上MATHLIB_EXPORTS让源文件的导出宏生效。编译的时候注意平台选择x86或x64必须和你的Office位数对应。如果你的开发环境里没有Visual Studio也可以用MinGW-w64的g来编译但导出规则和VC略有差异需要自己处理def文件我不建议新手一开始就走这条路线。我把上面头文件对应的实现写在MathLib.cpp里// MathLib.cpp #include MathLib.h #include cstring extern C { MATHLIB_API double __stdcall Add(double a, double b) { return a b; } MATHLIB_API double __stdcall ComputeMean(double* data, int count) { if (data nullptr || count 0) return 0.0; double sum 0.0; for (int i 0; i count; i) { sum data[i]; } return sum / count; } MATHLIB_API void __stdcall ToUpperW(wchar_t* input, wchar_t* output, int bufSize) { if (input nullptr || output nullptr || bufSize 0) return; int i 0; while (input[i] ! L\0 i bufSize - 1) { wchar_t ch input[i]; if (ch La ch Lz) { ch ch - La LA; } output[i] ch; i; } output[i] L\0; } MATHLIB_API int __stdcall SumIntArray(int* data, int count) { if (data nullptr || count 0) return 0; int sum 0; for (int i 0; i count; i) { sum data[i]; } return sum; } }编译完成后会生成MathLib.dll文件正常情况下这个文件会出现在项目输出目录比如x64\Release。先放着一会儿部署。3.2 用def文件固定导出名省一万个心如果你觉得extern C stdcall的导出名规则还是麻烦我教你一个更省心的方案加一个MathLib.def文件手动列出要导出的函数名。LIBRARY MathLib EXPORTS Add ComputeMean ToUpperW SumIntArray在链接器设置里指定Module Definition File为MathLib.def。这样编译完成后无论编译器发什么疯导出表里就是干干净净的Add、ComputeMean这些名字VBA声明时直接写函数名即可甚至都不用关心32位下是否带符号。这个做法看起来多了一步实际上能规避一堆莫名奇妙的453错误。我后来所有DLL项目都保留def文件几乎没再遇到过入口点找不到的问题。3.3 VBA声明与调用模板DLL准备好了现在拿到Excel的VBA编辑器里。在标准模块的顶部写声明Option Explicit Private Declare PtrSafe Function Add Lib MathLib.dll (ByVal a As Double, ByVal b As Double) As Double Private Declare PtrSafe Function ComputeMean Lib MathLib.dll (ByRef data As Double, ByVal count As Long) As Double Private Declare PtrSafe Function ToUpperW Lib MathLib.dll (ByVal inputStr As String, ByVal outputStr As String, ByVal bufSize As Long) As Long Private Declare PtrSafe Function SumIntArray Lib MathLib.dll (ByRef firstInt As Long, ByVal count As Long) As Long注意几个细节64位下必须有PtrSafe32位下不能有用条件编译处理。ByVal a As Double对应C的double参数是传值。ByRef data As Double在C端就是double*指针我们传数组时用这种声明。String类型在ByVal修饰下VBA会传递一个指向内部宽字符缓冲区的指针也就是BSTR的内部数据指针C端可以用wchar_t*接收。然后写几个测试过程Sub Test_Add() Dim result As Double result Add(2.5, 3.7) Debug.Print Add(2.5, 3.7) ; result End Sub Sub Test_Mean() Dim arr(0 To 4) As Double arr(0) 10 arr(1) 20 arr(2) 30 arr(3) 40 arr(4) 50 传数组第一个元素的地址C端当连续数组遍历 Dim m As Double m ComputeMean(arr(0), 5) Debug.Print Mean ; m End Sub Sub Test_ToUpper() Dim src As String Dim dst As String src hello, vba-cpp dll! dst Space(255) 预分配缓冲区 ToUpperW src, dst, Len(dst) Debug.Print Trim(dst) 输出 HELLO, VBA-CPP DLL! End SubAdd和ComputeMean跑通应该没有任何问题我重点说一下Test_ToUpper里的字符串处理和数组传参的坑这是VBA和C通信最容易出bug的地方。3.4 DLL部署的几种姿势以及它们的优先级DLL编译好了总不能每次都带上Visual Studio去别人的电脑。部署方案按推荐顺序排第一和当前工作簿/加载项放在同一目录。如果你的VBA工程是Excel加载项.xlam就在加载项所在的文件夹里放MathLib.dll。VBA在搜索DLL时会先找当前工程的路径大多数情况下这样最省事。第二放到系统System32管理员权限下或SysWOW64。对于32位Office用SysWOW6464位Office用System32。如果只有自己电脑用这个是可行的但牵扯到权限问题发布给别人时还要处理DLL依赖比较麻烦。第三修改Path环境变量把DLL所在目录加进去。适合公司内部分发但每台机器都要设置IT运维成本高。我的经验是优先选择和工作簿同目录。Excel在加载DLL时会搜索当前工作目录实际上是当前工作簿所在目录不需要额外配置。这是最灵活、最不容易出权限问题的方式。还要注意VC运行库依赖。如果用Visual Studio默认编译DLL可能依赖msvcp140.dll、vcruntime140.dll等运行库。目标机器没装过VC Redistributable的话加载DLL会失败。解决办法是在编译设置里选择静态链接运行库/MT这样生成的DLL就不依赖外部运行库拷贝到任何机器都能跑代价是文件体积变大一些。4. 参数传递的真相字符串、数组与内存管理4.1 VBA与C类型对照表在写Declare之前一定要先把类型对应关系搞明白。类型对不上轻则计算出错重则内存越界崩溃。这是我整理的对照表涵盖了90%的场景VBA类型字节数C对应类型说明Byte1unsigned char处理二进制流Integer2short注意不是C intLong4int / int32_tVBA的Long在64位下仍为4字节LongLong8int64_t仅64位Office支持Single4float浮点单精度Double8double推荐浮点都用它String(ByVal)-wchar_t* 或 BSTR实际传宽字符缓冲区指针Boolean2VARIANT_BOOL与Cbool(1字节)不同Date8DATE / double本质是双精度浮点Object4/8IDispatch*涉及COM按Variant处理最容易被坑的两个点一个是IntegerVBA的Integer是2字节对应shortC的int是4字节另一个是BooleanVBA的Boolean是2字节的VARIANT_BOOL值为0或-1C的bool是1字节0或1直接对应会出乱子。明面上这些都是小类型一旦用错返回的数据面目全非。4.2 字符串是你和DLL之间的第一个雷区字符串是VBA调用DLL的深水区搞不定它就别提做复杂的文本处理了。先讲原理。VBA里的String变量在内存里是BSTR结构前面有4字节64位下也是4字节的长度前缀后面跟着UTF-16编码的宽字符数据以两个0字节结尾。当你在Declare里用ByVal str As String传参时VBA实际传递的是BSTR内部数据的首地址也就是wchar_t*。再说C端。你的DLL函数签名里如果是wchar_t*那就直接使用这个缓冲区。修改缓冲区里的内容会直接影响VBA侧的字符串因为它们是同一块内存。这个特性可以做非常高效的就地改写但也很危险如果写入的长度超过了原始缓冲区就会覆盖后面的内存VBA进程直接崩溃。所以C端写入输出字符串时必须遵守两个纪律调用方VBA提前用String Space(n)分配足够的缓冲区C端不能超出这个长度。C端在写入时始终检查bufSize参数写入的字符数不能超过bufSize-1最后补上终止符。前面ToUpperW的实现就是这样每写一个字符都检查i bufSize - 1最后output[i] L\0。这样即使调用方给的缓冲区不够也不会越界。还有一个藏在背后的要点虽然VBA字符串是BSTR但用ByVal String传给DLL时C端拿到的只是一个wchar_t*并不是BSTR头指针。所以你在C端直接用SysStringLen之类的API是拿不到长度的那个函数需要真正的BSTR头指针。长度只能靠bufSize参数传递。4.3 数组传递不要直接拿SafeArray当C数组VBA里的数组和C里的数组不完全是同一个概念。VBA数组底层是SafeArray结构它除了元素数据本身还有维数、范围、元素大小等元信息而C端的数组只是一段连续内存。不过这并不妨碍我们通过传首元素地址的方式让C端把这段内存当作普通C数组。为什么可以这样因为SafeArray的元素数据区在内存中是连续排列的对于Dim arr(0 To 4) As Double这种固定数组5个double确实是紧挨着存放的。取arr(0)的地址C端就可以用data[i]的方式访问全部元素。但这里有几个极其容易踩的坑数组必须已经初始化且确定维度不能是Redim出来的空数组更不能是动态未分配数组。VBA数组索引从0开始如果声明成Dim arr(1 To 100)数据区起始位置仍然是第0个逻辑元素的位置C端无法感知VBA的LBound你需要自己保证传过去的count和实际数据布局一致。传首元素地址时Declare里的参数必须用ByRef并且类型要和数组元素类型严格一致。例如double数组就要用ByRef data As Double。我测试过的最稳妥做法是C端拿到指针后先用静态断言确认类型大小然后在函数内部第二行就做一个堆上的拷贝用memcpy把数据复制到本地vector再处理。这样就算VBA侧在计算过程中有其他操作干扰了内存比如窗体刷新、事件触发DLL内部也不会读到被篡改的状态。性能损失很小但安全收益很大。MATHLIB_API double __stdcall ComputeMeanSafe(double* data, int count) { if (data nullptr || count 0) return 0.0; std::vectordouble copy(data, data count); double sum std::accumulate(copy.begin(), copy.end(), 0.0); return sum / count; }从性能角度讲复制一份同样大小的数据属于一次内存拷贝比整体计算的时间少一个数量级完全可以接受。4.4 ByVal与ByRef的本质传值还是传地址VBA声明里的ByVal和ByRef对应的就是C函数签名里的传值和传指针。对于数值型参数Double、Long等如果是ByValC拿到的是值的拷贝如果是ByRefC拿到的是指向调用者变量的指针可以修改它来达到返回多个值的效果。举个例子你想让一个DLL函数返回两个值——平均值和标准差——可以这样设计C端MATHLIB_API void __stdcall CalcStats(double* data, int count, double* meanOut, double* stdOut) { if (data nullptr || count 0) return; double sum 0.0; for (int i 0; i count; i) sum data[i]; double mean sum / count; double sqSum 0.0; for (int i 0; i count; i) { double diff data[i] - mean; sqSum diff * diff; } double variance sqSum / count; *meanOut mean; *stdOut sqrt(variance); }VBA端Private Declare PtrSafe Sub CalcStats Lib MathLib.dll (ByRef data As Double, ByVal count As Long, ByRef meanOut As Double, ByRef stdOut As Double) Sub Test_CalcStats() Dim arr(0 To 4) As Double arr(0) 10: arr(1) 20: arr(2) 30: arr(3) 40: arr(4) 50 Dim mean As Double Dim std As Double CalcStats arr(0), 5, mean, std Debug.Print Mean ; mean Debug.Print Std ; std End Sub这里meanOut和stdOut用ByRef声明C端用double指针接收通过meanOut mean的方式回写。如果C端需要修改调用者的字符串指针本身而不是改字符串内容那就要用双层指针VBA声明用ByRef str As StringC端签名用wchar_t**这种情况比较少见暂时不展开。5. 那些年我踩过的坑报错与排查实录5.1 运行时错误53和453到底在说什么VBA调用DLL最常见的两个运行时错误相信我你迟早会遇到。运行时错误53 文件未找到VBA在搜索路径中找不到指定的DLL文件。原因通常是DLL不在工作目录、不在地图路径、也不在系统目录或者DLL是64位的但Office是32位此时加载器也会报找不到因为它无法加载所以视同不存在还可能是DLL依赖的VC运行库缺失导致加载失败被包装成了找不到文件。排查步骤我建议按顺序来用文件资源管理器确认DLL确实存在路径是否和VBA工程工作目录一致。用记事本打开DLL看首字节或者用dumpbin /headers查看机器类型x86还是x64确认位数匹配。用Dependency Walker或者Visual Studio的dumpbin /dependents查看DLL的依赖项确认没有缺失的依赖库。运行时错误453 找不到DLL入口点DLL文件找到了并加载成功了但是导出表里没有你要的那个函数名。原因通常是函数名写错、大小写不匹配其实Windows API字符串匹配不区分大小写但导出名仍然是一个精确的字符串查找过程、C名字修饰、stdcall导出名带了符号而你写的是裸名。验证导出名的绝对可靠方法是使用Visual Studio自带工具dumpbindumpbin /exports MathLib.dll输出里会列出模块名、导出函数的序数和名字。对照一下你就知道VBA里该写Add还是_Add8了。如果你用了def文件导出名就是你在def里写的原始名字不会漂移。5.2 时好时坏的神秘崩溃八成是内存越界比起报错还有一种更让人抓狂的情况VBA代码第一次运行正常第二次运行崩溃或者数据量大一点就崩数据量小就没事。这几乎可以断定是内存越界或者缓冲区溢出。典型的场景包括输出字符串缓冲区不够C写入超过了Space(n)分配的长度。数组元素个数和传递的count不一致C读取越界。数组类型不匹配把Long数组当成Double数组传元素大小对不上。用ByVal声明了一个应该用ByRef传的指针参数导致地址被当作值传入访问非法地址。排查这种问题光靠Debug.Print是不够的建议用Visual Studio的调试器直接附加到Excel进程用VS打开C DLL的解决方案设置断点。菜单调试→附加到进程选择Excel进程。在Excel里运行VBA代码触发DLL函数。断点命中后可以查看data指针的地址、count的值甚至观察内存窗口确认数组布局是否正确。实战中我靠这招解决过一个很隐蔽的bug数组首元素指针在32位下没问题但64位下因为Office的地址空间布局差异传过来的指针总是一个奇怪的地址。后来发现是我的Declare把ByRef写成了ByVal指针值被截断成32位64位下自然就崩了。这个错误用调试器一眼就能看出来。5.3 常见问题速查表现象可能原因解决方案编译错误Declare语句不允许作为类模块中的公共成员声明写在类模块而不是标准模块移动到标准模块编译错误缺少PtrSafe64位Office下用了VBA6风格声明加PtrSafe或用条件编译运行时错误53DLL路径不对 / 位数不匹配 / 依赖库缺失检查目录、位数、依赖项运行时错误453导出名不对 / 名字修饰用Dumpbin查看导出表推荐def文件Excel秒退无提示内存越界、栈不平衡检查缓冲区长度、调用约定、ByVal/ByRef返回NaN或乱码类型映射错误、数组元素类型不符重新核对类型对照表32位正常64位崩Declare缺PtrSafe或指针被截断全项目用PtrSafeWin64条件编译这张表我每次项目结束都会更新一版踩的坑越多表越全。5.4 三个提高调试效率的实用技巧第一个技巧在VBA代码里临时加一个诊断模式。每次调用DLL之前先用条件编译命令检查一下平台#If VBA7 And Win64 Then Debug.Print Running under 64-bit Office #Else Debug.Print Running under 32-bit Office #End If这样可以第一时间排除位数不匹配的嫌疑。第二个技巧用函数指针接收返回值时注意区分出口参数和返回值。如果C函数返回的是动态分配的内存用malloc或new申请而VBA这边用As String接收返回值十有八九会泄漏内存因为VBA不知道要释放这块堆内存。更稳妥的姿势是用预分配缓冲区的出口参数而不是直接让DLL返回一个字符串指针。第三个技巧如果要在VBA里实现回调函数或者事件通知比如DLL内部进度回传给VBA可以用AddressOf操作符把VBA函数指针传给DLL。具体需要C端声明一个函数指针类型作为参数VBA端用第四个参数加上AddressOf 函数名。需要注意的是这样传递的是VBA运行时内部指针要确保VBA函数名字在模块级别且DLL在调用期间不会提前结束。最后说一个我个人的经验C DLL里的函数接口设计尽量简单、扁平不要搞花活。接口越简单编译和调用两边就越不容易出错。把复杂的封装留在C内部VBA外面永远只看到传数据、取结果这一层后续维护起来心情会好很多。如果你要在这个方向深入把64位Office的条件编译和def导出表这两个基本功练扎实后面无论接什么项目都能稳得住。