企业官网建设流程全解析

简介：面向使用Visual Studio 2019的C++开发者，这套Qt 5.15.16编译产物包的完整发行版，覆盖32位与64位架构，可帮助开发者省去自行编译源码的繁琐过程，直接获得集成好的Qt能力，用于桌面、命令行、嵌入式等多类应用的快速搭建。压缩包内共约2000个文件，其中以1548个头文件为主，另有Qt模块配置所需的JSON与pri文件，还包含少量调试辅助文件，资源包整体大小为753.36MB。目录按include、lib、plugins、bin四大模块清晰组织：include集中全部接口声明，lib存放已编译的链接库，plugins提供功能扩展插件，bin内置部署配置与调试工具，定位非常方便。该资源目前已有866人学习下载，尤其适合希望跳过源码编译、快速进入开发状态的初中级工程师。获取后只需配置好包含路径与链接库即可正常编码运行，显著缩短环境搭建周期，为跨平台GUI项目打下可靠基础。

1. QT5.15.16编译：为什么我劝你别直接下预编译包

把 QT5.15.16 放在 Win10 和 VS2019 环境下从源码编译，听起来像是给自己找事，但如果你遇到过官方预编译包与项目依赖库版本对不上、想开 debug 和 release 双版本却只能拿到单一配置、或者需要裁剪模块缩小安装包体积的情况，就会明白源码编译其实是绕不开的一条路。这篇笔记从环境准备讲到 configure 参数、并行编译和部署验证，全程基于我在某公司实际搭建 Qt 5.15.16 开发环境时积累下来的方案，稍微少走点弯路。你不需要多少经验，只要手上有 VS2019，跟着步骤来，就能在自己机器上跑出一套完整可用的 Qt 库，中间那些坑我也会一条条给你指出来。

2. 先搞清楚为什么值得自己编：预编译包和源码构建的差别

2.1 官方二进制包够用，但有几个场景绕不过去

Qt 官方为 Windows 提供了 msvc2019_64 的预编译安装包，很多桌面项目直接用它做开发完全没问题。但我在实际工作中遇到过几种情况，逼着我去看源码编译这条路的可行性。

第一种是调试需求。预编译包通常只带 release 版库，虽然也能编出 debug 程序，但调试时进不了 Qt 源码内部，堆栈信息残缺，追踪信号槽连接问题非常痛苦。自己编一个 debug-and-release 双配置的版本，调试体验会好很多。

第二种是模块裁剪。某跨平台系统项目交付时要求安装包控制在 100MB 以内，官方编译包把所有模块都塞进去，光 Qt 库就占了 300 多 MB。通过 configure 时用 -skip 参数裁掉不需要的模块，体积能减少一半以上。

第三种是用例比较特殊——需要修改 Qt 源码内部的某个行为，或者给某个模块打补丁。这时候你手里必须有一份能完整编译的源码树，而不是一个不可变的二进制包。说句实话，对大多数页面上能跑起来的项目，预编译包够用，但你一旦踩到上面三种场景之一，源码编译就成了唯一靠谱的选择。

2.2 VS2019 的 MSVC 工具链：环境准备的第一道门槛

Qt 5.15.16 在 Windows 下编译依赖 MSVC 工具链，也就是 VS2019 自带的 cl.exe、link.exe 和标准库头文件。之所以强调这一层，是因为很多人直接打开普通 CMD 窗口跑 configure 脚本，然后报一堆找不到编译器的错误——这不是 Qt 的问题，而是你的环境里根本没有 MSVC 的环境变量。

VS2019 装好后，开始菜单里有一个独立的命令行入口，叫"x64 Native Tools Command Prompt for VS 2019"。这个名字里的 x64 很关键，因为 Qt 5.15.16 的 64 位版本必须用 64 位编译器才能编。打开这个窗口后，cl.exe、nmake.exe 都会被自动加进 PATH，lib 和 include 环境变量也会自动指到 MSVC 的对应目录。

如果你习惯用普通 CMD 或 PowerShell，也可以手动调用 vcvars64.bat 来加载环境变量。这个脚本在 VS2019 安装目录下的 VC\Auxiliary\Build 子目录里，具体路径因安装方式而异，常见做法是用 VsDevCmd.bat，它位于 Common7\Tools 目录下，功能类似。我一般会直接用开始菜单里的快捷方式，省得记路径。

