企业官网建设流程全解析

周五晚上七点半，Qt Creator 里 Release 模式编完，双击跑得贼溜。老板说“发个演示版给客户”，你屁颠屁颠把 MyApp.exe 拷进 U 盘，插到同事机器上——好家伙，“由于找不到 Qt5Core.dll，无法继续执行代码”。你没多想，把整个 Qt 安装目录拖过去，再点开，这次变成 “could not find or load the Qt platform plugin windows”。到这一步，恭喜你，正式进入 Qt 打包的深水区。

今天这篇不聊怎么画界面，不聊槽函数怎么写，只聊一件事：Qt 程序写完以后，怎么把它干干净净、又快又稳地交付出去。这篇文章会把我这几年用过的 Qt 打包工具全部摆出来对比，包括 windeployqt、linuxdeployqt、macdeployqt、Inno Setup、NSIS、Qt Installer Framework 以及 PyInstaller，一次性解决你“到底该用哪个”的选择困难症。

1. 先把“打包”这件事想明白：你打包的到底是什么

1.1 Qt 程序不是“一个exe”就完事：部署的本质是依赖收集

很多新手的第一反应是“把 exe 拷走不就完了”，结果就是开头那个经典报错。不理解这点，后面所有工具都用不明白。

Qt 程序默认是动态链接编译的。你写的代码最终生成一个 exe，但 exe 本身只是一张菜单和一套操作流程，真正干活的是 Qt 的 DLL 库，比如 Qt5Core.dll、Qt5Gui.dll、Qt5Widgets.dll 这些。它们负责事件循环、界面绘制、信号槽调度。程序启动时，操作系统会去 PATH 环境变量、exe 所在目录、系统目录这些地方找 DLL。Qt Creator 里能跑是因为 Qt Creator 在启动程序前帮你把 Qt 的 bin 目录塞进了环境变量，你单独双击 exe 时没人帮你了。

生活里类比一下：exe 是菜谱，DLL 是食材，插件 platforms/qwindows.dll 是厨房里的灶台和水电。光有菜谱开不了饭馆，食材工具全齐了才行。所以打包的本质就是把“食材”和“灶台”按照 Qt 规定的目录结构放到 exe 旁边，让程序走到哪儿都能找齐家伙什儿。

刚才那哥们儿把 Qt 安装目录整个拖过去，报错变成 “could not find or load the Qt platform plugin windows”，就是因为平台插件没放对位置。Qt 需要 plugins/platforms/qwindows.dll 这个插件来跟 Windows 打交道。插件是 Qt 按既定目录结构找的，而你只把 DLL 堆在根目录，它当然找不到。

1.2 三种发布形态决定工具选型：绿色便携、安装包、在线更新

动手之前先想清楚一个问题：你最终想交付一个什么东西？这决定了工具选型的方向，不能一上来就“哪个火用哪个”。

第一种是绿色便携版。解压就能用，不用安装，不写注册表，适合工具型小软件、内部工具、工程软件。Windows 上就是 exe 加一堆 DLL 的文件夹，打包成 zip 发出去；macOS 是 .app 目录；Linux 上通常是 AppImage 单文件。这类需求用官方部署工具就能搞，简单直接。

第二种是安装包。需要带桌面快捷方式、开始菜单项、卸载入口、协议页、安装路径选择，甚至要写注册表。这是普通商业软件最常见的交付形态。Windows 上你可以用 Inno Setup、NSIS，或者 Qt 官方的 Qt Installer Framework；macOS 多半是拖拽安装或者 .pkg。

第三种是带在线更新能力的安装器。用户装完基础版后可以选装组件、增量更新，软件发布新版本时可以从程序里直接拉取升级。这个场景基本只有 Qt Installer Framework 能接得住，它内置了 Updater 组件，可以做真正的“安装器 + 更新器”一体化方案。

顺带说一句，如果你的目标是嵌入式设备、工控板卡这种场景，那跟桌面发布完全是另一条路线。嵌入式通常要交叉编译、静态编译、裁剪 Qt 模块，把整个系统连同依赖做成镜像，已经不是“打包个安装程序”这么简单了。我见过不少做上位机的朋友在这上面纠结半天，最后发现目标机配置极高，直接把 Windows 桌面那一套 AppImage 类似的思路拿过去反而更快。所以先搞清楚平台再选路线。

