企业官网建设流程全解析

接手一个维护了五六年的老工控上位机项目时，甲方第一句话就是"编译环境别动，我们这边是 Qt 5.12.9"。这种情况下你没得选，只能老老实实去找那个 Qt 5.12.9 安装包，下载、校验、装组件、配 Kit，一路走下来。这活儿听起来简单，实际上从"下载哪个包"开始就埋着坑：有人下到只有几百兆的在线安装器，装到一半网络一断前功尽弃；有人勾了 MinGW 却发现项目依赖 WebEngine 根本编不过；还有人装完发现 qmake 版本对不上，命令行里敲出来的其实是三年前留在这台机器上的另一个版本。

这篇东西就是把这套流程完整拆一遍。内容包括 Qt 5.12.9 安装包有哪几种形态、拿到包之后组件怎么勾、Windows 下 MSVC 与 MinGW 两条链路各自怎么走通、Linux 和 macOS 上为什么完全是另一套操作、装完之后高频报错怎么从现象倒推原因，以及多版本共存怎么隔离环境。适合刚接手老项目的新人，也适合手头同时维护好几套 Qt 版本、被环境问题折腾过的人。我会尽量把"为什么这么选"讲清楚，而不是甩一串步骤让你照抄。

1. 先搞清楚 5.12.9 这个版本号在 Qt 的时间线上站在哪

动手下载之前，得先明白为什么偏偏是 5.12.9，而不是 5.12.3、5.12.12 或者 5.15。这个认知直接决定了你该下离线包还是在线包，也决定了后面遇到兼容性问题时该往哪个方向想。

1.1 LTS 分支的最后一个公开补丁版本

Qt 5.12 是官方长期支持分支，5.12.9 发布于 2019 年底，是这个分支最后一个面向所有用户公开发布的补丁版本。之后的 5.12.10、5.12.11 这些编号，只对持有商业授权的用户开放，普通开发者在公开下载渠道里是拿不到的。这就是为什么很多老项目文档里锁死的版本号就是 5.12.9——它同时满足"5.12 LTS 的稳定性"和"能公开获取"两个条件。

这个事实带来两个实际影响。第一，你不太可能找到比 5.12.9 更新的 5.12 系列安装包，网上有些所谓"5.12.12 离线包"要么是别人商业授权下的产物，来源存疑，要么根本就是改过文件名的 5.12.9。第二，如果你的项目确实需要 5.12.10 之后的补丁修复，唯一的正路是升级到 5.15 LTS 或者 6.x，而不是到处找来源不明的包。我在一个项目里见过有人拿了个来路不明的安装包，装完 Qt Creator 里的版权信息都对不上，最后整套环境推倒重来。

1.2 三种包形态：在线安装器、离线安装包、源码包

Qt 5.12.9 在不同平台上提供的包形态不一样，选错了会白折腾半天。Windows 上主要有两种：在线安装器（体积通常几十兆到一百多兆）和离线安装包（体积两个多 G）。Linux 上官方提供的是 .run 后缀的自解压安装器，也分在线和离线。macOS 上是 dmg。另外还有一份源码包 qt-everywhere-src-5.12.9，压缩后几百兆，解压出来好几个 G。

在线安装器的好处是灵活，你能精确勾选想要的模块，磁盘占用小；坏处是它依赖于安装过程中持续联网，一旦网络抖动，经常出现"下载到 80% 卡住"或者"某个模块校验失败需要重来"。离线安装包把全部组件都塞进去了，装的时候不联网，选完组件直接本地解压，稳定得多。我现在的习惯是：只要有离线包就优先用离线包，把它当成本地的一个资产存着，新机器直接拷过去，省掉每次重新下载的时间。

源码包适合的场景比较特殊：需要裁剪 Qt 体积、需要针对特定 CPU 架构编译、需要在没有图形界面的服务器上部署、或者需要给 Qt 打补丁。普通做界面开发的，别碰源码包，编译一次小半天就没了。

1.3 决定选包之前，先定死三件事

我以前吃过一次亏：先花半小时下完离线包，装完才发现项目必须用 MSVC 2017 的 64 位工具链，而我这台机器上连 Visual Studio 都没装，等于白装一遍。所以现在的顺序是反过来：先确认三件事，再去下包。