2.3 Perl、Python 和 jom：被很多人忽略的三个配角

Qt 5.15 的源码构建过程中，有几个工具是硬依赖，缺一个都会在 configure 阶段直接报错。Perl 用于处理部分代码生成脚本，Python 用于构建系统辅助工具，jom 则是 nmake 的并行替代品，用来加速编译。

先说 Perl。Qt 官方推荐 ActivePerl 或 Strawberry Perl，我用 Strawberry Perl 比较多，主要是它自带完整的移植环境，安装简单，而且默认就能被 configure 脚本识别。装完以后要把 perl.exe 所在目录加进 PATH，并在 CMD 里输入 perl -v 确认版本输出了再往下走。

Python 在 5.15 里主要用于某些工具链的辅助脚本，比如处理头文件扫描。要求是 Python 2.7 或 3.x，我直接上的 Python 3。同样需要加进 PATH，并输入 python --version 验证。

jom 是 Qt 自家出的并行 make 工具，在 Qt 安装目录的 Tools\QtCreator\bin 里能找到，也可以单独下载。它的作用后面编译章节再细说，现在先把它放到 PATH 里，和 nmake 一样能被命令行直接调用。注意 jom 只负责编译加速，不是 configure 的前置条件，所以顺序无所谓。

3. 源码包下载与 configure 参数选择：5.15.16 怎么配才不翻车

3.1 下载源码包和解压：目录结构决定后续省不省心

Qt 5.15.16 的源码发布形式是一个名为 qt-everywhere-opensource-src-5.15.16.zip 的压缩包，包含了 Qt Base、Qt Declarative、Qt Tools 等几乎所有模块的统一源码树。下载时建议从官方下载站的 archive 目录拿，能保证文件完整性和版本精确匹配。

解压时要特别注意一件事——整个源码树的路径不能包含中文、空格和特殊符号。我见过有人把源码解压到 "D:\我的代码\Qt 5.15.16" 这种路径下，configure 阶段各种怪异报错，最后把所有输出目录删掉换到纯英文路径才顺过来。这不是玄学，Qt 的构建系统在路径拼接时对空格的处理有缺陷，即便现代版本改了部分逻辑，我们也没必要去赌这个概率。

我一般会规划两个目录：源码目录 D:\Qt\src\5.15.16，构建输出目录 D:\Qt\build\5.15.16-msvc2019_64，安装目录 D:\Qt\5.15.16\msvc2019_64。源码和构建输出分开的好处是，如果 configure 参数觉得不合适，可以直接删掉构建目录重新配置，不用动源码树，成本极低。

3.2 configure 命令模板：一套能用的参数组合

进入构建目录，调用源码目录下的 configure.bat 脚本，然后传入各种开关参数。以下是我在 Win10 + VS2019 上验证过的参数组合，直接抄作业即可。

cd /d D:\Qt\build\5.15.16-msvc2019_64 D:\Qt\src\5.15.16\configure.bat ^ -prefix D:\Qt\5.15.16\msvc2019_64 ^ -opensource -confirm-license ^ -debug-and-release ^ -nomake examples -nomake tests ^ -skip qtwebengine ^ -skip qt3d ^ -skip qtcanvas3d ^ -skip qtpurchasing ^ -skip qtvirtualkeyboard ^ -skip qtdocgallery

这段命令值得逐项解释。第一行 cd 进构建目录，这是必须的一步，configure 默认要把构建产物写在当前目录。第二行调用源码树里的 configure.bat，用 ^ 做行连接符，实际在 CMD 里敲时可以写在一行。

-prefix 指定编译完成后安装位置，后续生成的 Qt 库、头文件、工具都会放在这个目录。这个路径我只推荐纯英文，理由同上。然后是 -opensource -confirm-license 两个参数，一个声明用开源协议，一个自动确认许可证——不加 confirm-license 的话 configure 会停下来等你敲 y，批处理脚本里没法交互，容易卡住。

-debug-and-release 是这次编译的核心诉求，告诉构建系统同时生成 debug 版和 release 版的 Qt 库，后缀分别带 d 和不带 d，调试时链接带 d 的库，发布时链接不带 d 的。代价是编译时间翻倍，但换来的是双配置可用，值。

-nomake examples -nomake tests 跳过例子和测试模块的构建，能省不少时间。我最初几次编译没有加这两项，结果多等了一个多小时去编我用不上的示例程序，后来果断加上了。