1.3 动手前先确认三件事：编译器、Qt 模块、目标系统

打包失败的原因里，有一大半跟工具选得对不对无关，而是从一开始就“版本错位”。

第一件事，确认编译器。Qt 安装目录往往是类似 D:\Qt\5.15.2\msvc2019_64 这种路径。里面的 msvc2019_64 表示这组库是用 MSVC2019 64 位编译的。你必须用对应的编译器构建你的程序。如果 Qt 是 msvc2019 的库，你用 MinGW 编译器去编译自己的代码，windeployqt 处理起来就很容易混。同理，MinGW 版本的 Qt 要用 mingw 那条路径下的 windeployqt。现在电脑上同时装了 Qt 5.15 和 Qt 6.2 的人很多，PATH 顺序一变，打出来的包可能带着两套 Qt 库，体积翻倍还崩溃。

第二件事，确认你用到了哪些 Qt 模块。普通 Widgets 程序只用 Qt5Widgets，打包简单；但如果你用了 QML、Qt Charts、Qt WebEngine、Qt Multimedia，依赖就会多出对应模块。尤其是 WebEngine，那玩意儿自带 Chromium 内核，打包出来动辄一两百 MB，光依赖就几十个 DLL。打包工具大多数时候能自动识别，但我的习惯是心里有本账，哪些模块是必须的，哪些是可以裁的，后面做体积优化时用得上。

第三件事，确认目标系统。客户机器是 Windows 7 还是 Windows 11？32 位还是 64 位？目标机有没有显卡驱动？如果目标系统不支持某些指令集，或者缺少 VC++ 运行库，程序照样崩。Qt 5.15 之后某些版本已经不太支持 Win7 了，硬要支持得用特定构建参数。Linux 上则要关注 glibc 版本，这个放到实操部分细说。

2. 主流 Qt 打包工具全景对比

2.1 一次看懂：7 款工具的选型速查表

先把结论放前面，方便大家按图索骥：

一句话选型逻辑：Windows 桌面程序，windeployqt 生成目录 + Inno Setup 出安装包是最短路径；Linux 桌面程序，linuxdeployqt + AppImage 几乎就是标准答案；macOS 直接用 macdeployqt 加 -dmg 参数；大型商业产品且有在线更新需求，老老实实学 Qt Installer Framework；用 Python 写 Qt 界面的话，PyInstaller 是你唯一需要掌握的。

2.2 windeployqt：Windows 下的黄金搭档

windeployqt 是 Qt 官方自带的部署工具，藏在 Qt 安装目录的 bin 文件夹里。原理不复杂：读取 exe 的导入表，看它依赖哪些 Qt DLL，然后把它们递归复制到 exe 所在目录。同时，它会自动生成 platforms、styles、imageformats 等插件目录，把对应插件拷进去，再把 Qt 的翻译文件（如 qt_zh_CN.qm）也准备好。

最常用的命令这个样子：

windeployqt MyApp.exe --release --no-opengl-sw --skip-plugin-types imageformats

逐条解释一下参数。--release 告诉工具只收集 Release 版的依赖，如果你用 Debug 版 exe 跑这个命令，打出来的包会是 Debug 库，体积大还要求在目标机装调试运行库，典型新手坑。--no-opengl-sw 表示不拷贝 OpenGL 软件渲染插件，如果你的目标机器都有正常显卡驱动，这个插件用不上，能省一点体积。--skip-plugin-types imageformats 是裁剪掉图片格式插件，如果你的程序只用 PNG 图标且不加载外部图片，这个参数能减掉好几个 DLL。如果程序用了 QML，记得加 --qmldir 指向你的 qml 源码目录，否则 QML 模块不会被打包。

