我刚接触 Qt 那会儿最头疼的其实不是写业务逻辑而是项目写完了不知道该怎么发给别人。Debug 模式下自己机器上跑得好好的一换电脑或者发给同事动不动就弹个“由于找不到 Qt5Core.dll”之类的错误。实际上 Qt 项目打包并没有那么玄乎关键是搞清楚 Qt 的依赖机制、选对工具、知道哪些文件必须带、哪些可以精简再加一点经验性的避坑技巧。这篇就专门把“Qt 项目打包”这件事从头到尾掰开揉碎地讲一遍。1. Qt 打包到底在做什么Qt 项目本质上不是一个“单文件程序”哪怕你写的是很小的 Hello World它也要依赖 Qt 框架自带的动态链接库比如 Qt5Core.dll、Qt5Gui.dll、Qt5Widgets.dll。在开发机上有 Qt 环境系统或者 Qt Creator 能找到这些库程序就能运行换到一台没装过 Qt 的机器上系统找不到这些 DLL自然就跑不起来。所以打包的核心工作包含三件事一是把程序依赖的 Qt 运行库、编译器运行库比如 MSVC 对应的 vc_redist、必要插件、QML 模块等一起收集齐全二是保证程序在目标机器上能正确找到这些依赖文件不依赖“修改 PATH 环境变量”这种不现实的操作三是尽量精简体积别把整个 Qt 安装目录几十个 GB 的东西全复制过去。很多人第一次打包都会走弯路直接复制 exe结果目标机器缺 DLL或者干脆把整个 Qt 文件夹拷过去又大又乱。正确思路是只把程序直接依赖的动态库和插件带上配合官方提供的 windeployqt / macdeployqt / linuxdeployqt 工具自动分析依赖再手动做少量补充和调整。这里我把打包场景分成三类平时大多数情况都能归进去场景分类目标环境依赖复杂度推荐方式本机换目录/换电脑同系统已安装部分组件中windeployqt 处理后补充缺失项发布给普通用户干净 Windows / macOS / Linux高windeployqt / macdeployqt / linuxdeployqt 安装包制作集成第三方库、特定插件任意目标环境较高在官方工具基础上手动补库、补插件下面以最常用的 Windows MSVC Qt 5.15.2 环境为主线兼顾 Qt 6 和跨平台场景把打包的实操过程和踩坑记录完整写出来。2. 核心细节解析与打包前的准备2.1 先搞清楚你的 Qt 版本和构建套件打包第一条铁律打包用的 Qt 库版本、位数、编译器套件必须和编译项目时完全一致。你用 Qt 5.15.2 MSVC2019 64 位编出来的程序就必须对应收集 5.15.2 → msvc2019_64 目录下的动态库如果项目是 MinGW 套件编的依赖的库在 MinGW 目录里两者不能混用混用轻则启动失败重则直接崩溃。个人建议在动手打包前先在 Qt Creator 里确认三点当前项目用的 Qt 版本是 5.x 还是 6.x。编译器是 MSVC 还是 MinGW是 32 位还是 64 位。是否开启了 debug/release 模式打包必须以 release 模式的 exe 为基础。一个特别容易踩的坑很多人在 Qt Creator 左侧选择器里把构建套件切到 Release点运行看着窗口弹出来了然后到 build 目录找 exe。但如果你之前没有真正执行过 Release 构建build 目录里可能是上一次 Debug 构建留下的 exe文件又大、依赖又全是带 d 后缀的调试库比如 Qt5Cored.dll这份 exe 即使带全了库也无法在干净系统上运行。务必在构建完成后到 build-release 目录下人工确认 exe 是刚生成的时间点而不是把人家的 debug 文件当成 release 去打包。2.2 Release 构建的关键选项不管用什么编译器发布版都需要在 release 模式下构建。原因很简单Debug 版依赖的 Qt 调试库体积更大、运行效率更低而且通常不会随 Qt 安装包分发导致目标机器上极难配齐依赖。更重要的是 Debug 库与 Release 库混在一起时exe 还会因为找不到调试运行时而报错排错成本直线上升。在 pro 文件里可以显式控制构建类型CONFIG(release, debug|release) { DEFINES QT_NO_DEBUG_OUTPUT }这在发布版里会自动关掉 qDebug 输出避免调试信息泄露和控制台窗口干扰。注意这行配置只会对 release 构建生效不影响日常开发时的 debug 输出可以放心加。如果你用的是 CMake Qt 6切换构建类型的常规操作是重新跑一次 CMake configure并显式指定 CMAKE_BUILD_TYPEcmake -B build-release -DCMAKE_BUILD_TYPERelease cmake --build build-release --config Release选好 Release 模式后最好把项目做一次 Clean 再 Rebuild确保没有旧的调试产物混进来。实际工作中我发现有相当一部分“打包后无法运行”的问题根子都在这一步——exe 根本就不是 release 产物。2.3 收集依赖windeployqt 的取舍与判断官方提供的 windeployqt 是目前 Windows 上最重要的依赖收集工具它在 Qt 安装目录的对应编译器套件目录下比如D:\Qt\5.15.2\msvc2019_64\bin\windeployqt.exe常见用法是把编译好的 exe 放到一个干净的文件夹里然后执行windeployqt.exe --release --no-translations --no-system-d3d-compiler --no-opengl-sw your_app.exe逐个参数说明一下这样你以后遇到异常也好排查--release 表示收集 release 库不会拖入带 d 后缀的调试文件。--no-translations 可不带 Qt 自带的语言翻译文件如果你的程序自绘所有界面文字或者只需要中文这一项能显著减少复制文件数量。--no-system-d3d-compiler 和 --no-opengl-sw 是可选优化如果项目没有用到单独的 OpenGL 软件渲染一般可以带上避免多复制几个体积较大的相关文件。如果你的程序用到了 Qt 的 imageformats比如加载 jpg、gif 等格式图片windeployqt 会自动把 plugins\imageformats 复制过去。这一点非常稳。但 windeployqt 也有局限性就是它分析不了第三方库、不会自动帮你处理系统运行库也不会管非 Qt 的私有依赖。所以我通常把它的产物看成“及格线”正式发布前还得做一次人工检查和补漏。2.4 手动补依赖识别缺什么、从哪里找识别缺失依赖的常用方案是打开 exe 的所在目录然后双击运行。如果系统报“缺少 xxx.dll”通常有两条路在 exe 旁边放一个依赖库搜索工具比如 Dependency Walker老工具已经不维护看 Qt5 的依赖经常误报谨慎参考、Process Explorer 的 DLL 列表、或者用微软的 dumpbin /dependents 查看 PE 依赖如果装了 VS可以直接用其一并分析。更直接的做法是在 Qt 安装目录里找到同名 dll复制到打包目录如果第三方 SDK 提供的是 LibDll 结构则在对应 bin 目录中找运行时。例如集成 Halcon你要带的是 halconcpp.dll而不是 halcon.lib。如何快速确定程序运行中实际加载的 DLL我这里给一个更实用的办法在打包目录启动程序打开任务管理器 → 详细信息右键选择“选择列”勾选 32 位和 DLL 列表或者直接用 Process Explorer按 CtrlD 查看软件进程加载的全部 DLL。凡是路径指向 Qt 安装目录的 dll说明它还没被打包把它们收集到程序目录即可。这个方法我用了好多年比瞪着眼睛猜哪里缺库高效得多。手动补依赖时注意一条基本原则最新版 Qt 在 Windows 上除了 Qt 自身库还可能依赖以下三类文件编译器运行库MSVC 对应的 msvcp140.dll、vcruntime140.dll、vcruntime140_1.dll 等。如果是 Qt 6还需要 vcruntime140_threads.dll。OpenSSL 库某些网络模块需要 libcrypto-1_1-x64.dll 和 libssl-1_1-x64.dllQt 6 可能是 libcrypto-3-x64.dll 等视官方构建而定。ICU 库部分带国际化功能的组件依赖 icu*.dll不过在 Windows 官方构建里比较少见。无论哪种情况从本机 Qt 安装目录手动拷贝这类 dll 只是权宜之计正式发布时建议使用官方对应版本的安装包、或者在目标机器上安装对应版本的 vc_redist.x64.exe。这里也顺便强调在 Win10/Win11 上仅靠复制 msvcp140.dll 到 exe 目录通常可行但在 Win7、Win8 上稳定性会差一些历史教训很多。2.5 精简体积与隐私安全Qt 自带的库不少哪怕只带核心库一套下来 4080 MB 很常见。但多个程序也大可不必每个都带一份 Qt 全套——如果同一个项目里有两个 exe 要一起发布先让 windeployqt 处理主程序再人工把依赖库整理一份共享出来即可或干脆把两个 exe 放在同一个发布目录下一起执行 windeployqt工具会自动去重。另一个大家容易忽略的细节是 qDebug 等调试信息如果代码里保留了大量 qDebug 输出路径、内部数据结构、甚至数据库连接串带上这些发布出去不仅影响性能还等于把系统细节暴露给使用者。建议发布前全局检索一下 qDebug把敏感内容清理掉保留关键错误日志可以通过 qInstallMessageHandler 重定向到本地文件方便售后排查又能保证信息不落到界面上。2.6 静态编译换一种思路但也换一堆坑除了动态库依赖方式Qt 本身也支持静态编译。如果采用静态编译exe 会把用到的 Qt 代码直接编进去运行时不再需要 Qt5Core.dll 这类动态库理论上复制单个 exe 就能跑。但我个人不推荐普通项目一上来就搞静态编译。原因有四一是静态编译 Qt 需要自己重新编译整个 Qt 源码耗时长、编译工具链配置繁琐二是 Qt 配套插件数据库、图像格式、TLS 后端在静态编译下可能需要手动指定或劳动量较大三是如果程序里用了 QML静态编译的配置和资源收集远比动态复杂四是 Qt 对静态编译的许可证/商业服务有特定的条款场景需要斟酌动态发布省心很多。比较合适的静态编译场景是内部工具、极简单文件小工具、以及你的发布目标系统非常陈旧例如一堆 Win7 或 XP 机器否则优先用动态依赖方案。3. 实操过程与核心环节实现现在进入正题一次完整的打包实操从目录准备、依赖收集、安装包制作到验证一步步走下来。3.1 标准发布目录的构建流程我的习惯是先建一个干净的发布目录再做事而不是把依赖直接堆在 build 目录里。比如项目名是 MyApp我习惯这么建D:\release\MyApp\ ├─ MyApp.exe ├─ platforms\qwindows.dll ├─ styles\qwindowsvistastyle.dll ├─ imageformats\... ├─ iconengines\... ├─ Qt5Core.dll ├─ Qt5Gui.dll ├─ Qt5Widgets.dll └─ ...操作流程如下在 build-release 目录里找到 MyApp.exe复制到干净目录。打开命令行cd 到该目录执行以下命令路径根据自己的安装位置调整D:\Qt\5.15.2\msvc2019_64\bin\windeployqt.exe --release --no-translations --no-system-d3d-compiler --no-opengl-sw MyApp.exe命令执行完后目录里会多出 platforms、styles、imageformats 等子目录以及 main 的 Qt5 系列 dll。这说明自动依赖收集基本完成了。如果你不确定是否漏库用一个比较简单粗暴但有效的办法把这个打包目录复制到一台完全没装 Qt 的干净虚拟机双击 exe 看是否运行。如果项目里只依赖 Widgets 和标准库到这一步通常已经能直接运行。如果用了第三方库比如 Halcon、OpenCV、MySQL 客户端库从对应 SDK 的 bin 目录把运行库复制到 exe 同目录同时注意它们自身的依赖比如 OpenCV 可能需要不同版本的 msvcp140.dll确认和 Qt 用的是同一套避免版本冲突。一个细节windeployqt 默认生成的 platforms/qwindows.dll 是根据你的编译器套件编译的版本。如果你的项目是 MSVC 编译但想在一个没有装 VC 运行库的干净系统运行除了 DLL最好一并到微软官网下载 vc_redist.x64.exe放到发布包内提示用户安装。这是最常见的现场报错“VCRUNTIME140.dll 缺失”的解决方案。3.2 Windows 下打包后的目录结构参考一个相对精简的 Widgets 项目发布目录大致长这样MyApp/ ├─ MyApp.exe ├─ D3Dcompiler_47.dll ├─ Qt5Core.dll ├─ Qt5Gui.dll ├─ Qt5Widgets.dll ├─ Qt5Network.dll (如果用网络模块) ├─ libEGL.dll ├─ libGLESv2.dll ├─ opengl32sw.dll (如果不加 --no-opengl-sw 会出现) ├─ platforms/ │ └─ qwindows.dll ├─ imageformats/ │ ├─ qjpeg.dll │ └─ qgif.dll ├─ iconengines/ │ └─ qsvgicon.dll ├─ styles/ │ └─ qwindowsvistastyle.dll └─ vc_redist.x64.exe (可选)如果项目是 QML 应用windeployqt 还会额外生成 qml 目录Qt 6 下更明显。如果你的程序只需要少许图片格式可以删掉 imageformats 下不用的 dll但这属于锦上添花的精简前提是你已经确认程序不需要这些格式否则不建议贸然删除。3.3 跨平台打包macOS 与 Linux 的差异桌面项目不只是 Windows很多人的 Qt 代码是 Windows 上编完、然后又扔到 Ubuntu 或 macOS 上交叉使用的打包方式差异很大这里补一下。macOS 打包macOS 上称为 “Bundle” 结构Qt 官方提供 macdeployqt它负责把 Qt 库拷贝进 .app/Contents/Frameworks并处理 install_name_tool 重写动态库路径最终得到一个可以双击运行的 MyApp.app/opt/Qt/5.15.2/clang_64/bin/macdeployqt build-release/MyApp.app -dmg加 -dmg 会顺便生成可发布的 dmg 镜像。注意如果项目里有第三方 dylibmacdeployqt 不一定能全部处理成功需要手动把 dylib 复制进 Contents/Frameworks 并执行 install_name_tool 修改查找路径。macOS 的依赖路径比 Windows 更“敏感”所以更建议在纯干净环境测试。Linux 打包说到 Linux这里要特别处理好“动态库通用性”问题Ubuntu 下编译如果依赖的 Qt 库版本较高拿到 Debian 或 CentOS 上经常因为 libc 版本、libstdc 版本不同跑不起来。社区常用的 linuxdeployqt 工具能自动收集主程序依赖。更稳妥的路线是把程序做进 AppImage 或者容器打包。AppImage 对用户友好无需安装、解压即运行且能内嵌绝大多数依赖。简单来说linuxdeployqt 负责收集依赖appimagetool 负责打包成 AppImage整个过程需要在你喜欢且能正常通过系统联网的干净环境完成。如果项目对系统兼容性要求极高最低成本方案还是在目标系统上重新编译一次毕竟二进制兼容在 Linux 生态里真的很难保证。3.4 使用安装包工具做安装程序依赖收集完成以后通常不直接把文件夹发给用户而是打成安装包。这里推荐两个主流且免费的工具工具特点适合场景Inno Setup轻量、脚本化、无额外运行库Windows 桌面小工具、个人项目NSIS老牌、灵活、支持插件扩展复杂安装逻辑、多语言、企业级分发Inno Setup 的脚本非常简单下面这个例子可以直接抄[Setup] AppNameMyApp AppVersion1.0.0 DefaultDirName{autopf}\MyApp OutputDirinstaller OutputBaseFilenameMyApp_Setup Compressionlzma2 SolidCompressionyes [Files] Source: D:\release\MyApp\*; DestDir: {app}; Flags: recursesubdirs [Icons] Name: {autoprograms}\MyApp.lnk; Filename: {app}\MyApp.exe注意首段里我已把默认目录设为 {autopf}也就是自动对应的 Program Files 目录变量在不同 Windows 版本上表现基本一致比死板地写死 C:\Program Files 要稳。这段脚本可以帮你一键生成安装包。关于安装包体积LZMA2 压缩能减小不少但 Qt 的 dll 本身已经比较大压缩率有限。如果要减小安装包体积可以考虑对发布目录做 UPX 压缩对 exe 和 dll 都有效但要注意 UPX 在某些杀毒软件看来可能“过于可疑”不做推荐给正式商业分发这个度自己把握。3.5 用 Process Explorer 做临场检查这里分享一个我习惯的“验证五步法”发布前做一遍能省掉很多现场售后在干净虚拟机上安装安装包。运行程序确认能正常打开主窗口。打开 Process Explorer找到进程按 CtrlD 查看已加载的 DLL 列表。确认 DLL 列表中没有任何指向 Qt 安装目录、第三方 SDK 目录的路径如果有说明依赖收集不完整。逐个验证功能性操作打开图片对话框、使用网络功能、调用数据库等确保运行时插件/模块真的在发布包内。这个五步法看起来麻烦但能覆盖到“程序能启动但某个功能崩溃”这类最隐蔽的问题。很多 Qt 程序在常见路径下能跑但只要用户点了一下“打开文件”系统找不到 jpeg 插件就静默失败或崩溃这种情况在开发机上几乎不会暴露一上干净环境就现形。4. Qt 6 打包的新变化如果你是 Qt 6 项目打包流程大体一致但有三个明显差异qml 目录空前重要Qt 6 对 QML 的依赖收集必须覆盖 qml/QtQuick、qml/QtQml 等模块windeployqt 会尽量自动化但有时你得加 --qmldir 参数指定项目源码的 qml 文件目录避免漏掉动态 import 的模块windeployqt.exe --release --qmldir . --no-translations MyApp.exe插件目录变化Qt 6 里平台插件和部分图形插件被重新整理例如 qwindows.dll 路径、qml 目录结构都有调整别拿 Qt 5 的经验硬套。编译套件对应关系更强Qt 6 的 MSVC2022 构建和 Qt 6.8.3 这类小版本之间点对点匹配更严格官方预编译库也更靠近最新编译器。如果目标机器没装对应 VC 运行库强烈建议把 vc_redist.x64.exe 放进安装包在安装时静默执行。有一个真实案例我可以分享一个 Qt 6.5 项目在 Qt Creator 中一切正常打包后到客户机器上报 qwindows.dll 找不到。排查半天发现用户机器缺少两个 VC 运行库组件而 Qt 6 内部某插件在加载时失败导致平台插件加载失败并进一步产生误导性报错。解决方式就是在安装包里预置 vc_redist.x64.exe。5. 常见问题与排查技巧实录打包这块的报错真是五花八门但 90% 的问题其实都集中在几个典型场景上。我把这些年踩坑和帮别人排查遇到的问题整理成几条。5.1 无法定位程序输入点、退出代码 0xc0000135这类报错大概率是 exe 与 Qt 库版本不匹配。常见情况是Release exe 旁边既有 Qt 5.12 的库又有 Qt 5.15 的库或者 32 位库和 64 位库混在同一目录。Windows 加载 DLL 时按搜索顺序查找会在目录中先找到一个版本不对的库并加载随后因为导出函数不匹配直接报错。建议发布目录只放一套 Qt 版本的库千万别把多版本的 dll 混在里面。如果有人告诉我“我拷了所有版本的库进去”那这个项目即使能跑起来我也要先把环境重做一遍不然迟早出问题。5.2 Qt 平台插件 “windows” 找不到相关热搜词里有一条.qpa.plugin: could not find the Qt platform plugin windows。这类报错出现时多数不是插件真的不存在而是程序找不到 platforms 目录或者 platforms 目录下插件依赖的库不全。比如在干净的机器上你把 qwindows.dll 复制了正确但没有把 Qt5Gui.dll依赖之一放在 exe 同目录插件加载失败后系统会误报找不到平台插件。这跟“库不全”有直接关联。排查顺序建议确认发布目录里存在 platforms/qwindows.dll。确认该文件没有被杀毒软件隔离。确认程序目录里所有 Qt5 系列 dll 与 qwindows.dll 版本口径一致尤其不要混用 32/64 位。如果你在打包目录运行其他 exe 时出现过同样问题多半是目录污染或杀软误删可以先复制一份到全新目录再试。5.3 中文路径与空格路径带来的问题Windows 上用中文用户名或带空格路径时Qt 打包程序偶发找不到插件。虽然现代 Windows 对空格支持较好但某些 DLL 搜索逻辑和老版插件仍存在兼容问题。发布时我尽量减少路径特殊性尽量使用纯英文路径发布。更严谨的做法是确保安装包默认安装目录合理引导用户不要手动把安装目录改到中文带空格的路径下。5.4 杀毒软件误杀与 SmartScreen 拦截Qt 程序打包后经常被某些杀毒软件误报这个情况在 Python、Electron 打包应用里也常见本质是二次编译的动态库缺少有效的代码签名信息。处理建议如果做商业分发为 exe 申请代码签名证书能从根上减少误报和 SmartScreen 黄屏。如果只做人分享或个人工具建议上传到有信誉的平台比如自己的官网、GitHub release用绿色压缩包发布能被更多用户接受。不要为了“防止误报”去混淆 dll 或用奇怪方式改壳反而更容易触发启发式查杀。不过请注意签名这件事有正规服务商和个人合规发布无冲突如果你的程序以后要卖给企业客户准备一个正规签名是值得的。5.5 Debug 版和 Release 版都带上我曾见过有人把两个版本的库都拷贝进去目录里既有 Qt5Core.dll 也有 Qt5Cored.dll想着“双保险”。这属于典型的误人误己。程序运行时只会根据自身编译属性去加载匹配的库多的那份 dll 不仅白白增加体积还可能让 IMAGE 加载器在遍历目录时先读到错误的版本然后产生更多灵异报错。5.6 使用官方插件但缺少对应 Visual C 运行库Windows 上 Qt 官方包默认是用 MSVC 编译的因此目标机器必须安装对应的 Visual C Redistributable。如果你只是复制了 Qt5Core.dll 和 Qt5Gui.dll没装运行库启动时经常会弹“VCRUNTIME140.dll 缺失”。字体、图标显示也不正常。这个没有任何取巧办法要么安装运行库要么改用 MinGW 套件编译你的 Qt 项目并把 MinGW 的运行时libgcc_s_seh-1.dll、libstdc-6.dll、libwinpthread-1.dll一并带上。这个差别在打包方案确认时就应该定好。6. 打包的体系化经验与个人心得如果你能把上面这些步骤都做到位一个 Qt 项目打包到发布状态基本没问题。但我还想掏出几条更有价值的经验——不是在步骤层面而是在“组织”层面。6.1 建立自动化打包脚本别手动操作今天项目小你可以手动点鼠标把目录建好、复制文件、运行 windeployqt但项目多了以后手动操作一定会出错。建议建立一个打包脚本bat 或 PowerShell把构建、复制、windeployqt、拷贝第三方库、调用 Inno Setup 编译全部串起来。一个简单的示例 batecho off set RELEASE_DIRD:\release\MyApp rmdir /s /q %RELEASE_DIR% mkdir %RELEASE_DIR% copy /y build-release\MyApp.exe %RELEASE_DIR%\ D:\Qt\5.15.2\msvc2019_64\bin\windeployqt.exe --release --no-translations %RELEASE_DIR%\MyApp.exe copy /y thirdparty\bin\*.dll %RELEASE_DIR%\ C:\Program Files (x86)\Inno Setup 6\ISCC.exe installer\MyApp.iss脚本里可以逐步加上压缩、改名、上传等动作。很多项目团队到了发布阶段手忙脚乱就是因为这一步没自动化。6.2 版本管理与符号对齐发布时建议把 exe 的文件版本、产品版本、版权信息设置清楚不然用户或售后同事看到安装包、文件属性都是一片空白很容易混淆版本。Qt 工程里设置版本信息的一般做法是在 pro 文件中配 VERSION或者用 windeployqt 上带 --version 参数来调试但这些都不如在 Windows 资源文件里配置靠谱。Windows 里更常见的做法是那个 .rc 文件定义 VS_VERSION_INFO这样右键文件属性能看到完整信息对售后定位问题特别有用。VERSION 1.0.0配合 .rc 文件设置文件版本和产品版本能极大方便追溯问题。6.3 第三方库的许可证合规第三个经验是关于许可证的。Qt 本身有 LGPL/商业许可之分你动态链接 Qt 库并遵守 LGPL 条款如允许用户 relink、提供适当的库版权说明等通常没问题但第三方库比如某些商用 SDK、GPL 组件的发布条款也需要一并关注。打包时把版权文件、许可证文件放到发布目录已经是行业好习惯别省这点工作量。6.4 保留一个干净打包环境最后一个建议持续准备一台没有开发工具的干净虚拟机或云桌面专门用来做发布验证。这台机器上不装 Qt、不装 VS用最接近普通用户的系统环境来安装你打的安装包、运行你的软件。它能验证“我打出来的包在真实世界里到底能不能跑”。我现在做任何发布都会在这台干净环境里重跑一遍核心功能路径确认 DLL 依赖问题真的清干净了才敢发出去。打包不只是一项“复制文件”的手艺它是在验证你对 Qt 运行模型、编译器工具链、目标系统环境的理解是否完整。第一次踩坑难免但只要你把流程脚本化、把验证标准化后面每次发布都会越来越顺。上面这套流程和坑点是我从把 Qt 程序折腾到遍地 DLL 缺失到后来能稳定输出安装包的过程里一点点攒出来的。照着走一遍相信你的项目也能顺利发出去。