装机量最大的桌面环境仍然是 Windows，而大量 C++ 项目最后一步都卡在同一件事上：Visual Studio 里按 F5 一切正常，把 exe 拷到别人电脑上双击就是"缺少 xxx.dll"或者 0xc000007b。我把这几年经手的项目从"能编译"打磨到"能发布"的过程整理成这篇，围绕 Visual Studio 2022 下的 C++ 项目如何打包成可独立运行的 exe，讲清楚依赖怎么清点、运行库怎么选、目录怎么摆、安装包怎么做。适合已经能写出跑得起来的程序、但一发版就被打回来的朋友，也适合接手别人遗留工程、需要一个下午摸清它到底依赖什么的人。文中不给万能脚本，给的是一套可复现的判断流程——你照着走一遍，就知道自己项目的坑在哪。

1. 从"我这能跑"到"他那打不开"：三个高频翻车现场

先把最常见的失败形态摊开来看。发布这件事的难点从来不是"怎么把 exe 拷出去"，而是"为什么我这台机器能跑、他那台不行"。这三个现场几乎覆盖了我遇到过的大半问题，对号入座能省掉很多瞎试的时间。

1.1 0xc000007b 与找不到 MSVCP140.dll 的真实含义

先说明白这个：0xc000007b是 STATUS_INVALID_IMAGE_FORMAT，名字看着像"文件损坏"，实际在九成场合下是位数不匹配。你编的是 64 位程序，依赖链里混进了一个 32 位 DLL；或者反过来。系统的加载器按顺序找同名 DLL，找到第一个就加载，加载了发现结构不对，直接抛这个错误。它不会告诉你哪个文件错了，这就是它烦人的地方。

另一类报错更直白：弹窗提示找不到MSVCP140.dll、VCRUNTIME140.dll、VCRUNTIME140_1.dll。这几个是 MSVC 的可再发行运行库，你的开发机装了 Visual Studio，它们被顺手装进了 System32，所以你本地永远正常。目标机器没装过任何开发环境，自然找不到。很多人第一反应是"那我让人装一下这个运行库合集"，能解决，但作为发布方，把这件事甩给用户是不体面的，后面第 4 节会讲两种自己兜住的办法。

还有一种更隐蔽的：api-ms-win-crt-runtime-l1-1-0.dll缺失。这属于 UCRT（通用 C 运行库），Windows 10 及以后是系统自带的，但更早的系统需要额外的系统更新才具备。这条依赖链最有迷惑性，因为它不是你的编译器直接产出的，而是由 CRT 内部的 API Set 转发出去的，用老工具查的时候经常看不全。

判断顺序建议：先看报错是"加载失败（弹窗）"还是"启动后立刻退出（0xc000007b）"。前者基本是缺文件，后者优先怀疑位数。别一上来就重装运行库，那是治标。

1.2 隐式依赖：你只拷了 exe，它还要一堆东西

第三方库分两类依赖方式。显式依赖是你代码里LoadLibrary或者链接了导入库，这类通常好发现；隐式依赖是"你链接的那个库本身还链着别的东西"，是踩坑重灾区。

举个我踩过的例子：项目引了一个图像处理库，我把它的主 DLL 拷过去了，程序启动直接崩，连报错窗口都不给。用依赖查看工具一拉链，发现这个主 DLL 又静态链进去了另外三个运行库 DLL，少一个就加载失败。这种"链式依赖"在你自己的工程里是完全看不见的，因为编译和链接阶段库的作者已经处理完了，只有运行时才暴露。

还有一类是延迟加载和插件式加载。程序启动正常，点某个功能才崩，那多半是某个功能模块通过LoadLibrary动态加载了一条你没带走的路径。这类问题在测试时容易被忽略，因为开发机上那条路径是存在的。

我的做法是把"依赖清点"当成一个独立步骤，而不是"编译完顺手拷一下"。具体工具和流程在第 3 节详细说。

1.3 工作目录与相对路径：调试器悄悄替你兜了底

