企业官网建设流程全解析

简介：以 VS2017 与 MATLAB 2018b 为例，整理了一份 VS 调用 MATLAB 生成 DLL 的完整教程文档，面向需要在 C++ 与 MATLAB 之间实现混合编程的工程师。包体共 1 个 docx 文件，大小约 1.08MB，内容涵盖 MATLAB 端 library Compiler 封装 DLL、VS 中 VC++ 目录与链接器附加依赖项配置，并说明了 test.lib、mclmcr.lib 等关键库文件。文档给出了可直接参考的 C++ 调用示例，覆盖 mclInitializeApplication 初始化、mwArray 数组类传参、加法函数调用与结果输出等核心环节；同时补充了 mbuild -setup 编译语言配置，帮助读者提前搭好编译环境。已有 2553 人学习下载，适合需要快速跑通跨语言调用示例的 C++ 开发人员参考实践。

1. 为什么用VS调用MATLAB生成的DLL：一次跨语言协作的最小闭环

在 Visual Studio 里调用 MATLAB 生成的 DLL，比大多数人想象中更常见，也更坑。做上位机、做仿真验证、做算法落地的同学，经常会遇到一套算法用 MATLAB 验证得漂漂亮亮，但交付时客户端是 C++ 程序，不可能让每台目标机器都装一套 MATLAB。于是 MATLAB Compiler 把.m函数编译成 DLL，VS 这边只负责链接、传参、拿结果，这成了最经典的跨语言协作方案。

但这个方案的反直觉之处在于：真正难的不是“怎么调 DLL”，而是“怎么和 MATLAB Runtime 打交道”。凡是翻过车的都清楚，编译速度很快，VS 里 include、lib 配起来也不难，最后卡住的往往是 mwArray 的数据转换、Runtime 初始化顺序和那套版本对应的动态链接库。本文就按“MATLAB 生成 DLL → VS 配置 → 调用代码 → 避坑 → 封装复用”这条线写一遍，新手能按步骤抄，熟手也能对照检查自己漏了哪个参数。

2. MATLAB侧生成DLL：用mcc命令产出C++共享库

2.1 为什么选MATLAB Compiler而不是直接在VS里嵌MATLAB引擎

很多第一次做这个需求的人会先问：能不能在 VS 里直接调用 MATLAB 引擎 API，让程序实时跑到 MATLAB 进程里？我一般会直接劝退。MATLAB Engine 的架构是一套 C/S 模式，VS 程序启动一个 MATLAB 后台进程，然后通过 IPC 去调用命令。好处是修改.m文件立即生效，但代价是目标机器必须装完整版 MATLAB，启动要等十几秒，License 和版本冲突都是隐患。

MATLAB Compiler 生成的 DLL 则不同，它把.m函数连同依赖的 toolbox 函数一起打包进二进制库，目标机器只需要安装一个免授权场景的 MATLAB Runtime（MCR，现在一般叫 MATLAB Runtime）就能跑。对交付场景来说，这才是能规模化部署的做法。这里的代价是不能使用脚本化功能、不能访问 MATLAB 工作空间，但大多数算法函数（图像处理、矩阵计算、信号滤波）都符合打包条件。

另一个常见误区是以为生成 DLL 必须用图形界面的 Deployment Tool。命令行mcc其实更快、更可控，尤其当你有多个函数或多个-a附加资源时，写成脚本是一劳永逸的。本文的命令部分就按 mcc 展开，图形界面做的事本质上是一回事。

2.2 mcc生成C++共享库的最小命令与参数

先在 MATLAB 里写好一个最简单但能说明问题的函数。新建calcFunc.m：

function y = calcFunc(x) % 最简示例函数：输入标量 x，输出 x 平方加 2 % 实际项目里可以换成滤波、变换或任何可编译的 MATLAB 函数 y = x^2 + 2; end

然后在 MATLAB 命令行窗口执行：

mcc -W cpplib:CalcLib -T link:lib -d ./dll_output -v calcFunc.m