这个工具真正方便的地方在于：它不只处理 Qt 自带的 DLL，还会分析你在 .pro/.pri 里链接的第三方库。如果你用了自己编译的第三方 DLL，只要放在 exe 旁边能搜到，windeployqt 一般也能帮你覆盖进去。不过它毕竟不是万能钥匙，有些非 Qt 库它不管，后面还是要人工检查一遍目录。

2.3 linuxdeployqt + AppImage：Linux 分发标准答案

Linux 下的分发比 Windows 更让人头疼，因为 Linux 发行版太多，各自的 Qt 库版本和路径都不一样。你在一台 Ubuntu 上编译好，拷到另一台 Fedora 上大概率缺这个库缺那个库。主流解决方案就是 AppImage。

AppImage 的思路很讨巧：应用不安装到系统里，而是打成一个单文件。运行的时候，AppImage 自己挂载内部的文件系统，把里面预设的 Qt 库和插件暴露给应用。用户不用装任何依赖，chmod +x 之后直接运行。

linuxdeployqt 是社区维护的部署工具，即使不是官方出品，在 Qt 官方没有对应方案的情况下，它就是事实标准。基本流程是：先手动搭建一个 AppDir 目录结构，然后把编译好的程序和依赖放进去，最后用 linuxdeployqt 补全 Qt 库并用 --appimage 参数压成单文件。

一个标准的 AppDir 目录长这样：

MyApp.AppDir/ ├── MyApp ├── lib/ └── usr/ ├── bin/ ├── lib/ └── share/ ├── applications/ │ └── myapp.desktop └── icons/ └── hicolor/ └── 256x256/ └── apps/ └── myapp.png

linuxdeployqt 的原理和 windeployqt 类似，也是靠 ldd 分析依赖，把 Qt 相关的 so 文件收集到 AppDir 的 lib 目录里。但它比 windeployqt 更依赖你提供一个正确的 .desktop 文件，里面有应用名称、启动命令和图标路径。如果你不提供，工具会报错退出。

有一点要特别提醒：AppImage 对 glibc 版本非常敏感。你在 Ubuntu 22.04 上打的包，拿到 Ubuntu 20.04 上跑，很可能报 “version GLIBC_2.34 not found”。原因是你构建机自带的 glibc 版本比目标机器高。解决思路很简单：在较老的发行版上做构建，或者用 Docker 拉一个 Ubuntu 18.04/20.04 的镜像当构建环境。我自己的习惯是专门留一台老版本 Ubuntu 虚拟机做打包机，这件事后面还会提到。

2.4 macdeployqt：苹果生态的一键封装

macOS 下部署相对省心一些。Qt 官方提供了 macdeployqt，能把编译出来的 .app 目录结构补全，把所有 Qt 框架和插件塞进 .app 的 Contents/Frameworks 和 Contents/PlugIns 目录里。

日常就这么用：

macdeployqt MyApp.app -dmg

其中 -dmg 参数是让它顺手生成一个可发布的 dmg 镜像文件。如果应用需要签名，可以在打包前先用 codesign 签名，macdeployqt 也能识别已有的签名状态。

macOS 有个特殊的地方：应用程序对动态库的查找依赖 install_name 和 rpath。macdeployqt 会帮你把 Qt 库的 install_name 改成 @rpath 形式，这样应用在其他 Mac 上也能找到自己的依赖，不会出现 Windows 上那种“DLL 找不到”的土办法式报错。但如果你在构建时手动改过 rpath，或者用了非标准路径的第三方库，macdeployqt 也有可能处理不到位，装完到另一台 Mac 上双击闪退。遇到这种情况可以用 otool -L MyApp.app/Contents/MacOS/MyApp 查看实际的依赖路径，检查是否有指向你本机绝对路径的库。

2.5 Inno Setup 与 NSIS：安装包界的老将

windeployqt 解决的是“文件不齐”的问题，但交付给普通用户时，通常还要一个像样的安装程序。Windows 安装包制作工具里，最常用的两个是 Inno Setup 和 NSIS。

Inno Setup 是我个人最推荐新手学的。它免费、单文件、安装向导做得很正统，支持中文，脚本写起来是 Pascal 风格，结构清晰，网上能找到非常成熟的模板。我的经验是：从复制一份现有项目脚本改起，半小时内能出一个像模像样的安装包。典型的 .iss 脚本长这样：