这一条最坑，也最容易被忽略。Visual Studio 调试时，默认工作目录是项目目录，不是你 exe 所在的输出目录。所以你的代码里写fopen("config/settings.json", "r")或者imread("assets/logo.png")，在调试器里跑得好好的——因为项目目录下确实有这些文件。一旦你双击 exe，工作目录变成了 exe 所在的文件夹，所有相对路径全部失效。

这类问题的表现很有特点：不是崩溃，而是"功能静默失效"。配置文件读不到就走默认值，模型文件加载失败就降级，日志目录建不出来就直接不写日志。用户看到的是"这软件怎么不太对"，你看代码看不出任何毛病。

正确姿势是不要相信工作目录。启动时就把基准目录定死为 exe 自己所在的目录：

#include <filesystem> #include <windows.h> std::filesystem::path GetAppDir() { wchar_t buf[MAX_PATH]{}; ::GetModuleFileNameW(nullptr, buf, MAX_PATH); return std::filesystem::path(buf).parent_path(); } // 之后所有资源路径都基于 GetAppDir() 拼 auto cfg = GetAppDir() / L"config" / L"settings.json";

另外提醒一个反向的坑：不要图省事去SetCurrentDirectory，把工作目录改成 exe 目录。如果你后续要拉起用户选择的文件、或者调用带相对路径参数的第三方命令行工具，改工作目录会带来一连串副作用。只在自己拼路径时用绝对路径就够了，工作目录保持系统给的原样。

2. Release 配置里那几个开关，决定了后面要还多少债

很多人打包失败，根子不在打包环节，而在编译配置。项目属性面板里那几个选项，随手一改就是几种完全不同的发布形态。这一段把关键开关逐个拆开说，讲清楚每个选项改了什么、代价是什么。

2.1 运行库选项 /MD 与 /MT：不是"静态就一定好"

位置在项目属性 → C/C++ → 代码生成 → 运行库。默认 Debug 配置是"多线程调试 DLL (/MDd)"，Release 是"多线程 DLL (/MD)"。

• /MD：动态链接 MSVC 运行库，exe 体积小，但目标机需要运行库 DLL 或系统里装了可再发行包。
• /MT：静态链接运行库，运行库代码被塞进 exe，单个文件自给自足，体积大几百 KB 到 1MB 不等。
• /MDd、/MTd是调试版，绝对不能出现在发布产物里。调试版运行库依赖ucrtbased.dll这类只在开发机上存在的文件，还带大量断言开销。

选哪个？我的一般判断是：如果项目只有一个 exe，第三方库也不多，/MT最省事，拷一个文件就能发。但只要出现下面任一情况，我会退回/MD：

最后一行是关键。/MT最大的坑不是体积，而是每个模块各自持有一份 CRT 堆。A.dll 里new出来的指针，传到主程序里delete，两边的堆管理器不是同一个，轻则内存泄漏，重则直接堆损坏崩溃，而且崩的位置往往和真正出错的位置隔了很远，极难定位。我见过一个项目因为这个原因，崩了两个月都没查出来，最后发现是某个同事把运行库从/MD改成了/MT。

混合链接是最糟的组合：主程序/MT、依赖库/MD，或者反过来。链接器会给你一堆LNK4098: 默认库"LIBCMT"与其他库的使用冲突警告，这个警告不能忽略，必须清干净。

2.2 平台工具集、目标平台和 Windows SDK 版本的三重对齐

平台工具集选v143（VS 2022 自带的），这个一般不用动。真正需要关注的是目标平台和SDK 版本。

解决方案平台要明确是x86还是x64。Any CPU是 .NET 的概念，C++ 项目里没有真正的"任意"，最终一定落到某个具体架构。我接手过的工程里，有人为了"兼容性"把所有依赖都按 x86 编，结果程序能吃到的内存被卡在 2GB 上下，处理大文件时直接崩。现在除非要对接特定的老系统或老硬件，我一律 x64 起步。

Windows SDK 版本决定了你能调用哪些 API，也影响_WIN32_WINNT宏的默认值。如果你的代码里用了较新的 API，在旧系统上会因为找不到入口点而加载失败——注意这个失败发生在加载阶段，比运行时报错更早、提示更含糊。稳妥的做法是在代码里显式定义目标系统版本，并且对可能缺失的 API 用GetProcAddress动态取地址，而不是直接调用。