3.3 -skip 参数：裁剪模块的正确姿势

-skip 参数用来排除你不需要的模块，属于可选但强烈推荐。Qt 整个源码树包含几十个模块，全部编译完耗时太长，而且有些模块在 Windows 上编译极容易出问题。最关键的是 qtwebengine——这个模块就是 Chromium 内核，编译它需要额外下载大量依赖，耗时往往超过 Qt 其他模块之和，而且内存占用极高，8GB 内存的机器编译过程中随时可能崩。很多开发者反馈这个模块翻车率最高，所以除非你的产品真的需要内嵌浏览器，否则直接 skip 掉。

qt3d、qtcanvas3d、qtpurchasing、qtvirtualkeyboard、qtdocgallery 这些模块对于普通桌面应用也用不到，skip 掉可以缩短总编译时长。实际裁剪时你用不到哪个就 skip 哪个，我的建议是宁多勿少——真需要某个模块，后面回源码树里单独编译它也行。

configure 跑完会输出一份配置摘要，里面列出了每个模块是否启用、qmake 源码路径、构建类型等关键信息。花三十秒扫一眼这段输出，确认你自己的目标模块都出现在"Enabled"列表里，再继续编译，能省掉后面返工的麻烦。

3.4 依赖缺失时怎么处理：ICU 和 OpenSSL 的取舍

configure 过程如果检测到某些依赖缺失，会在摘要里用提示方式告诉你哪些模块因为缺少依赖被降级或禁用。最常见的是 ICU 和 OpenSSL。

ICU 提供国际化支持，缺失时 Qt 的 QTextCodec、QCollator 等类会退回使用系统编码，处理非拉丁字符的能力受限。如果项目面向中文用户，基本不需要 ICU；如果要做国际化多语言排序，建议先编译一份 ICU 库，再回来 configure。我这边项目用不到，直接忽略。

OpenSSL 缺失时 QtNetwork 模块的 TLS 支持不可用，也就是 HTTPS 请求会失败。注意这不是编译失败，只是功能受限，configure 会继续跑完。有上线部署需求的话，建议先编译好 OpenSSL 的 Windows 版本，再在 configure 时通过 -openssl-linked 连接进去。

这两个依赖的核心原则是：先明确需求再决定配不配，不要盲目追求全部启用。缺依赖时的默认行为是 Qt 把对应模块降级处理，编译照样能完成，所以看到警告不用慌，确认自己用不到对应功能就能继续。

4. 编译阶段详解：从 nmake 到 jom 的并行加速方案

4.1 为什么不用 nmake 单线程硬跑

configure 成功之后，构建目录下会生成 Makefile 文件和一系列构建脚本。Windows 上 Qt 默认的 make 工具是 nmake，它是微软出的命令行构建工具，与 Makefile 格式完全兼容。

nmake 可以完成整个编译流程，但它有个致命弱点——默认单线程顺序执行。Qt 全量编译有接近一万个源文件，单线程 nmake 跑完需要数个小时，这期间 CPU 占用率不到 20%，大部分核心在闲着。我在某公司第一次用 nmake 编 Qt 时，从下午三点跑到晚上十点才结束，后面收到不少吐槽。

提速的第一选择是加多线程。nmake 提供了一个可选的并行开关，写作 /MP，可以指定同时编译的进程数，比如 nmake /MP 8。这个参数不是所有版本的 nmake 都支持，3.0 以上版本的 MSVC 自带的 nmake 才认识它。使用方法是：

nmake /MP 8

这里 /MP 后面跟的是并行编译的源文件数，8 表示同时编译 8 个源文件。从实际效果看，/MP 能显著缩短耗时，但和后面要说的 jom 相比仍有差距，原因是 nmake 的多线程只作用在单个目录的编译上，跨目录的依赖顺序和文件扫描仍是串行。

4.2 jom：真正的并行构建体验

jom 是 Qt 官方开发的 nmake 兼容替代品，解决了 nmake 并行度不足的问题。它读取同样的 Makefile，但能真正做到任务级的并行调度，多个子目录可以同时编译，CPU 核心利用率明显提高。

安装 jom 最简单的方式是把 jom.exe 放到 PATH 目录下。然后在构建目录里执行：

jom -j 8