[Setup] AppName=MyApp AppVersion=1.0.0 DefaultDirName={autopf}\MyApp OutputDir=installer OutputBaseFilename=MyApp_Setup_1.0.0 Compression=lzma2 SolidCompression=yes [Files] Source: "deploy\*"; DestDir: "{app}"; Flags: recursesubdirs [Icons] Name: "{autoprograms}\MyApp"; Filename: "{app}\MyApp.exe" Name: "{autodesktop}\MyApp"; Filename: "{app}\MyApp.exe" [Run] Filename: "{app}\MyApp.exe"; Description: "运行 MyApp"; Flags: nowait postinstall skipifsilent

脚本含义不复杂，[Setup] 配置安装程序本身的信息，[Files] 把整个 deploy 目录递归塞进安装目录，[Icons] 创建开始菜单和桌面快捷方式，[Run] 允许安装完成后直接启动程序。里面用 {autopf}、{app} 这类常量表示系统路径和安装目录，Inno Setup 会自动替换成实际路径。

NSIS 则是另一种风格。它的脚本语言更底层，适合喜欢折腾的人，很多专业软件（包括不少商业软件）都用 NSIS 做安装器。优点是插件生态极其丰富，可以做自定义页面、检测已安装版本、写注册表、控制服务。缺点是学习曲线陡，写一个简单的安装脚本比 Inno Setup 费劲。我给的建议是：绝大多数场景用 Inno Setup 就够了，除非你想做高度定制的安装交互体验，或者你是 NSIS 脚本老手，否则没必要为了“强大”而选 NSIS。

2.6 Qt Installer Framework：官方大杀器

Qt Installer Framework（简称 IFW）是 Qt 官方出的重型安装器，它解决的问题是“一个安装包走天下进阶版本”：用户可以自己勾选组件、选择安装路径，未来还能通过它自带的维护工具在线更新、添加删除组件。大型商业软件，比如 IDE 本身、工业软件、产品套件，很多就是用 IFW 做的。

IFW 的最小项目结构长这样：

installer/ ├── config/ │ └── config.xml └── packages/ └── org.mycompany.myapp/ ├── data/ │ └── (部署好的Qt程序文件) └── meta/ ├── package.xml └── installscript.qs

config.xml 负责描述整个安装器的元信息，比如安装器名称、发布者、初始页面。package.xml 描述这个组件的基本信息，比如名称、版本、依赖关系。installscript.qs 是 Qt Script 写的安装逻辑，可以在安装前中后执行脚本，比如检查磁盘空间、写注册表、创建快捷方式。最后用 binarycreator 命令把所有组件合成一个安装器：

binarycreator -c config/config.xml -p packages -t installer.exe MyAppInstaller.exe

IFW 的优点是正规、可控、支持在线更新。缺点是配置复杂，学习成本是这几个工具里最高的。如果你只需要做一个“装就完事”的小工具，IFW 有点杀鸡用牛刀；但如果你的产品计划发布多个版本、用户需要可控的组件安装，那 IFW 值得投入时间。

3. 完整实操：从 exe 到可分发的安装包

3.1 Windows 发布全流程实录：windeployqt + Inno Setup

我把一套完整的 Windows 发布流程拆成五步，照着做基本不会翻车。

第一步，把项目编译成 Release 版。用 Qt Creator 打开项目，切到 Release 模式，构建。此时在 build 目录下会有生成的 MyApp.exe。注意别在这个阶段去做任何手动复制 DLL 的事情，后面交给工具处理。

第二步，建一个干净的发布目录。比如 C:\release\MyApp\，把 MyApp.exe 拷进去。这个目录就是你的“部署舞台”，windeployqt 会在里面铺开依赖。

第三步，跑 windeployqt。建议直接用 Qt 安装目录自带的命令行工具路径，或者打开 Qt 的命令行环境，然后执行：

windeployqt C:\release\MyApp\MyApp.exe --release --no-opengl-sw