还有一处经常被忽略：Debug 和 Release 的位数可能不一样。项目属性是"按配置"保存的，有人只把 Release 改成 x64，Debug 还留在 Win32，结果测试用的是 32 位、发布的是 64 位，行为差异全出来了。切换配置后建议把属性面板两个配置都过一眼。

2.3 字符集、C++ 标准与二进制兼容性

字符集在项目属性 → 高级 → 字符集。默认是 Unicode，也就是宏UNICODE和_UNICODE生效。如果你的代码混用了char和wchar_t的 API 版本，或者依赖某个只支持 ANSI 的老库，容易在 Release 下暴露出来——因为不同配置的宏定义可能不一致。

C++ 语言标准同理。VS 2022 默认std::c++14，如果你改了/std:c++17或/std:c++20，要确认所有依赖库是用同等级别的标准编的。STL 在不同标准下的 ABI 有细微差别，跨模块传递std::string、std::vector时出问题的概率随之上升。

一个实用建议：把发布配置的语言标准、字符集、运行库这三项，写进项目 README 或者团队约定里。这三个参数只要有一个和依赖库不一致，排查成本就是按天算的，而且症状分散，很难和别人描述清楚。

发布前还有一个动作必须做：清理并重新生成。不要用增量编译的产物打包。我遇到过资源文件改了没生效、老的 obj 混进链接的情况，表现在 exe 里图标还是旧的。菜单里"生成 → 清理解决方案"，再"重新生成解决方案"，这两步花不了两分钟。

3. 依赖清点：把 exe 真正需要的文件一个一个列出来

这一步是整个流程里最需要耐心、也最能体现经验的地方。目标很明确：拿到一份完整的清单，写清楚 exe 旁边必须放哪些文件，一个不多一个不少。

3.1 用 dumpbin 拉出第一层依赖

VS 自带dumpbin，不需要额外装东西。从开始菜单打开"x64 Native Tools Command Prompt for VS 2022"（32 位项目就用 x86 的那个），切到输出目录：

dumpbin /dependents MyApp.exe

输出是一张表，列出所有导入的 DLL。看到的东西大概长这样：

KERNEL32.dll USER32.dll MSVCP140.dll VCRUNTIME140.dll VCRUNTIME140_1.dll opencv_world490.dll

这里要做一个重要区分：上面四行系统 DLL 不用管，它们在任何 Windows 上都存在；MSVCP140那几行是运行库，需要处理；opencv_world490.dll是第三方库，必须随包带走。判断标准很简单——文件名是KERNEL32、USER32、GDI32、ADVAPI32、SHELL32、ole32这一类 Windows 核心组件的，一律不用管。名字里带api-ms-win-前缀的也是系统转发层，不用管。

然后对每个第三方 DLL 重复这个操作，一层一层往下拉：

dumpbin /dependents opencv_world490.dll

一直拉到所有叶子节点的依赖都是系统 DLL 为止。这个过程手工做有点烦，但一般项目两三层就到底了。如果依赖特别多，可以写个脚本递归跑，注意加个已访问集合防止循环引用。

dumpbin有一个短板：它对 API Set 的解析在老版本上不完整，有时候会漏报。所以我不把它当唯一依据。

3.2 用图形化工具做交叉验证

我习惯用两个工具互补。第一是Dependencies（一个开源的可视化依赖分析工具），它支持 API Set 解析，能看到完整的加载链，还能直接看每个模块的导入导出表。用它打开 exe，左侧树状展开，红色标记的就是找不到的模块。这个"找不到"非常有价值，因为它用的搜索路径和你机器上的实际环境一致，能直接告诉你缺什么。

第二是 VS 自带的**"查看 → 其他窗口 → 模块"**调试窗口。在调试运行时打开它，能看到进程实际加载了哪些 DLL、从哪个路径加载的。这一招对排查"加载了错误版本的同名 DLL"特别有效——文件名一样但路径不对，是 DLL 地狱的经典形态。

两个工具的结果交叉一下，基本不会有遗漏。这里有个经验：以"实际运行时的模块列表"为准。因为有些库是延迟加载的，静态依赖表里看着没有，运行到某一步才加载。所以要跑一遍完整的功能流程，把模块列表导出，再和静态清单比对。