这条命令是生成 VS 可调的 C++ 共享库的最小形态。-W cpplib:CalcLib表示生成基于 C++ 包装的共享库，库名前缀定为 CalcLib；-T link:lib告诉编译器目标产物是链接库而不是可执行文件；-d ./dll_output指定输出目录，方便把生成物集中管理；-v开启详细输出，万一失败能看到是哪一步引起的。

代码逻辑上，mcc会先分析calcFunc.m的依赖，再用内嵌编译器把 MATLAB 代码转成 C++ 中间代码，最后调用外部 C++ 编译器生成 DLL。这里有一个隐含前提：机器上需要安装受支持的 C++ 编译器，MATLAB 才能完成编译。建议先执行mex -setup c++选好编译器，常见配置是 MSVC 对应版本，否则会报找不到编译器。

参数说明着重看两点：一是-W cpplib决定了 VS 侧拿到的是 C++ 头文件，而-W lib生成的是纯 C 接口，两者调用方式完全不同；二是-T link:lib能否成功，取决于函数里有没有使用不支持编译的代码，例如eval、脚本化变量名、某些图形句柄回调，遇到这些需要先改写。

2.3 生成目录里到底多了哪些文件

命令执行完，dll_output目录下至少会看到CalcLib.h、CalcLib.lib、CalcLib.dll，可能还有CalcLib_mcc_component_data.c和依赖分析日志。VS 侧真正关心的是前三个：头文件负责函数声明，导入库负责链接期符号解析，DLL 负责运行期实际代码。

用文本编辑器打开CalcLib.h，你会看到里面引用了mclcppclass.h、mclmcrrt.h等 MATLAB 运行时头文件，并声明了类似CalcLibInitialize()、CalcLibTerminate()的库级初始化函数。这就是 VS 项目里 include 路径必须指向 MATLAB 安装目录extern/include的原因，否则编译器会在这条链路上直接断掉。

有一点容易忽略：CalcLib.dll本身并不包含 MATLAB Runtime 代码，它依赖目标机器上的mclmcrrt.dll。这个 dll 是 MATLAB Runtime 的核心，版本必须和编译时使用的 MATLAB 版本一致。很多人以为把生成的 DLL 拿给别人就能跑，结果在对方机器上提示找不到mclmcrrt.dll，就是因为没给这个前提讲清楚。

3. VS侧项目配置：include、lib和MCR运行时的三条链路

3.1 配置包含目录和库目录：x64和Debug/Release要提前定

在 Visual Studio 里新建一个 C++ 控制台项目后，第一步先确认解决方案平台是 x64。MATLAB Compiler 生成的是 64 位 DLL，项目如果是 Win32 基本在链接阶段就宣告失败。接下来打开项目属性，找到“VC++ 目录”，把以下两项填进对应位置：

很多教程只写第一行，漏掉 dll_output，结果在包含CalcLib.h时也能编译，但链接时找不到CalcLib.lib。我一般会把这两个目录都配在项目属性里，而不是写在代码里硬编码，这样后续换版本只要改属性，不用改一行源码。

Debug 和 Release 的选择建议提前想好。MATLAB Runtime 的库是按 Release 方式编译的，我的习惯是最终交付用 Release，调试阶段用 Debug 也尽量保持相同的运行库选项。如果你在 Debug 下遇到一些匪夷所思的内存问题，先切 Release 试一下，往往症状立刻消失。

3.2 在链接器里挂上lib：附加依赖项别漏mclmcrrt

路径配置完成后，打开“链接器 → 输入 → 附加依赖项”，填上两个名字：CalcLib.lib和mclmcrrt.lib。前者是刚生成的 MATLAB 函数库，后者是 MATLAB Runtime 的导入库。漏掉 mclmcrrt 是最常见的链接错误来源，因为CalcLib.h里的初始化函数和 mwArray 类最终都指向 mclmcrrt 里的符号。

这里有个细节：mclmcrrt.lib是导入库，它不包含实现，只负责告诉链接器这些函数在mclmcrrt.dll里。因此运行期还是要保证系统能按顺序找到mclmcrrt.dll。搜索路径包括 MCR 安装目录的runtime\win64子目录，把这个目录加到系统 PATH，或者直接把 DLL 复制到可执行文件目录下。