第一件是编译器。项目现有的构建脚本用的是 qmake 还是 CMake？工程文件里写的是 win32-msvc 还是 win32-g++？这两个 mkspec 直接对应两套完全不同的工具链。第二件是位数。32 位和 64 位的 Qt 库是不通用的，尤其是项目如果链接了第三方的 32 位静态库，那就只能跟着装 32 位 Qt。第三件是模块清单。项目里有没有 include QtWebEngine、QtCharts、QtDataVisualization 这类附加模块，这些在安装时是可以不勾的，不勾后面就找不到。

这三件事确认完，你才知道该下哪个平台的包、装哪个编译器版本、勾哪些组件。顺序颠倒的代价，往往就是重装一遍。

2. 组件勾选这一步，基本决定了后面九成报错的来源

安装器走到组件选择页面时，很多人的做法是"全选"，觉得多装点总没坏处。全选确实能避免漏装，但代价是磁盘占用轻松突破十个 G，而且不同编译器版本的库混在一起，后面配 Kit 的时候反而容易选错。我的建议是精准勾选，但要知道每个选项背后的含义。

2.1 MSVC 还是 MinGW：这不是喜好问题，是硬约束

这两个选项的区别，说白了是"用谁家的编译器和 C 运行库"。MSVC 走微软的工具链，需要你本机另外安装对应的 Visual Studio 或者 Build Tools，编出来的程序依赖 MSVC 运行时库（vcruntime140.dll 那一套）。MinGW 走的是 GNU 工具链在 Windows 上的移植版，Qt 安装包里直接带了 MinGW 编译器，装完就能编，不用额外装几个 G 的 IDE。

选择逻辑很直接：如果项目要链接任何用 MSVC 编译出来的第三方库（很多商业 SDK、硬件厂商提供的库都是这样），你就必须用 MSVC，因为两套工具链的 C++ ABI 不兼容，混链会出一堆链接错误。如果是一个从零开始的小工具、或者教学项目，MinGW 更省事，安装包里自带的 GDB 调试器也能直接用。

还有一个坑必须提前说：Windows 平台上的 Qt WebEngine 模块只提供 MSVC 版本，没有 MinGW 版本。如果你的项目要用到 QWebEngineView 做内嵌网页，那就没有第二条路，必须走 MSVC 链路。我在一个项目上见过有人用 MinGW 装完发现组件列表里压根没有 WebEngine 选项，还以为是自己安装包下错了。

2.2 容易被漏勾的几个模块，以及勾了会付出什么代价

Qt 5.12.9 安装器的组件树里，除了 Qt 本体之外还有一堆东西。有几个是漏了会很麻烦、但平时想不起来的：

• Qt Debug Information Files：调试信息文件。不勾的话，用 MSVC 调试器单步进 Qt 源码时会看不到变量值、调用栈也不完整。做深入排查的时候很需要，代价是占几百兆到一两个 G。
• Sources：Qt 源码。想在 IDE 里按 F2 跳进 Qt 内部实现看代码，就得勾这个。同样占空间，但对理解框架行为很有帮助。
• Qt Charts / Qt Data Visualization：做图表和数据可视化的，很多工控、仪表类项目离不开。
• Qt WebEngine：内嵌浏览器内核，体积巨大（一个 G 上下），只有 MSVC 版本。
• Qt Creator：IDE 本体，安装器默认会带一个 4.11.0 左右的版本。如果你已经有惯用的编辑器，这个可以不勾，但第一次装建议留着，它自带 Kit 配置向导，能帮你快速验证环境是否可用。

反过来，有些模块是老项目遗留的、现在基本没人用了，比如 Qt Script（已被 QJSEngine 取代）。勾了不影响什么，但会增加安装体积，也让组件列表更乱。我的原则是：项目代码里 grep 一遍#include <Qt，把实际用到的模块前缀列出来，按这个清单勾，比凭感觉选靠谱得多。

2.3 安装路径和账号环节，两个看着不起眼但很致命的地方

安装路径这件事，说一百遍都不算多：路径里不要有中文、不要有空格、不要有特殊字符。qmake 生成的 Makefile 里对路径的处理在某些环节不够健壮，路径中带空格或者中文时，经常出现"某个头文件找不到"这种莫名其妙的编译错误，排查起来能耗掉一整天。我一般直接用D:\Qt\Qt5.12.9这种清清爽爽的路径，或者C:\Qt\5.12.9。顺便说一下，路径尽量别太深，Windows 有 260 字符的路径长度限制，Qt 的某些模块（尤其是 WebEngine）中间文件路径本来就长，再叠加几层目录很容易超限。