3.3 修剪第三方目录：只留 Release、只留对应位数

拿到清单之后，别急着全部拷贝。第三方库的安装目录里通常混着 Debug 版、Release 版、x86 版、x64 版、还有一堆.lib、.pdb、头文件。直接整个目录拖过去，包体积能翻好几倍。

我的规则是三条：

第一，只拷运行时需要的，不拷开发用的。.dll要，.lib、.exp、.pdb、头文件、cmake配置一律不要。

第二，只拷对应位数的。bin/x64下的，不要bin/x86。混着放最危险，因为 Windows 的 DLL 搜索顺序里，exe 所在目录优先级很高，一个错位数的同名文件就能把程序搞死，报的还只是 0xc000007b。

第三，Debug 版 DLL 一律剔除。命名规律通常是带d后缀（opencv_world490d.dll、Qt6Cored.dll）。这类文件依赖调试版运行库，发布出去必然加载失败。

顺便说一个体积优化的点：如果你的库提供world合并版和拆分版，合并版通常是单个大 DLL，拆分版是多个小 DLL。发布场景下合并版更省心（不容易漏），但如果你只需要其中一两个模块，拆分版能显著减小体积。这个取舍看具体项目，我一般是先能用合并版跑通，再考虑要不要裁。

3.4 资源、配置、模型与数据文件：和 exe 的相对关系

依赖清点不只是 DLL。很多项目还带一堆非代码文件：配置文件、图标、字体、翻译文件、模型权重、模板文档。

这些文件的组织原则只有一条：以 exe 所在目录为根，保持固定的相对结构。不要依赖"安装到某个绝对路径"，也不要依赖"用户从哪个目录启动"。第 1.3 节那个GetAppDir()在这里派上用场。

我用得最多的目录骨架是这样：

MyApp/ ├── MyApp.exe ├── *.dll # 运行库 + 第三方库 ├── config/ │ └── settings.json ├── resources/ │ ├── icons/ │ └── fonts/ ├── models/ # 大的数据文件 └── logs/ # 空目录，运行时写入

logs这个目录要特别说一句。如果程序最终装到Program Files下，普通用户对那个目录没有写权限。你的程序在开发机上写日志写得好好的，装到用户机器上就静默失败，因为CreateDirectory返回了拒绝访问，而你可能压根没检查返回值。正确做法是日志、缓存、用户数据一律写到%LOCALAPPDATA%\<你的程序名>\下面，用SHGetKnownFolderPath(FOLDERID_LocalAppData, ...)拿路径。这既是权限问题，也是多用户场景下的正确做法。

4. 让 exe 摆脱"装运行库"的两条路线

前面反复提到运行库依赖。这一节把两条主流路线掰开讲，各自的适用边界、操作细节和副作用。

4.1 静态链接运行库：一条命令换来的独立性

改法很简单：项目属性 → C/C++ → 代码生成 → 运行库 → 多线程 (/MT)，Release 配置改，Debug 配置改成/MTd（如果 Debug 也要独立跑的话）。改完清理重编，再用dumpbin /dependents看一眼，MSVCP140.dll、VCRUNTIME140.dll这几行应该全部消失。

有效是有代价的，我把代价列清楚：

• 体积增长。静态链接进来的运行库代码大概几百 KB，最终 exe 增大 300KB 到 1MB 不等，看用到的 CRT 功能多少。
• 跨模块传递对象有风险。前面 2.1 讲过，每个模块一份堆。如果你的项目是"一个 exe + 若干自己写的 DLL"，而 DLL 接口里出现了std::string、std::vector、std::shared_ptr这类 STL 类型，/MT下就要非常小心。解决办法是接口只暴露 C 风格的类型，或者用带自定义删除器的智能指针，把释放动作约束在创建它的那个模块里。
• 第三方库必须也是/MT。这一条最容易翻车。你改了主程序，依赖的预编译库还是/MD，链接器会报LNK4098，运行起来可能出现诡异的内存问题。如果第三方库只提供/MD版本（很多商业库是这样），那这条路就走不通，老老实实用第 4.2 节。