-j 8 表示最多 8 个并行任务。这个数值怎么选，需要看你的 CPU 物理核心数和可用内存。每个编译任务大约占用 300 到 500MB 内存，8 并发大约需要 4GB 空闲内存，16 并发需要 8GB。我在这台机器上试过 -j 12，内存没问题但 CPU 温度偏高，最终稳定在 -j 8。

使用 jom 的另一个好处是错误信息格式和 nmake 兼容，Ctrl+C 中断后再次执行 jom，它能从断点处继续，不用整个重新编译。增量编译对反复改参数调试非常有帮助。

4.3 编译输出产物：怎么确认编出来的东西是完整的

编译完成后，构建目录下会生成大量中间文件，但真正的产物在 -prefix 指定的安装目录里。运行 jom install 或者直接执行 install 目标，把所有库、头文件、可执行文件复制到安装路径。

jom install

安装完成后，检查安装目录结构，正常情况下应存在 bin、lib、include、mkspecs 这几个子目录。bin 下有 qmake.exe、windeployqt.exe、moc.exe、uic.exe 等工具，lib 下有 Qt5Core.lib、Qt5Core.dll、Qt5Cored.lib 等链接库和动态库，include 下是按模块组织的头文件目录。

最关键的一个验证是看 lib 目录里是否同时存在 Qt5Cored.lib 和 Qt5Core.lib。前者是 debug 版库，后者是 release 版库，两个都存在说明 debug-and-release 配置生效了。如果只看到一个版本，说明 configure 阶段参数没传对，需要回到 configure 那一步重新检查。

另外，观察编译结束时的输出日志，正常结局是"Qt is now configured for building"信息之后的 make 阶段顺利跑完，没有出现 error C 开头的编译错误或者 link 开头的链接错误。凡是出现 error 关键字而中断的，从那条错误往上翻日志，通常能看到是哪个源文件、缺失什么头文件或链接库，信息量比想象的大。

5. 避坑清单：5 个 QT5.15.16 编译高频问题的排查记录

5.1 configure 报"Perl not found"，但明明装过 Perl

现象：运行 configure.bat 后不久，屏幕上直接报 "Perl not found" 然后退出，去 CMD 里输入 perl -v 又正常显示版本号。

原因：configure 脚本检测 Perl 时用的是相对路径查找方式，当前 CMD 窗口的 PATH 环境变量里没有包含 Perl 的安装目录，或者 Perl 版本太旧不满足要求。

解决：确认 Strawberry Perl 安装目录（默认 C:\Strawberry\perl\bin）已加进 PATH，并新开一个 CMD 窗口验证 perl -v。如果配置完 PATH 仍然报错，检查是否同时装了两个 Perl 版本，把 PATH 里的旧版本路径删掉。最后在构建目录里删掉 config.cache 文件再重新 configure，老缓存有时候会干扰检测。

5.2 编译中断，报"无法打开文件 Qt5Core.lib"

现象：jom 跑到一半，弹出一堆类似 "fatal error LNK1104: cannot open file 'Qt5Core.lib'" 的错误，整个构建停住。

原因：最常见的是杀毒软件把 Qt 生成的 .lib 文件当可疑文件锁住了，导致链接器无法读取；另一种可能是同时跑了两个 jom 进程，互相抢同一个 lib 文件。

解决：把整个 Qt 源码目录、构建目录和安装目录加入杀毒软件白名单，或者直接在设计编译期间暂时关掉实时防护。同时检查任务管理器里没有残留的 cl.exe 和 jom 进程，有的话结束掉再重新编译。我第一次遇到这个坑时折腾了半小时，最后发现是同步盘把 lib 文件同步到云端导致权限冲突，关掉同步就恢复了。

5.3 debug 和 release 库混用，程序链接报一堆未解析符号

现象：自己编的 Qt 装好之后，用 VS2019 创建一个简单 QWidget 程序，链接时出现几十个 unresolved external symbol 错误。

原因：构建时生成 debug 和 release 两套库，但 VS2019 的附加依赖库配置里只写了 release 版 Qt5Core.lib，而源文件编译用的是 debug 模式（/MDd 开关），运行时需要的是 Qt5Cored.lib，两套库 ABI 不一致导致链接失败。

解决：在 VS2019 的项目属性中，分别设置 Debug 配置和 Release 配置的附加依赖库。Debug 配置链接 Qt5Cored.lib、Qt5Widgetsd.lib 等带 d 后缀的库；Release 配置链接不带 d 的。这一步没有捷径，必须逐个配置。后面我会给出一个更省事的自动化方案。