跑完后，你会看到 exe 旁边多了 Qt5Core.dll、Qt5Gui.dll 等一堆文件，还有 platforms、styles、translations 这些目录。整个目录现在就是一套可独立运行的绿色版程序。可以先把整个目录压缩成 zip 发给身边装了 Windows 的同事试试能不能跑，验证这一步没问题再继续。

第四步，写 Inno Setup 脚本。新建一个 .iss 文件，把上面 2.5 节里的脚本抄下来改改路径和程序名，然后打开 Inno Setup 编译器，点编译。它会生成一个 Setup.exe。我习惯给安装包加版本号和日期，比如 MyApp_Setup_1.0.0_build20240615.exe，这样发给客户时不会搞混版本。

第五步，验收。找一个没有装 Qt 的电脑或虚拟机，把 Setup.exe 拷过去，安装，运行。我的标准流程是：Win10 虚拟机装一遍、Win11 本机装一遍、顺手再关掉杀软测试一次（因为有时候杀软会对 UPX 压缩过的程序误报）。不用做太多复杂的自动化测试，重点确认程序能启动、主界面不报错、关键功能跑通。

3.2 Linux 发布全流程实录：linuxdeployqt + AppImage

Linux 下的流程我以 Ubuntu 环境为例，因为这个发行版最常见，踩坑记录也最多。

第一步，准备好构建环境。关键原则是“用老发行版构建，兼容新发行版”。我建议在 Ubuntu 18.04 或 20.04 的物理机、虚拟机或 Docker 容器里构建你的项目，这样打出来的包 glibc 版本低，拿到更新的系统上通常也没问题。如果你的开发机是 22.04 或 24.04，建议用 Docker 拉一个老版本镜像来搞，省心很多。

第二步，编译 Release 版本。方法跟 Windows 一样，在 Qt Creator 里切 Release 构建，或者在 CMake 下用 Release 配置构建。得到可执行文件 MyApp。

第三步，创建 AppDir 目录结构并拷贝基础文件：

mkdir -p MyApp.AppDir/usr/bin mkdir -p MyApp.AppDir/usr/lib mkdir -p MyApp.AppDir/usr/share/applications mkdir -p MyApp.AppDir/usr/share/icons/hicolor/256x256/apps cp MyApp MyApp.AppDir/usr/bin/ cp myapp.desktop MyApp.AppDir/usr/share/applications/ cp icon.png MyApp.AppDir/usr/share/icons/hicolor/256x256/apps/myapp.png

myapp.desktop 文件内容大致如下：

[Desktop Entry] Type=Application Name=MyApp Exec=MyApp Icon=myapp Categories=Utility;

第四步，运行 linuxdeployqt：

linuxdeployqt MyApp.AppDir/usr/share/applications/myapp.desktop -appimage

工具会扫描 MyApp 的依赖，把 Qt 相关的 so 收集到 AppDir/usr/lib 下，然后在系统里注册一个临时的 FUSE 挂载来测试 AppImage 能否正常启动。如果提示缺某个系统库（比如 libxcb），你需要先装上对应的依赖，再重新执行。

第五步，把生成的 MyApp-x86_64.AppImage 文件发给目标用户。用户只需要：

chmod +x MyApp-x86_64.AppImage ./MyApp-x86_64.AppImage

就能运行，不需要安装任何东西。这就是 AppImage 的爽快之处。

补充一个经验：如果你的目标是多个不同发行版的用户，建议至少在 Ubuntu（Debian 系）和 Fedora（RPM 系）各测试一遍。AppImage 绝大多数情况能平滑跨发行版，但偶尔会有图标主题或桌面环境兼容性的小问题。

3.3 PyQt/PySide 用户怎么搭车：PyInstaller 的“Qt 系”配置

如果你不是用 C++ 而是用 Python 写 Qt 程序（PyQt5、PyQt6、PySide6 都算），前面对的工具基本帮不上忙，你需要的打包工具是 PyInstaller。但 PyInstaller 的默认行为对 Qt 系应用并不总能一步到位，这里说几个我实测过的关键配置。

最基础的一条命令：

pyinstaller --noconsole --name MyApp --hidden-import PyQt5.sip main.py