账号环节：Qt 5.12.9 时期的安装器在开始安装前会要求登录账号，离线安装包也一样。这一步在无网络的机器上会卡死。应对办法是在有网的机器上先完成登录步骤，让安装器把凭据缓存下来，或者干脆用命令行参数跳过界面交互。我个人的做法是把离线安装包和一份安装完成后打包好的目录一起存档，新机器直接解压部署，连安装器都不用跑。

另外提醒一句：安装器在组件选择页会顺带问你要不要关联某些文件类型、要不要装示例代码。示例代码几百兆，日常开发基本不看，可以在安装时取消，需要的时候再去官网翻文档。

3. Windows 上两条工具链的实际走通过程

理论说完，进入真正的操作。Windows 是最常见的场景，这里把 MSVC 和 MinGW 两条链路分开讲，因为它们的准备工作差异很大，混着说容易乱。

3.1 MSVC 链路：先有编译器，才有 Qt

MSVC 链路的顺序不能反：先把 Visual Studio 或者 Build Tools 装好，再装 Qt。原因很简单，Qt 的 MSVC 版本在安装时并不包含编译器，安装器只放库文件和头文件；如果本机没有对应的 MSVC 工具链，装完之后 Qt Creator 的 Kit 检测会显示"编译器未找到"，你连一个空窗口都编不出来。

具体装哪个版本的 MSVC？Qt 5.12.9 提供的预编译库对应 MSVC 2015 和 MSVC 2017 两套（32 位和 64 位都有）。现在新的 Visual Studio 版本在安装时可以勾选"v141 工具集"来获得 2017 兼容的编译器，这条路径是可行的。安装时记得把"使用 C++ 的桌面开发"工作负载勾上，里面包含 MSVC 编译器、Windows SDK 和 CMake 工具；Windows SDK 别漏，缺了它会报一堆找不到 windows.h 的错误。

装完编译器之后跑 Qt 安装包，组件树里勾选Qt 5.12.9 -> MSVC 2017 64-bit（按项目位数来）。装完打开 Qt Creator，进"工具 - 选项 - Kits"，正常情况下它会自动扫描出一个 Kit：编译器指向 cl.exe，Qt Version 指向D:\Qt\Qt5.12.9\5.12.9\msvc2017_64\bin\qmake.exe。如果编译器那一栏是红的，点"编译器"标签页手动添加，路径大致在C:\Program Files (x86)\Microsoft Visual Studio\...\VC\Tools\MSVC\<版本号>\bin\Hostx64\x64\cl.exe。这一步手工配置的细节，官方文档写得比较含糊，实际就是找到 cl.exe 的确切路径填进去。

验证方式别用"新建一个空项目能不能跑"，那个太宽松了。我的做法是建一个带 QWebEngineView 或者 QChart 的测试工程，因为这些模块对工具链最挑剔，能编过基本说明环境没问题。

3.2 MinGW 链路：省事，但要接受它的边界

MinGW 链路的准备工作几乎为零，因为 Qt 安装包里自带的 MinGW 7.3.0 是完整的一套工具链，包含 gcc、g++、gdb、mingw32-make。装完 Qt 之后，Qt Creator 里一般会自动出现一个名为 "Desktop Qt 5.12.9 MinGW 64-bit" 的 Kit，直接就能用。

但省事的代价是边界更窄。前面提过 WebEngine 不支持 MinGW，这是最硬的一条。其次是调试体验：MinGW 用的 GDB 在 Windows 上对某些场景的支持不如 MSVC 调试器，比如查看 std::string 的内容、多线程死锁现场的还原，偶尔会出现显示不全的情况。另外，如果你的项目需要 profile 性能、需要 link-time optimization，MSVC 那套工具链的配套更完整。

MinGW 还有一个实际操作中会碰到的问题：make 和 mingw32-make 的混淆。如果你本机另外装过 MSYS2 或者别的 GNU 环境，PATH 里可能有一个同名的 make.exe，编译时会报各种奇怪的错误。判断方法是在命令行敲where mingw32-make，看它解析到的是不是 Qt 安装目录下那一份。这个问题我在两台机器上都遇到过，症状是编译到一半突然报"某个 .o 文件无法创建"，实际上是另一个 make 版本在解析路径。

3.3 Kit 配好之后，用一个最小工程做端到端验证

环境配完必须验证，而且验证工程要能覆盖"编译 - 链接 - 运行 - 调试"四个环节。我通常用这样一个流程：