判断标准可以简化成一句话：项目是单模块、或者 DLL 接口不碰 STL，就走/MT；否则走/MD+ 随包带运行库。我现在的项目大多是后者，因为只要规模上去，模块化是必然的。

4.2 AppLocal：把运行库 DLL 放在 exe 旁边

AppLocal 部署的意思是：不要求用户在系统层面安装运行库，而是把运行库 DLL 直接放到 exe 同目录。Windows 的 DLL 搜索顺序里，exe 所在目录的优先级高于 System32，所以程序加载时会优先用到你带的那份，不用管系统里装没装。

需要拷哪些文件？用dumpbin /dependents看你的 exe 直接依赖了哪些，通常是这几个：

msvcp140.dll vcruntime140.dll vcruntime140_1.dll concrt140.dll # 用到并发运行时才需要

从%VCToolsRedistDir%下面拷贝，路径类似C:\Program Files\Microsoft Visual Studio\2022\...\VC\Redist\MSVC\<版本号>\x64\Microsoft.VC143.CRT\。注意是Redist目录，不是System32里那份——System32里的可能是被系统更新覆盖过的版本，不一定匹配你的工具集。

这里面有个坑要说清楚：UCRT 部分。ucrtbase.dll在 Windows 10 及以后是系统组件，不用带；但如果你的程序需要跑在更早的系统上，就需要额外处理，方式是用随 Visual Studio 提供的 UCRT 可再发行组件。我一般的判断是——如果明确不需要支持老系统，就不带，包更干净；如果需要，就在文档里写清楚前置条件，而不是悄悄带一堆文件让体积膨胀。

还有一件事必须做：在干净环境验证。找一台没装过 Visual Studio 的机器，或者一个全新的虚拟机快照，把整个文件夹拷过去跑。这一步不能省，因为你的机器上永远有你看不见的运行时环境。我吃过这个亏：本地全绿，发出去当天就被反馈启动不了，最后发现某个依赖是从系统目录加载的，而那个目录里的版本是某个开发工具顺手装的。

建议在虚拟机里建立三个检查项：不装任何开发工具、不要管理员权限运行、把网络断掉。断网这一条是为了排除"某功能依赖在线资源"的假象。

4.3 DLL 地狱与清单冲突：同名不同版的排查方法

有一种失败特别难查：程序能启动，但某些功能的行为和预期不一致，或者用到某功能时才崩。原因往往是加载了一个同名但版本不对的 DLL。

排查手段有两个。一是用调试器的模块窗口看实际加载路径，逐个核对是不是你预期的那个。二是用 Process Monitor 这类工具过滤Load Image事件，能看到完整的加载尝试记录，包括失败的尝试。Windows 的搜索顺序大致是：exe 目录 → 系统目录 → 当前目录 → PATH 里的目录。知道了顺序，就知道为什么"我明明拷了正确版本它不用"——大概率是系统目录里有优先级更高的同名文件，或者位数不匹配被跳过。

还有一个和清单文件相关的问题。Visual Studio 的 C++ 项目可以配置"链接器 → 清单文件 → 生成清单"。如果你的程序引用了某个带 side-by-side 清单的组件，而清单里的版本号和目标机器上实际安装的组件对不上，会报"应用程序无法启动，因为应用程序的并行配置不正确"。这类报错的排查思路是：用mt.exe把 exe 内嵌的清单提取出来看，对照依赖组件的实际版本。多数情况下，最简单的解法是放弃外部 side-by-side 依赖，改成 AppLocal 直接带文件。

5. 发布产物的目录骨架与那些"看不见"的配置

把文件凑齐只是第一步。一个能让用户双击就用的发布包，还需要图标、版本信息、权限声明这些看起来可有可无、但直接影响体验的东西。

5.1 一套可复用的目录结构与输出配置

我习惯在项目里把输出目录和中间目录分开，避免 Debug 和 Release 的 obj 文件互相污染。设置位置在项目属性 → 常规 → 输出目录 / 中间目录：

输出目录: $(SolutionDir)bin\$(Platform)\$(Configuration)\ 中间目录: $(SolutionDir)obj\$(Platform)\$(Configuration)\