--noconsole 是关键，它告诉 PyInstaller 这是一个 GUI 程序，不要弹黑色的命令行窗口。很多新手忘了加，结果运行程序时 Windows 下面总有黑框跟着闪，看着就像开发版一样，客户一下就觉得不专业。

--hidden-import PyQt5.sip 是为了确保 SIP 绑定模块被包含进去。PyInstaller 通常有 PyQt 的 hook，但有些场景 hook 不够完善，显式声明一下更保险。

如果你用了 Qt 的额外模块，比如 QtChart、QtWebEngine，可能需要进一步收集：

pyinstaller --noconsole --name MyApp --collect-all PyQt5 --collect-all PyQt5.QtChart main.py

--collect-all 会把对应模块的所有子模块和数据文件都塞进来。代价是体积变大，好处是几乎不会出现“运行到某行才报 ModuleNotFoundError”这种事。

如果你用了 Qt Designer 生成的 .ui 文件，并且是通过动态加载方式使用，PyInstaller 默认可能检测不到这些 .ui 文件。解决办法是在 .spec 文件里显式把 .ui 文件加进 datas：

datas=[('ui/mainwindow.ui', 'ui')]

PyInstaller 会把 data 文件解压到临时目录，用 PyQt 的 uic 加载时要注意路径获取方式，最好用 sys._MEIPASS 来定位资源文件。这也是个经典坑，主题相关，但我已经踩平了，这里提前帮你填上。

3.4 让发布自动化起来：脚本与流水线

手工一步步点击很爽，但一旦每周发版本就烦了。所以我把打包流程脚本化，放到 CI 里自动跑。

最简单的自动化，是用 shell 脚本把 windeployqt 和 Inno Setup 串起来。Windows 上可以写一个 PowerShell 脚本：

$releaseDir = "C:\release\MyApp" New-Item -ItemType Directory -Force -Path $releaseDir | Out-Null Copy-Item .\build\release\MyApp.exe $releaseDir & "D:\Qt\5.15.2\msvc2019_64\bin\windeployqt.exe" "$releaseDir\MyApp.exe" --release --no-opengl-sw & "C:\Program Files (x86)\Inno Setup 6\ISCC.exe" .\installer.iss

这个脚本把三步操作缩成一行命令：拷贝 exe、补依赖、出安装包。配合 cron 或者 Windows 任务计划程序，每天凌晨都能自动出包，手机上看一下打包邮件就行。

进阶一点，可以把发布链路放进 GitHub Actions，用 Qt 官方提供的 jurplel/install-qt-action 安装 Qt，然后跑 windeployqt 和 Inno Setup。整个流水线在云端执行，本地不需要装任何 Qt 工具。但注意 CI 环境默认是干净系统，你需要显式安装 Qt 以及必要的编译工具，否则第一次运行大概率会因为找不到 qmake 直接挂掉。

4. 我踩过的坑：常见问题与排查思路

4.1 Qt 打包常见报错速查表

这张表我建议收藏，遇到问题先对照一遍，能省下不少排查时间。

4.2 别乱设 QPA 平台插件路径：一个真实崩溃案例

我看到过有人在环境变量里设置了 QT_QPA_PLATFORM_PLUGIN_PATH，值类似 D:\Qt\5.15.2\msvc2019_64\plugins。在开发机上确实没问题，但把程序拷到客户机器上必然崩，因为那个路径在客户机上根本不存在。这种情况比单纯缺插件更隐蔽，因为你本地怎么测都是好的，发出去就炸。

核心原则是：让 windeployqt 生成的 platforms 目录自己工作，不要手动设置 QT_QPA_PLATFORM_PLUGIN_PATH，除非你有特别的需求（比如把 Qt 插件统一放在某个自定义目录）。Qt 默认会先在 exe 所在目录下找 platforms 子目录，这个机制已经足够可靠。如果你非要自定义插件路径，请用相对路径并写好判断逻辑：

QCoreApplication::setLibraryPaths(QStringList() << QCoreApplication::applicationDirPath() + "/plugins");