如果你不想用附加依赖项这种隐式链接方式，也可以在代码里写#pragma comment(lib, "CalcLib.lib")，效果一样。但项目属性方式更直观，团队协作时每人打开属性就看得到依赖，不需要翻代码。

3.3 MCR运行时部署：本地开发与目标机器两条路径

本地开发时，只要 MATLAB 装在同一台机器上，Runtime 通常已经注册到了系统，VS 直接调试一般能起来。但交付到目标机器时，需要单独安装 MATLAB Runtime 运行环境。下载安装时一定要选和编译 MATLAB 大版本完全一致的分发版本，例如某版本对应 Runtime 版本号是一串数字，必须严格匹配，小版本不一致也可能导致 mwArray 内存布局冲突。

目标机器的环境变量配置也值得检查：把 MATLAB Runtime 的runtime\win64和bin\win64加入 PATH，能避免很多“DLL 已找到但依赖库找不到”的诡异问题。之所以不推荐把一堆 DLL 全部手动复制，是因为 Runtime 文件之间有相互依赖，少一个文件时弹出的提示往往不是真正的缺失项。

如果你用 MATLAB Compiler 自带的打包功能生成安装包，它会自动带上 Runtime 安装器，目标用户先装 Runtime 再运行程序即可。但这会增大安装体积，很多团队为了省这一步选择只在目标机器上安装 Runtime 独立安装包，效果相同，只是部署人员要自己盯版本。

4. 写调用代码：初始化、mwArray数据转换和异常捕获

4.1 初始化Runtime与库：顺序别颠倒

VS 里调用 MATLAB 生成的 DLL，第一个函数必须是mclInitializeApplication，第二个才是库自己的初始化函数。顺序颠倒会导致库初始化内部状态失败，常见的表现是调用返回 false，或者稍后调用算法时直接异常。

下面是一段完整的最小调用代码，对应第 2 章的calcFunc：

// CalcLibSample.cpp #include "CalcLib.h" #include <iostream> int main() { // 1. 初始化 MATLAB Runtime，参数固定传 nullptr 和 0 if (!mclInitializeApplication(nullptr, 0)) { std::cerr << "初始化 MATLAB Runtime 失败" << std::endl; return -1; } // 2. 初始化 CalcLib 库，函数名由 mcc 生成的头文件决定 if (!CalcLibInitialize()) { std::cerr << "初始化 CalcLib 失败" << std::endl; mclTerminateApplication(); return -2; } try { // 3. 构造 1x1 的 double 输入矩阵 mwArray input(1, 1, mxDOUBLE_CLASS); double inVal = 4.0; input.SetData(&inVal, 1); // 4. 调用编译后的 MATLAB 函数 mwArray output; calcFunc(1, output, input); // 5. 从输出矩阵中取出 double 值 double outVal = output.GetData<double>(); std::cout << "calcFunc(4) = " << outVal << std::endl; } catch (const mwException& e) { std::cerr << "调用异常: " << e.what() << std::endl; CalcLibTerminate(); mclTerminateApplication(); return -3; } // 6. 释放顺序与初始化相反 CalcLibTerminate(); mclTerminateApplication(); return 0; }

这段代码里的CalcLibInitialize和CalcLibTerminate是 mcc 为CalcLib生成的库级函数，不同 MATLAB 版本命名基本一致，但建议以头文件里的声明为准。调用calcFunc时第一个参数 1 表示输出参数个数，后面按顺序传输出变量和输入变量，这和 MATLAB 函数定义里的左值右值一一对应。

初始化失败时，代码里已经做了基本兜底：Runtime 初始化失败直接退出；库初始化失败则先终止 Runtime 再退出。这两个分支看着简单，实际项目里很多崩溃都是因为其中一个没写，调试器又不会明确提示是初始化不完整。

4.2 用mwArray传参：double、字符串和矩阵怎么转

MATLAB 世界里所有数据都是数组，所以 DLL 接口层不认 C++ 的int或std::string，必须包装成mwArray。它是 MATLAB Runtime 提供的一个 C++ 类，头文件mclcppclass.h里定义了构造、读取和赋值操作。

构造一个标量 double 最常见的方式是：

mwArray input(1, 1, mxDOUBLE_CLASS); double value = 42.0; input.SetData(&value, 1);