1. 新建一个 Qt Widgets Application，构建系统选 qmake（老项目基本都是 qmake，先验证这条链路）。
2. 在 .pro 里加一行QT += core gui widgets，确认能正常解析。
3. 主窗口里放一个 QPushButton，点击弹一个 QMessageBox，编译运行，确认窗口能出来。
4. 在按钮的槽函数里打一个断点，用调试模式启动，确认能停在断点上、能看到局部变量。
5. 最后打开"编译输出"面板，确认 qmake 的版本号和路径确实指向 5.12.9，而不是机器上残留的其他版本。

第 5 步特别关键。很多人卡在"明明装的是 5.12.9，编译报的错却是 5.15 才有的语法"，本质上就是 Kit 里的 qmake 指错了。后面第 5 节会专门讲这个。

4. Linux 和 macOS 上，5.12.9 的安装完全是另一套打法

同一份 Qt 源码，到了不同平台，安装包的形态、依赖关系、坑点全都不一样。如果你的项目需要跨平台，这一节的内容迟早用得上。

4.1 Linux 上的 .run 安装器与系统依赖补全

Linux 平台官方提供的是 .run 后缀的自解压安装程序，下载下来之后第一件事是加执行权限：chmod +x qt-opensource-linux-x64-5.12.9.run，然后直接运行。图形界面版的安装器和 Windows 上长得差不多，也有组件勾选页；如果没有图形环境，可以加参数走命令行安装。

真正的麻烦在于系统依赖。Qt 的应用在 Linux 上依赖一堆 X11 和 OpenGL 相关的开发库，缺了之后的表现不是安装失败，而是"装完了，一编译就报找不到某个头文件"。5.12 这个年代的项目，通常需要装这些：OpenGL 相关的 mesa 开发包、xkbcommon 的 X11 支持、字体相关的 freetype、以及 xcb 的一堆辅助库。具体的包名在不同发行版上差异很大，我一般不去背，直接看编译报错里的缺失文件名，再反查对应的开发包。

还有一个老生常谈的点：如果是在服务器上部署，需要无界面运行，安装时要记得勾选对应平台的库，并且运行时设置QT_QPA_PLATFORM=offscreen或minimal这类平台插件，否则程序会因为找不到显示设备直接退出。

补一句实操心得：Linux 上我更倾向于用系统包管理器装 Qt，而不是用 .run 安装器，因为系统包管理器会把依赖关系一并解决。但如果你必须锁死 5.12.9，系统仓库里通常没有这个精确版本，这时候还是得用官方 .run 包，然后手工补依赖。这两条路的取舍，取决于你对版本精确度的要求有多硬。

4.2 macOS 上的 dmg 安装与几个现实限制

macOS 上官方提供的是 dmg 镜像，挂载后拖进应用目录就行，过程比 Windows 简单得多。但要注意 5.12.9 这个版本的时间点：它的预编译包是针对 Intel 架构的，在新款的 ARM 架构机器上需要通过兼容层运行。日常开发编译一般没问题，但如果你要出发布包、要做性能敏感的图形处理，那还是得考虑在 Intel 机器上做，或者升级到更新的 Qt 版本。

另一个实际会遇到的问题是签名和公证。macOS 的新系统对未签名的应用限制越来越严，从网络下载的 dmg 挂载后运行安装器时，可能提示"无法验证开发者"。这时候需要在系统的安全设置里放行，具体路径在不同版本的系统上位置不同，但都在"隐私与安全性"相关页面里。这件事只影响安装环节，装完之后 Qt Creator 本身运行是正常的。

macOS 上还有一个容易忽略的点：Xcode 命令行工具必须先装好。Qt 的 macOS 版本需要系统的 clang 工具链来编译，如果没装 Xcode Command Line Tools，Kit 配置里编译器会是空的，报错信息又很含糊。用xcode-select --install装上基本就解决了。

4.3 什么时候该老老实实编源码

前面说过，普通开发不建议碰源码包。但有两种情况绕不开：一是需要给 Qt 打补丁（比如修复某个特定平台上的崩溃），二是目标平台没有预编译包（比如某些嵌入式架构）。

编译 Qt 5.12.9 源码，关键参数就那几个。以 Linux 下为例，一个可用的配置命令大概是：

./configure -prefix /opt/qt-5.12.9 \ -opensource -confirm-license \ -nomake examples -nomake tests \ -skip qtwebengine \ -opengl desktop