并确保部署目录里 plugins 的结构和内容是从原版复用过来的。我的建议是：别这么做，交给官方工具，省下的时间用来多测两遍功能，不香吗？

热词里那个 “qt_qpa_platform_plugin_pathd:\qt\5.15.2\msvc2019_64” 的报错截图，大概率就是试过“手动设路径”这个方案然后翻车了。如果网上教程让你写这个环境变量，请先动脑子判断一下，你是在给开发机配环境还是在给客户机打包，两件事不能混着来。

4.3 换台干净电脑实测：唯一靠谱的验证方式

关于打包，我交过的最贵学费是这样的：自己在开发机上跑精了，打包发出去，客户说打不开。我远程一看，报错信息在开发机上根本复现不了。原因就是开发机装过 Qt，系统全局路径里一堆 Qt DLL 顶着，缺失问题被掩盖了。你永远不能相信“开发机上看起来没问题”这件事。

所以我后来立了一条规矩：每个安装包发布前，一定要在一台完全没有 Qt 环境的电脑上跑一遍。不用真买新机器，开个虚拟机、关掉共享目录、不装开发工具，装完系统直接测安装包。Windows 用 VM 虚拟机，Linux 可以开个 Docker 容器再加个 OpenGL 验证，macOS 在虚拟机里跑 dmg 也行。整个过程自动化后也就几分钟的事，但能救回大量的客户投诉。

如果程序在干净机器上还是崩，用 Dependencies（Windows 下的依赖查看工具）打开 exe，看它实际加载了哪些 DLL，有没有指向本地路径的文件依赖。也可以在程序启动时用 Process Explorer 抓一下，看缺少哪个 DLL 导致退出。这个排查流程比坐在那猜要快得多。

4.4 体积与优化：从 200MB 到 80MB 的降级路线

项目大起来以后，安装包体积会迅速膨胀。Qt WebEngine 一上，起步就是 150MB+。这不是不能优化，但要有顺序。我的经验是：先保证正确，再做体积优化，别一上来就搞激进裁剪，最后包打不开了。

第一步，裁剪不需要的插件。windeployqt 支持 --skip-plugin-types 跳过不需要的插件类型，比如 platforms 下的 qdirect2d.dll、imageformats 下的 qmng.dll、qsvg.dll 等。你可以在部署目录里手动删掉用不到的插件，每次删完都跑一遍程序，确认不报错。

第二步，把 Debug 库彻底清干净。绝对不要用 debug 版本打包。如果部署目录里混进了带 d 后缀的 Qt5Cored.dll 之类的文件，一起删掉。Debug 库体积比 Release 大一大截，还会要求目标机有 Debug 运行库，客户电脑十有八九没有。

第三步，用 UPX 压缩可执行文件和 DLL。UPX 能把 PE 文件压缩 50% 左右，程序运行时自动解压到内存，对功能性几乎没有影响。唯一的坑是某些杀毒软件对 UPX 壳误报很高，给客户用的安装包我一般不启用这个选项。这个适合自家内部工具，或者你能确定客户那边没有敏感杀软，再考虑。

第四步，从源头裁剪。在配置 Qt 库时，用 configure 命令或者 Qt 源码编译时关闭不需要的模块，这样生成的 Qt 库本身就小很多。但这是重操作，一般项目不值得投入产出比，除非你的 Qt 是自编译且对体积有硬指标。普通项目做到前三步，体积下降 40% 到 60% 是正常的。

我个人在实际操作中最深的体会是：打包工具多到让人眼花，但你不需要全部都会，把一条链路吃透就够了。Windows 就是 windeployqt 加 Inno Setup，Linux 就是 linuxdeployqt 加 AppImage，macOS 就是 macdeployqt，Python 就是 PyInstaller。把这些组合练熟，已经能覆盖九成以上的 Qt 交付场景。最后再分享一个小技巧：把每次发布的命令、目录结构、注意要点写进项目 README 的“发布笔记”一节。三个月后你可能早忘了当初是怎么打包的，翻一下 README 三分钟就能重新上手。别问我怎么知道这一点的——都是被自己坑出来的。