第一行创建了一个 1 行 1 列的 double 矩阵；第二行把 C++ 的 double 写进去；第三行SetData把内存中的数值拷贝到 mwArray 内部。这里如果只写构造不调用 SetData，MATLAB 函数拿到的将是未初始化内存，结果完全不可控。

读结果时用GetData<T>()，例如double out = output.GetData<double>()。如果函数返回的是矩阵而不是标量，GetData也可以把数据拷贝到预分配数组里，但一定要保证数组长度足够。我见过有人拿std::vector<double>的data()指针去接结果，却没有提前 resize，结果写入越界，排查起来很痛苦。

字符串和类型化的数组在 mwArray 里各有构造函数，比如字符串可以用mwArray str("hello")直接构造，但要注意 MATLAB 函数接口期望的是 char 数组还是 string 类型，这会影响初始化方式。最稳妥的办法是先看函数在 MATLAB 里的输入数据类型，然后在 VS 里通过mxCHAR_CLASS构造。

4.3 调用方式、返回值和异常处理

调用编译后的函数，规则基本是：第一个参数是请求的输出参数数量，后面是输出容器和所有输入参数。输出容器必须提前构造为空或正确尺寸的mwArray，不能传nullptr，否则函数内部会因为拿不到输出对象而抛出异常。

MATLAB Compiler 生成的 C++ 接口在运行出错时会抛出mwException，它继承自std::exception，所以catch (const mwException& e)和catch (const std::exception& e)都能捕获，但前者能拿到更多 MATLAB 侧的错误堆栈。调试时在 catch 里把e.what()打出来，往往能直接定位到是算法内部哪个函数报错。

如果你的 MATLAB 函数本身会出错，比如矩阵维数不匹配，这个错误不会在 DLL 内部被吞掉，而是会在调用处抛出异常。因此调用层必须有 try-catch，否则程序会直接崩溃。另一个经验是：不要在 catch 里再调用 MATLAB 的disp之类封装，因为你已经不在 MATLAB 工作空间，那只会让异常链路更乱。

5. 避坑：VS调用Matlab DLL最常见的5个翻车点

5.1 现象：链接报错unresolved external symbol

第一次编译时经常看到满屏的LNK2019 unresolved external symbol mclInitializeApplication。原因基本有四个：没有在附加依赖项里加mclmcrrt.lib；库目录指向了 32 位版本的extern\lib\win32；项目平台选成了 Win32；或者是 MATLAB 版本与 VS 编译器工具集不匹配。

解决方法是先检查项目平台是否为 x64，再打开“链接器 → 输入”，确认CalcLib.lib和mclmcrrt.lib都写进去了。如果还不行，用进程监视工具看编译器实际搜的路径，会发现库目录里第一个路径优先级最高，别让错误版本抢先命中。

5.2 现象：运行时提示缺少MSVCP140.dll或mclmcrrt.dll

开发机编译通过，一拿到目标机器去跑就弹窗，最常见的两个缺失分别是 VC++ 运行库和 MATLAB Runtime。很多人只拷了CalcLib.dll就以为万事大吉，忘了 MATLAB Runtime 本身还有几十个 DLL。

解决思路是目标机器先装对应版本的 MATLAB Runtime 独立安装包，再装 Visual C++ Redistributable x64。如果是在内网环境没法在线装，就要把 Runtime 安装包离线下载好，或者用打包工具把 Runtime 一起打进去。还有一个技巧是设置环境变量PATH指向 Runtime 的runtime\win64，比逐个复制 DLL 可靠得多。

5.3 现象：mwArray析构时崩溃或内存异常

程序功能正常，但退出时在mclTerminateApplication附近崩溃，这种玄学问题多半是释放顺序错了。MATLAB Runtime 初始化是全局状态，任何mwArray对象都存在 Runtime 分配的内存池里。如果你先调用了mclTerminateApplication，再析构后面栈上的mwArray，等于在已经被卸载的 Runtime 上操作内存，不崩才怪。

解决方案可以理解成栈式释放：先保证所有mwArray变量离开作用域，再调用CalcLibTerminate，最后才调mclTerminateApplication。项目里如果用了全局或静态的mwArray，它们的析构发生在 main 之后，很容易晚于 Runtime 终止，这种结构最好改成函数内局部变量或封装类管理。