这样编完之后，bin\x64\Release\下面就是干净的产物目录。再把资源文件通过生成事件 → 后期生成事件按需拷贝过去，一条xcopy就够了：

xcopy /Y /E /I "$(ProjectDir)resources" "$(OutDir)resources"

比起手工拷，写成后期事件的好处是"不会再忘"。但要注意xcopy的返回码，如果在没有文件可拷时返回非零，MSBuild 会把生成判为失败。稳妥做法是在末尾加if errorlevel 1 exit /b 0之类的容错，或者用robocopy并接受它的特殊返回码。

整个目录打包成 zip 之前，我会做一次"减法"：删掉*.pdb（除非要给用户做崩溃分析）、删掉*.lib、删掉任何名字里带d.dll的文件、删掉遗留的测试数据。这一步花三分钟，能省掉后续无数次"用户说包太大"和"为什么会有调试符号"的沟通。

5.2 应用程序清单：UAC 权限、DPI 感知与兼容性

清单文件（manifest）是个 XML，可以内嵌进 exe，也可以单独放在旁边。它决定了三件很实际的事：

第一，UAC 权限级别。默认是asInvoker，即继承启动者的权限，普通用户启动就是普通权限。如果你的程序需要写系统目录、装驱动、改注册表全局项，就要改成requireAdministrator。改的办法是在项目属性 → 链接器 → 清单文件 → UAC 执行级别里选。这里我的建议是：能不提升就不提升，代价是每次启动都弹权限确认框，用户会烦。真正需要的写操作，改成写用户目录更合适。

第二，DPI 感知。不声明 DPI 感知的程序，在高分屏上会被系统做位图拉伸，界面糊得没法看。现代做法是在清单里声明 Per-Monitor V2：

<application xmlns="urn:schemas-microsoft-com:asm.v3"> <windowsSettings> <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness> <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware> </windowsSettings> </application>

加了 Per-Monitor V2 之后，你的窗口需要在WM_DPICHANGED消息里响应缩放变化，否则多屏拖动时会错乱。这是笔额外的工作量，但对比"整个界面模糊"的体验损失，值得。

第三，兼容性声明。清单里可以声明程序适配的系统版本，影响某些 API 的行为。比如没声明的话，GetVersionEx会返回假的版本号。这块平时不太会碰到，但如果你发现程序在目标机上某个系统 API 的表现和开发机不一样，可以先看看清单。

5.3 图标、版本信息与文件属性

图标不复杂，但要注意两点。一是资源文件里IDI_ICON1的编号要设对，通常是 ID 最小的那个图标被资源管理器用作显示图标。二是一定要提供多种尺寸（16、32、48、256），只给一个 256x256 的 PNG 压缩图标，在大图标视图下好看，在任务栏小图标上会糊成一团。

版本信息更值得认真填。在资源视图里能直接编辑VERSIONINFO，填公司名（这里填你自己的或者留空）、文件说明、文件版本、产品版本。这些信息会在文件属性里显示，也是安装包和自动更新做版本比较的依据。版本号建议用主版本.次版本.修订号.构建号四段式，并且和构建流程绑定——每次正式构建自动递增构建号，避免"两个不同的包版本号一样"这种麻烦。

资源文件里如果填中文，注意.rc文件的编码问题。老版本的资源编译器对 UTF-8 支持不好，容易出现乱码。稳妥做法是.rc存成带 BOM 的 UTF-8，或者在文件头加#pragma code_page(65001)。

6. 交付形态的选择与分发前的最后一次自检

到这一步产物齐了，最后要决定的是：给用户一个压缩包，还是做一个安装程序。这个选择取决于你的用户群和使用场景，没有标准答案，但有明确的判断依据。

6.1 绿色压缩包与安装包，各自适合什么

压缩包适合：内部工具、技术人员使用、程序本身没有注册表和系统目录依赖、不需要开始菜单项。好处是零安装成本、可以多版本共存、卸载就是删文件夹。我自己的内部工具基本都是 zip + 一个说明文件。