逐个解释一下为什么这么写。-prefix指定安装路径，编译完成后make install会把产物放到这里，跟系统里可能存在的其他 Qt 版本隔离开；-opensource -confirm-license是明确接受开源许可，不加的话会进入交互问答；-nomake examples -nomake tests跳过示例和测试的编译，能省掉一大半时间，日常开发根本不需要；-skip qtwebengine跳过 WebEngine，这个模块编译特别慢、依赖特别多，不需要的话一定要跳掉；-opengl desktop强制使用系统桌面 OpenGL，避免去链接一些用不上的图形后端。

Windows 下编译源码要用对应的命令行环境，MSVC 的话需要先跑 vcvarsall.bat 初始化环境变量，然后configure -platform win32-msvc。整个编译过程视机器性能而定，从一小时到四五小时都有，中途内存占用也不小。

5. 装完之后那些报错，从现象倒推原因

环境装好了不代表能用。这一节列几个高频报错，以及我实际排查时的思路，尽量把"怎么想到的"也写出来，方便你举一反三。

5.1 "Unknown module(s) in QT: xxx" 到底在说什么

这个报错的意思是：.pro 文件里QT +=后面的某个模块名，qmake 在当前这套 Qt 安装里找不到。原因通常有三类。

第一类是组件根本没装。比如写了QT += webenginewidgets，但安装时勾的是 MinGW 版本，而 WebEngine 只有 MSVC 版本，自然找不到。这类问题的确认方法很直接：去看D:\Qt\Qt5.12.9\5.12.9\<你的工具链>\mkspecs\modules\目录下有没有对应的 .pri 文件，比如qt_lib_webenginewidgets.pri。有文件说明装上了，没文件就是没装。

第二类是模块名写错了。Qt 的模块名和头文件名不完全一一对应，比如头文件是<QtCharts/QChartView>，模块名要写QT += charts。这个对应关系可以查模块目录下的 .pri 文件名。

第三类比较隐蔽：项目引用了第三方模块的 .pri，但那个 .pri 里又去 include 别的模块，链条断了。这种就得一个一个往上追，看断在哪一环。

5.2 版本串味：命令行 qmake 和你以为的不是同一个

这个坑我踩过不止一次，症状是"明明装的 5.12.9，编译却报了个只在更新版本里才有的语法错误"，或者"生成的可执行文件在客户机器上跑不起来，报缺 DLL"。根因是 PATH 环境变量里存在多个 Qt 的 bin 目录，命令行走到了旧的那个。

排查方法：命令行里执行where qmake（Windows）或者which qmake（Linux/macOS），它会列出所有命中的路径，从上到下就是实际优先级。然后在命令行敲qmake -v，看输出的版本号。如果版本号和路径对不上你的预期，就去环境变量里把多余的 Qt 路径删掉，或者调整顺序。

更稳的做法是压根不依赖全局 PATH。Qt 提供了一个叫qtenv2.bat的脚本（在Qt5.12.9\5.12.9\msvc2017_64\bin目录下），运行它会临时把当前命令行的环境变量设成这套 Qt 的，关掉窗口就失效。我现在的习惯是每个项目的构建脚本第一行先调这个脚本，彻底避免串味。

5.3 编译过了，运行时报缺 DLL

这种情况九成是运行时找不到 Qt 的动态库。Windows 上的解决方式是两种：要么把Qt5.12.9\5.12.9\msvc2017_64\bin加进 PATH（仅限开发机），要么用windeployqt工具把依赖的 DLL 拷到可执行文件旁边。

windeployqt的用法很简单：命令行走 Qt 的 bin 目录，执行windeployqt --release 你的程序.exe，它会自动分析依赖并把需要的 Qt DLL、平台插件、图像格式插件都拷过去。这里有个高频坑：平台插件目录 platforms 必须存在，缺了之后程序启动会弹一个 "This application failed to start because no Qt platform plugin could be initialized"，看着吓人，实际就是少了个 qwindows.dll。windeployqt 一般会带上，但如果你是手工拷 DLL，很容易漏掉整个目录。

还有一种情况是编译器运行库缺失。MSVC 编译的程序依赖 vcruntime 和 msvcp 系列 DLL，客户机器上如果没装对应的运行库就会报错。解决方式是让用户装运行库，或者在编译时选择静态链接运行库（工程属性里改 Runtime Library 设置）。静态链接的代价是程序体积变大，以及某些场景下的许可证合规问题，选之前要掂量。

5.4 卸载重装之后的"幽灵残留"