5.4 编出来的程序双击没反应，进程闪退

现象：从 VS 里运行正常，但直接双击生成的 exe 文件，屏幕闪一下什么都没有，任务管理器里看不到进程。

原因：Qt 程序运行时依赖 bin 目录下的 Qt5Core.dll、Qt5Gui.dll 等多个动态库，exe 启动后找不到这些 DLL 就静默退出，而 VS 里运行正常是因为调试器帮它定位到了 Qt 安装目录。

解决：把 bin 目录加进系统 PATH，或者更规范的做法是用 Qt 自带的 windeployqt 工具把需要的 DLL 复制到 exe 所在目录。命令如下：

windeployqt C:\release\myapp.exe

windeployqt 会自动扫描 exe 的依赖，把 Qt5Core.dll、Qt5Gui.dll、platforms 插件等都拷贝到同一个目录。这种方式适合发布给没有开发环境的用户使用。

5.5 编译时间超出预期，经查是没启用并行

现象：jom -j 8 执行之后，CPU 占用率只有三成，进度数字滚动很慢，整个编译耗时五个小时，和 nmake 单线程差不多。

原因：大多数情况下是 Makefile 里某些模块内部的串行依赖限制了并行度，但也有可能是因为 PATH 里的 jom 版本太旧，对某些规则的处理退化成串行。另外，构建目录放在机械硬盘上时，磁盘 IO 会成为瓶颈，并行度再高也快不起来。

解决：确认 jom 是最新版本，同时把构建目录放到 SSD 上。还有一个小技巧：编译前先设置环境变量 CL 加上 /MP 参数，让单个源文件的编译也走多线程头文件扫描，整体能再快一点。

set CL=/MP

注意这个设置只对当前 CMD 窗口有效，重新打开窗口需要再设一次。这几步组合做下来，在我机器上从五小时降到两小时出头。

6. 部署验证与后续使用技巧：确认你编译出的 Qt 真的能用

编译安装完成只是第一步，真正要用它开发，还有几件事需要落实。首先验证工具链里的 qmake 是否指向你自己的安装目录。

qmake -v

输出应该显示 "Using Qt version 5.15.16 in D:\Qt\5.15.16\msvc2019_64" 这样的信息。如果指向了其他 Qt 版本，检查 PATH 环境变量里是否有老版本的 Qt bin 目录排在前面，把多余的路径移除即可。

接下来做一个最小项目验证整个链路是通的。项目文件 main.pro 内容如下：

QT += core widgets CONFIG += debug_and_release TARGET = smoke_test TEMPLATE = app SOURCES += main.cpp

对应的 main.cpp：

#include <QApplication> #include <QLabel> int main(int argc, char *argv[]) { QApplication app(argc, argv); QLabel label("Qt 5.15.16 built with VS2019"); label.resize(320, 120); label.show(); return app.exec(); }

然后在项目目录下执行：

qmake jom

如果编译没有报错，运行生成的 debug 目录下的 smoke_test.exe，能看到窗口出现，说明 Qt 核心功能正常。我这边的习惯是顺手编一个小工具来测试网络模块是否启用，因为 OpenSSL 缺失时 HTTP 请求会静默失败，编译层面看不出来。

验证通过之后，最后一步是为 VS2019 配置 Qt 插件环境，这样后续就不用每次手工调用 qmake 了。在 VS2019 的扩展菜单里安装 Qt Visual Studio Tools 扩展，然后在扩展选项中把 Qt 版本路径指到 D:\Qt\5.15.16\msvc2019_64。这里有个细节要注意：扩展需要读的是 qmake.exe 所在的 bin 目录，填错层级会导致扩展识别不到版本。

总结我这几轮折腾下来的经验：第一轮就老老实实把确认需要用的模块列好，该 skip 的 skip，该留的留；第二轮用上 jom 并配合 SSD 构建目录，把等待时间控制在可接受范围内；第三轮把 PATH 和 VS 附加依赖库一次性配好，后续建项目不再重复踩坑。至于 ICU 和 OpenSSL 这些可选项，项目没有明确需求就不配，等真遇到跨语言排序或 TLS 需求再回来补编，成本比想象的低。希望帮到你。

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