5.4 现象：中文目录或中文文件名导致加载失败

源码放在D:\项目\发布\这样的路径下，VS 里能编译，但跑起来 DLL 初始化失败，查了一圈代码没问题。这类问题在 MATLAB Runtime 的某些版本里很典型：它对非 ASCII 路径支持不完善，导致CalcLibInitialize()找不到一些元数据文件。

解决方法是把生成目录、可执行文件路径、MCR 安装路径全部改成纯英文，连用户名的中文都最好避开。如果受制于同事的机器名是中文，可以考虑在代码里用GetShortPathNameW拿到短路径再传给 Runtime，但这属于绕路，最干净的还是部署时统一英文目录规范。

5.5 现象：Debug和Release混用导致数据错乱

Debug 下调试时函数返回结果偶尔对、偶尔错，或者堆报错，Release 却完全正常。这个问题大多出在项目运行库设置上。MATLAB Runtime 的二进制是按 release + 动态运行库/MD编译的，你的项目若是 Debug +/MT静态运行库，就会维护两套不同的堆管理器，数据跨模块传递时容易出现内存布局错位。

解决办法是在项目属性中把“C/C++ → 代码生成 → 运行库”设置为“多线程调试 DLL (/MDd)”或“多线程 DLL (/MD)”，Debug 和 Release 都保持动态链接。这个选项也影响目标机器是否需要安装对应 VC++ 运行库，但相比静默的数据错乱，这是一个明面上的依赖，反而好管理。

6. 进阶：把DLL调用封装成可复用的C++类

6.1 封装后接口长什么样

上面的流程跑通后，每次写代码都要重复初始化、调用、释放三个步骤，时间一长会很烦。我习惯把整套调用封成一个类，构造函数负责初始化，析构函数负责释放，类里面只暴露业务方法，这样业务代码永远不会漏调CalcLibTerminate。

最小封装可以这样写：

#include "CalcLib.h" #include <stdexcept> class CalcWrapper { public: CalcWrapper() { if (!mclInitializeApplication(nullptr, 0)) throw std::runtime_error("MATLAB Runtime 初始化失败"); if (!CalcLibInitialize()) { mclTerminateApplication(); throw std::runtime_error("CalcLib 初始化失败"); } m_initialized = true; } ~CalcWrapper() { if (m_initialized) { CalcLibTerminate(); mclTerminateApplication(); m_initialized = false; } } CalcWrapper(const CalcWrapper&) = delete; CalcWrapper& operator=(const CalcWrapper&) = delete; double Run(double x) { if (!m_initialized) throw std::logic_error("CalcWrapper 未初始化"); mwArray input(1, 1, mxDOUBLE_CLASS); input.SetData(&x, 1); mwArray output; calcFunc(1, output, input); return output.GetData<double>(); } private: bool m_initialized = false; };

这里有几个值得注意的细节：构造函数初始化失败要抛异常，不能让一个半初始化的对象留在调用方；析构函数里的m_initialized防止多次释放；拷贝构造被删除是因为mclInitializeApplication和CalcLibInitialize是全局过程，不应该随对象拷贝重复执行。实际项目中如果多线程同时使用，还要给Run加锁，因为 MATLAB Runtime 底层不是完全线程安全的。

6.2 用生命周期管理替代手动释放

封装类最大的收益是让“忘记释放”问题从源头上消失。在 C++ 里把对象声明成局部变量，离开作用域就会自动析构；如果程序里需要频繁切换不同 DLL，还可以把初始化检查做成手工版本，在 Debug 下输出一段日志，方便定位是哪个 DLL 没初始化。

我自己的习惯是每一个被封装的库对应一个 Wrapper，内部保存库句柄和 Runtime 状态，之后就能非常放心地在业务代码里直接写calc.Run(42)。这种方式看似多几十行代码，但省下的排查时间远不止这些。这些年用下来的最大教训是：不要迷信“生成 DLL 就能到处跑”，版本对应、路径规范和释放顺序永远优先确认。希望这篇整理能帮你少走几步弯路。

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