Qt 的安装器在卸载时并不总能清干净。常见残留有三处：安装目录下剩下的空文件夹或者没被删掉的模块、用户目录下的配置文件（Qt Creator 的 Kit 配置、项目历史记录）、以及系统环境变量里指向旧路径的条目。

症状是：卸载了 5.12.3、装了 5.12.9，结果 Qt Creator 打开后 Kit 列表里还是旧的那套，构建时用的还是已经不存在的路径。这时候要去用户目录下找到 Qt Creator 的配置文件夹（Windows 上通常在%APPDATA%和%LOCALAPPDATA%里各有一个），把对应的目录整个删掉，重启 IDE 让它重新扫描。这一步不做，重装多少次都是白搭。

6. 一台机器上跑多个 Qt 版本，怎么隔离才不出事

实际工作中很少只有一套 Qt。老项目要 5.12.9，新项目可能用 5.15 或者 6.x，还有可能要给客户维护一个更老的 5.6 版本。多版本共存本身不难，难的是别让它们互相干扰。

6.1 我不建议把 Qt 加进全局 PATH 的原因

把 Qt 的 bin 目录加进系统 PATH，短期很方便，长期是灾难。原因有三：一是前面说的版本串味，命令行走错版本几乎必然发生；二是不同版本的 Qt DLL 同名，如果两个路径都在 PATH 里，加载哪个取决于顺序，而顺序在某些工具里是不可控的；三是团队协作时，你的 PATH 配置在别人机器上不存在，构建脚本就跑不通。

正确的做法是用脚本按需注入环境。Windows 下用批处理，Linux 和 macOS 下用 shell 脚本或者环境管理工具。核心逻辑就两步：先把 PATH 里所有可能干扰的 Qt 路径清理掉，再把当前项目需要的那个版本加进去。下面是一个 Windows 批处理的骨架：

@echo off set QT_ROOT=D:\Qt\Qt5.12.9\5.12.9\msvc2017_64 set PATH=%QT_ROOT%\bin;%PATH% set QTDIR=%QT_ROOT% echo Qt environment: %QT_ROOT% qmake -v

那个qmake -v是故意加的，每次激活环境都打印一次版本，眼见为实。团队里推广这套做法之后，"我这边能编你那边编不过"的问题少了一大半。

6.2 Kit 层面的隔离：命名要能一眼看出是什么

Qt Creator 里如果装了多个版本，Kit 列表会变得很长。默认命名都是 "Desktop Qt 5.12.9 MSVC2017 64bit" 这种，看多了眼花。我的习惯是手动改名字，把关键信息塞进去，比如 "Qt5.12.9-MSVC2017-64-Debug" 和 "Qt5.12.9-MinGW7.3-64-Release"，一眼就知道这个 Kit 是什么组合。

还有一点：Kit 里的 "Qt Version" 和 "Compiler" 是分开配置的，两者必须匹配。我见过有人把 Qt 的 MinGW 版本和 MSVC 编译器配在一个 Kit 里，编译直接报一堆无法解析的外部符号。这种错误信息看着复杂，根因其实很简单，就是工具链不配套。改的时候两个都改，别只改一半。

6.3 分发阶段：怎么保证客户机器上的环境和你的开发环境一致

开发环境配好了，打包发给客户，对方说"打不开"。这种问题太常见了，根源是运行时环境不一致。

我的做法是每次发布都走一遍固定的收集流程：先在一个干净的环境里（虚拟机或者一台没装过 Qt 的机器）跑一遍 windeployqt，然后手工检查几个关键目录——platforms 下的平台插件、imageformats 下的图片格式插件、如果用到 OpenGL 还要检查有没有对应的软件渲染回退。最后在那台干净机器上实际启动一次，确认能进主界面、能读到配置文件、能显示图片，才算打包完成。

这一套流程走下来多花二十分钟，但能省掉无数次"客户那边打不开"的来回沟通。我在一个交付周期很紧的项目上曾经图省事跳过了这一步，结果在交付当天发现客户机器缺运行库，临时补包折腾到半夜，这个教训记到现在。

最后分享一个我在实际维护老项目时养成的小习惯：把 Qt 5.12.9 的离线安装包、装好之后的目录压缩包、以及一份写清楚"哪个项目用哪个 Kit、构建命令是什么"的环境说明，一起放进项目的版本库或者共享盘。半年后再回来接手这个项目时，你会感谢当时的自己。环境这种东西，配的时候觉得麻烦，丢了的时候才是真麻烦。