安装包适合：面向普通用户、需要写注册表关联文件类型、需要开机自启、需要装到Program Files、需要正规的卸载入口。用户对"下载一个 exe，双击，下一步下一步"这套流程是有预期的，给个压缩包反而会让人不知所措。

如果决定做安装包，工具上我常用两类：轻量脚本型的（配置写起来直观，几分钟能跑通一个基础安装）和功能更全的（能处理复杂的组件选择、升级逻辑）。无论用哪个，几个要点是一致的：

• 安装目录默认给Program Files下的子目录，但允许用户改。
• 卸载时要清理干净：程序目录、开始菜单项、注册表项。特别注意不要误删用户数据目录。
• 不要在安装时静默安装运行库。如果你用了 4.2 的 AppLocal 方案，运行库已经在你自己的目录里，完全不需要系统级安装，也就不会和其他软件产生版本冲突。
• 加一个"安装完成后直接运行"的勾选项，用户第一次体验会顺畅很多。

如果程序需要和某个系统集成（比如注册文件类型关联），记得在安装脚本里写注册表，并且在卸载时删掉。只写不删是最常见的低级问题，用户卸载后文件图标还在，观感很差。

6.2 pdb 符号与崩溃日志：发布之后才见真章

.pdb文件不要放进发布包，但绝对不能删掉。它是把崩溃地址还原成函数名和行号的唯一凭据。我习惯把每次发布版本的 pdb 和 exe 一起归档到内部的一个目录里，按版本号命名，保留至少最近十个版本。

程序在用户那边崩了，怎么定位？两条路。一是让程序自己在崩溃时写出 dump 文件，这需要在代码里装一个未处理异常过滤器：

#include <windows.h> #include <dbghelp.h> #pragma comment(lib, "dbghelp.lib") LONG WINAPI CrashHandler(EXCEPTION_POINTERS* ep) { auto dumpPath = GetAppDir() / L"crash.dmp"; HANDLE h = ::CreateFileW(dumpPath.c_str(), GENERIC_WRITE, 0, nullptr, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, nullptr); if (h != INVALID_HANDLE_VALUE) { MINIDUMP_EXCEPTION_INFORMATION info{}; info.ThreadId = ::GetCurrentThreadId(); info.ExceptionPointers = ep; info.ClientPointers = FALSE; ::MiniDumpWriteDump(::GetCurrentProcess(), ::GetCurrentProcessId(), h, MiniDumpNormal, &info, nullptr, nullptr); ::CloseHandle(h); } return EXCEPTION_EXECUTE_HANDLER; } // 在 main 开头注册 ::SetUnhandledExceptionFilter(CrashHandler);

注意MiniDumpNormal只包含线程栈和少量信息，够用来定位崩溃位置。如果需要看局部变量，得用MiniDumpWithFullMemory，但文件会大到几百 MB，不适合让用户回传。

另一条路是靠系统的错误报告，注册表里配一个LocalDumps项，让系统在崩溃时自动落 dump。这种方式不需要改代码，适合已经发出去的老版本。

拿到 dump 之后，用调试器加载，把符号路径指到你归档的 pdb 目录，就能看到调用栈。这一步的前提是 pdb 和 exe 严格对应——所以版本管理要做好，别把 pdb 搞混了。

6.3 发布前的自检清单

最后给一份我自己的检查表，每次正式发版前照着过一遍，能拦掉八九成的问题：

最后一条要单独说。自己写的、没有数字签名的 exe，被安全软件拦下来的概率不低，尤其是程序里有网络通信、进程操作、或者打包工具生成的安装程序。如果用户群比较大，值得考虑买个代码签名证书，能显著降低误报和"这软件是不是病毒"的质疑。如果暂时不签，至少在下载页面上说明文件的大小和校验值，让用户能自行核对。

另外，把整个流程沉淀成一个脚本会省很多事。我现在的做法是：一个build.ps1负责清理、编译、拷贝资源、裁剪、打 zip；一个package.iss（或者对应的安装脚本）引用那个 zip 的内容。这样每次发版就是改个版本号、跑一条命令，人工干预越少，出错的概率越低。刚开始写脚本会觉得比手动麻烦，第三次发版之后就不会这么想了。