简介面向Windows平台Qt开发者的Qt 5.15.16编译成品库基于VS2019工具链构建可直接用于32位与64位桌面应用开发省去自行编译源码的时间成本。压缩包共约2000个文件以1548个C头文件为主体覆盖QtCore、QtGui、QtWidgets、QtTest、OpenGL及Vulkan等模块的类声明另含少量json、pri工程配置与模块依赖描述文件整体约753MBinclude、lib、plugins、bin四类目录分工明确便于按模块引用与部署。已有874人学习下载适合需要稳定Qt运行库、希望跳过漫长编译流程的中级开发者也便于对照头文件梳理模块依赖与插件机制快速集成到既有工程中。1. Qt 5.15.16 源码编译为什么在 Win10 VS2019 上自己编一遍更省心装完 Qt 官方在线安装器打开工程发现调试器版本对不上、某个模块缺库、想裁掉 WebEngine 又裁不掉——这类事在 Win10 上做桌面开发的人多少都碰过。Qt 5.15.16 是 5.15 LTS 分支的后期维护版本官方二进制包默认按特定 MSVC 工具链构建一旦你的 VS2019 环境、Windows SDK 版本或第三方库 ABI 有偏差链接期就会冒出一堆 unresolved external。自己从源码编一遍本质是把工具链、模块裁剪、调试符号三件事一次性对齐到自己的机器上代价是几十分钟到两小时的编译时间。这篇笔记面向需要在 Win10 VS2019 下稳定产出 Qt 库的从业者从环境准备、configure 参数、nmake 编译到踩坑排查按能照着复现的粒度写。2. 编译前的环境对齐VS2019、SDK 与源码目录怎么摆2.1 工具链版本组合与依赖清单Qt 5.15.16 的源码构建对 MSVC 版本有明确下限要求VS2019MSVC 19.2x是官方支持范围内的组合。真正容易翻车的不是 VS 本身而是 Windows SDK 版本和 Perl、Python 这两个构建期依赖。configure 脚本在 Windows 上需要 Perl 处理部分生成逻辑Python 用于部分模块的构建脚本两者都要在 PATH 里能被找到且不能是 Microsoft Store 版的别名 stub——Store 版 python.exe 在脚本调用时会弹应用商店直接让 configure 中断。我一般按下面这张表核对缺一项就先补别急着跑 configure组件建议版本/形态作用常见问题Visual Studio 201916.x含 C 桌面开发工作负载提供 cl.exe、link.exe、nmake只装了 Build Tools 但没装 Windows SDKWindows 10 SDK10.0.17763 及以上头文件与库多版本共存时 configure 选错Perl5.28 的独立发行版构建脚本依赖未加入 PATHPython3.7/3.8 独立安装部分模块脚本Store 别名 stub 干扰Qt 源码包qt-everywhere-src-5.15.16编译输入路径含空格或中文磁盘空间预留 30GB 以上源码 中间产物 安装目录中途空间不足导致链接失败源码目录和构建目录必须分开这是 Qt 官方推荐的 shadow build 方式。源码放D:\qt-src\qt-everywhere-src-5.15.16构建目录另建D:\qt-build\5.15.16-msvc2019安装目录再单独一个D:\Qt\5.15.16\msvc2019_64。三个目录都不要带空格和中文nmake 和部分生成脚本对路径里的空格处理并不可靠血泪经验是路径里出现一个空格后面可能要多花半小时定位。2.2 用 vcvarsall 固定编译环境不要从开始菜单随便开一个“x64 Native Tools 命令提示符”就干活那个环境的 SDK 版本取决于安装顺序。正确做法是显式调用 vcvarsall 并指定架构把环境变量钉死:: 以管理员身份打开 cmd进入 VS2019 安装目录下的 VC\Auxiliary\Build call C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat x64 -vcvars_ver14.29这段调用的含义x64指定目标架构为 64 位-vcvars_ver14.29把 MSVC 工具集锁定到 14.29 这一具体版本避免机器上装了多个 VS 版本时被切到别的工具集。执行完可以用cl和where nmake验证输出里应能看到 14.29 的版本号和 nmake 的绝对路径。如果cl提示找不到说明工作负载没装全回 VS Installer 补“使用 C 的桌面开发”。环境固定后再确认 Perl 和 Pythonperl -v python --version where perl where pythonwhere python如果第一条指向WindowsApps下的 stub说明 Store 别名在抢路去“应用执行别名”里把 python 和 python3 关掉或者把独立安装的 Python 目录提到 PATH 最前面。这一步不做configure 阶段会卡在一个看似无关的脚本报错上翻车概率很高。3. configure 参数怎么配模块裁剪与许可选项的取舍3.1 一份可直接抄的 configure 命令Qt 5.15 的 configure 在 Windows 上实际是调用configure.bat参数分几类安装前缀、许可、模块开关、特性开关、第三方库路径。下面这份是我在 64 位桌面项目里常用的组合裁掉了 WebEngine 和部分移动端模块保留 Widgets、Network、Sql、Multimedia 这些桌面常用件cd /d D:\qt-build\5.15.16-msvc2019 D:\qt-src\qt-everywhere-src-5.15.16\configure.bat ^ -prefix D:\Qt\5.15.16\msvc2019_64 ^ -opensource -confirm-license ^ -platform win32-msvc ^ -debug-and-release ^ -nomake examples -nomake tests ^ -skip qtwebengine -skip qtwebview ^ -skip qtquick3d -skip qtquickcontrols ^ -opengl desktop ^ -mp逐项说明-prefix是最终nmake install的落地目录装完这个目录就是可被 Qt Creator 或 qmake 引用的 Qt 根目录-opensource -confirm-license表示按开源许可构建并跳过交互确认商用闭源场景要换成对应许可参数这一点别抄错-platform win32-msvc是 Windows 下的 mkspec 名64 位也用它架构由 vcvarsall 决定-debug-and-release同时产出调试版和发布版库调试版对定位崩溃很有用代价是编译时间和磁盘翻倍-nomake examples -nomake tests跳过示例和测试能省下大量时间-skip按模块名整块跳过模块名要和源码顶层目录名一致写错不会报错只会静默不生效这是最容易踩的坑之一-opengl desktop用桌面 OpenGL 而非 ANGLE桌面项目一般这样选-mp开启多核编译。如果项目需要 WebEngine把-skip qtwebengine去掉但要额外准备 Python 和 Node 环境且编译时间会显著拉长建议单独一轮构建别和主库混在一起排错。3.2 参数生效的验证与常见误配configure 跑完会在构建目录生成config.summary这是判断参数是否真正生效的唯一可靠依据别只看屏幕滚动输出。重点核对三处Build type是否为 debug-and-release、Build options里 skip 的模块是否确实不在列表、Qt Sql下的驱动是否包含你需要的比如 SQLite 默认内置MySQL 需要额外指定。如果发现某个-skip没生效先检查模块名拼写再检查该模块是否被其他模块依赖而无法单独跳过。另一个高频误配是-prefix指向了已存在的 Qt 安装目录。nmake install 会往里覆盖文件如果那个目录是官方安装器装的 Qt混装后 qmake 的 mkspec 和库版本可能对不上出现“编译过了但运行崩”的玄学问题。我的习惯是 prefix 永远指向一个空目录或全新目录装完再在 Qt Creator 里手动添加这个 Kit不碰官方安装目录。提示configure 失败时不要急着重跑先看构建目录下的config.log里面记录了每个探测项的原始命令和返回码比屏幕输出详细得多。4. nmake 编译与安装从中间产物到可用 Kit4.1 分阶段编译与并行度控制configure 成功后在同一个 cmd 窗口环境变量还在里执行 nmake。Qt 的顶层 Makefile 支持分模块编译全量nmake会串起所有模块出问题时不好定位。我一般先编核心模块验证工具链再全量:: 先编 qtbase验证工具链和 configure 是否正确 cd /d D:\qt-build\5.15.16-msvc2019 nmake module-qtbase :: 核心通过后再全量编译 nmakemodule-qtbase是顶层 Makefile 提供的模块级目标只编 qtbase 这一块通常十几分钟能出结果是验证环境是否健康的低成本手段。全量nmake的并行度由-mp在 configure 阶段决定也可以在命令行用nmake /NOLOGO配合环境变量CL/MP调整但并行度过高在内存不足的机器上会触发链接器 OOM表现为fatal error C1060或链接进程被系统杀掉。16GB 内存的机器建议并行度控制在 8 以内32GB 以上可以放开。编译过程中如果某个模块报错nmake 默认会继续往下走最后汇总一堆失败。想快速定位第一个错误用nmake /K的反面——直接不加参数让它遇错即停或者把输出重定向到日志再搜errornmake build.log 21 findstr /i error build.log重定向的好处是编译几十分钟后还能回看屏幕缓冲区早就滚没了。日志里第一个error往往才是根因后面的多是连锁失败。4.2 安装与 Kit 注册全量编译通过后执行安装nmake install这一步把编译产物按 prefix 布局复制到D:\Qt\5.15.16\msvc2019_64包括 bin、lib、include、mkspecs、plugins。装完验证 qmakeD:\Qt\5.15.16\msvc2019_64\bin\qmake.exe -v输出应显示QMake version 3.1和Using Qt version 5.15.16。然后在 Qt Creator 里“工具 → 选项 → Kits → Qt Versions”添加这个 qmake 路径再新建一个 Kit编译器选 VS2019 的 cl.exe调试器选 cdb 或 VS 自带调试器。Kit 建好后用一个最小 Widgets 工程跑一遍 debug 构建能断点进 Qt 源码前提是编译时带了 debug 且保留了 pdb才算真正可用。注意debug 版库的 pdb 文件在 install 后位于 lib 目录如果后续要调试进 Qt 内部别在清理磁盘时把 pdb 删了删了就只能看汇编。5. 编译期避坑清单五条血泪记录5.1 现象configure 报 “Perl not found” 但明明装了原因通常是 Perl 装了但没进 PATH或者 PATH 里排在前面的某个目录有同名但不可执行的 perl。解决where perl确认实际解析到的路径把正确目录提到 PATH 最前重开 cmd 再试。别在当前窗口改 PATH 后直接重跑环境变量缓存可能没刷新。5.2 现象nmake 中途报 C1060 堆空间不足原因是并行编译的 cl.exe 进程太多内存被吃满。解决降低并行度或在 configure 时去掉-mp改用nmake /NOLOGO单线程慢编。也可以只编需要的模块用module-xxx目标逐个来避免一次性拉起全部。5.3 现象编译通过但运行时报 “找不到 Qt5Core.dll”原因是运行目录不在 PATH 里或 Kit 配置的 Qt 版本路径不对。解决开发期把D:\Qt\5.15.16\msvc2019_64\bin加进系统 PATH发布期用 windeployqt 收集依赖。别把 bin 目录直接拷到 exe 旁边当部署方案插件路径会乱。5.4 现象-skip qtwebengine写了但 WebEngine 还是被编了原因是模块名拼写和源码目录名不一致或者该模块被其他未跳过的模块依赖而被动拉起。解决对照源码顶层目录名核对拼写再看config.summary确认 skip 列表必要时把依赖它的模块一起 skip。5.5 现象install 后 qmake 能跑但 Creator 里新建工程链接失败原因是 Kit 里选的编译器架构和 Qt 库架构不一致比如 32 位 cl 配了 64 位库。解决Kit 的编译器必须和 vcvarsall 里指定的架构一致检查 cl 的dumpbin /headers输出确认目标机器类型再回 Creator 改 Kit。6. 增量重编与产物验证把一次编译变成可复用流程源码编译最烦的不是第一次而是改了 configure 参数或打了补丁之后的重编。Qt 的构建系统支持增量但前提是构建目录没被破坏。改 configure 参数的正确姿势是在构建目录里重新跑一次 configure它会复用已有中间产物然后nmake只有受影响的模块会重编。如果改了-prefixinstall 会往新目录复制旧目录残留需要手动清别指望它自动迁移。验证产物是否完整我习惯跑一个脚本化的冒烟测试而不是靠肉眼点 Creatorimport subprocess, os qmake rD:\Qt\5.15.16\msvc2019_64\bin\qmake.exe env os.environ.copy() env[PATH] rD:\Qt\5.15.16\msvc2019_64\bin; env[PATH] # 检查 qmake 版本与模块可用性 out subprocess.check_output([qmake, -query], envenv, textTrue) for key in (QT_VERSION, QT_INSTALL_PREFIX, QT_INSTALL_LIBS): line [l for l in out.splitlines() if l.startswith(key)] print(line[0] if line else f{key} MISSING) # 检查关键库文件是否存在 libs [Qt5Core, Qt5Gui, Qt5Widgets, Qt5Network, Qt5Sql] libdir rD:\Qt\5.15.16\msvc2019_64\lib for lib in libs: for suffix in (.lib, d.lib): p os.path.join(libdir, lib suffix) print((OK if os.path.exists(p) else MISS), p)这段脚本做两件事用qmake -query读出安装后的实际路径和版本确认 prefix 生效再逐个检查关键库的 release 和 debug 版本是否都在。d.lib后缀是 debug 版库的命名约定缺了说明-debug-and-release没真正生效。跑完这个脚本再进 Creator 建最小工程基本能排除“装是装了但不可用”的情况。从那以后我每次编 Qt 都强制走一遍“vcvarsall 固定环境 → configure 看 config.summary → 先 module-qtbase 再全量 → install 后跑冒烟脚本”这条链路中间任何一步跳过后面大概率要用更多时间还债。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/11/5 2:12:46 · 阅读 1.2k Qt 5.15.16 源码编译指南：Win10+VS2019 环境配置与避坑
简介面向Windows平台Qt开发者的Qt 5.15.16编译成品库基于VS2019工具链构建可直接用于32位与64位桌面应用开发省去自行编译源码的时间成本。压缩包共约2000个文件以1548个C头文件为主体覆盖QtCore、QtGui、QtWidgets、QtTest、OpenGL及Vulkan等模块的类声明另含少量json、pri工程配置与模块依赖描述文件整体约753MBinclude、lib、plugins、bin四类目录分工明确便于按模块引用与部署。已有874人学习下载适合需要稳定Qt运行库、希望跳过漫长编译流程的中级开发者也便于对照头文件梳理模块依赖与插件机制快速集成到既有工程中。1. Qt 5.15.16 源码编译为什么在 Win10 VS2019 上自己编一遍更省心装完 Qt 官方在线安装器打开工程发现调试器版本对不上、某个模块缺库、想裁掉 WebEngine 又裁不掉——这类事在 Win10 上做桌面开发的人多少都碰过。Qt 5.15.16 是 5.15 LTS 分支的后期维护版本官方二进制包默认按特定 MSVC 工具链构建一旦你的 VS2019 环境、Windows SDK 版本或第三方库 ABI 有偏差链接期就会冒出一堆 unresolved external。自己从源码编一遍本质是把工具链、模块裁剪、调试符号三件事一次性对齐到自己的机器上代价是几十分钟到两小时的编译时间。这篇笔记面向需要在 Win10 VS2019 下稳定产出 Qt 库的从业者从环境准备、configure 参数、nmake 编译到踩坑排查按能照着复现的粒度写。2. 编译前的环境对齐VS2019、SDK 与源码目录怎么摆2.1 工具链版本组合与依赖清单Qt 5.15.16 的源码构建对 MSVC 版本有明确下限要求VS2019MSVC 19.2x是官方支持范围内的组合。真正容易翻车的不是 VS 本身而是 Windows SDK 版本和 Perl、Python 这两个构建期依赖。configure 脚本在 Windows 上需要 Perl 处理部分生成逻辑Python 用于部分模块的构建脚本两者都要在 PATH 里能被找到且不能是 Microsoft Store 版的别名 stub——Store 版 python.exe 在脚本调用时会弹应用商店直接让 configure 中断。我一般按下面这张表核对缺一项就先补别急着跑 configure组件建议版本/形态作用常见问题Visual Studio 201916.x含 C 桌面开发工作负载提供 cl.exe、link.exe、nmake只装了 Build Tools 但没装 Windows SDKWindows 10 SDK10.0.17763 及以上头文件与库多版本共存时 configure 选错Perl5.28 的独立发行版构建脚本依赖未加入 PATHPython3.7/3.8 独立安装部分模块脚本Store 别名 stub 干扰Qt 源码包qt-everywhere-src-5.15.16编译输入路径含空格或中文磁盘空间预留 30GB 以上源码 中间产物 安装目录中途空间不足导致链接失败源码目录和构建目录必须分开这是 Qt 官方推荐的 shadow build 方式。源码放D:\qt-src\qt-everywhere-src-5.15.16构建目录另建D:\qt-build\5.15.16-msvc2019安装目录再单独一个D:\Qt\5.15.16\msvc2019_64。三个目录都不要带空格和中文nmake 和部分生成脚本对路径里的空格处理并不可靠血泪经验是路径里出现一个空格后面可能要多花半小时定位。2.2 用 vcvarsall 固定编译环境不要从开始菜单随便开一个“x64 Native Tools 命令提示符”就干活那个环境的 SDK 版本取决于安装顺序。正确做法是显式调用 vcvarsall 并指定架构把环境变量钉死:: 以管理员身份打开 cmd进入 VS2019 安装目录下的 VC\Auxiliary\Build call C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat x64 -vcvars_ver14.29这段调用的含义x64指定目标架构为 64 位-vcvars_ver14.29把 MSVC 工具集锁定到 14.29 这一具体版本避免机器上装了多个 VS 版本时被切到别的工具集。执行完可以用cl和where nmake验证输出里应能看到 14.29 的版本号和 nmake 的绝对路径。如果cl提示找不到说明工作负载没装全回 VS Installer 补“使用 C 的桌面开发”。环境固定后再确认 Perl 和 Pythonperl -v python --version where perl where pythonwhere python如果第一条指向WindowsApps下的 stub说明 Store 别名在抢路去“应用执行别名”里把 python 和 python3 关掉或者把独立安装的 Python 目录提到 PATH 最前面。这一步不做configure 阶段会卡在一个看似无关的脚本报错上翻车概率很高。3. configure 参数怎么配模块裁剪与许可选项的取舍3.1 一份可直接抄的 configure 命令Qt 5.15 的 configure 在 Windows 上实际是调用configure.bat参数分几类安装前缀、许可、模块开关、特性开关、第三方库路径。下面这份是我在 64 位桌面项目里常用的组合裁掉了 WebEngine 和部分移动端模块保留 Widgets、Network、Sql、Multimedia 这些桌面常用件cd /d D:\qt-build\5.15.16-msvc2019 D:\qt-src\qt-everywhere-src-5.15.16\configure.bat ^ -prefix D:\Qt\5.15.16\msvc2019_64 ^ -opensource -confirm-license ^ -platform win32-msvc ^ -debug-and-release ^ -nomake examples -nomake tests ^ -skip qtwebengine -skip qtwebview ^ -skip qtquick3d -skip qtquickcontrols ^ -opengl desktop ^ -mp逐项说明-prefix是最终nmake install的落地目录装完这个目录就是可被 Qt Creator 或 qmake 引用的 Qt 根目录-opensource -confirm-license表示按开源许可构建并跳过交互确认商用闭源场景要换成对应许可参数这一点别抄错-platform win32-msvc是 Windows 下的 mkspec 名64 位也用它架构由 vcvarsall 决定-debug-and-release同时产出调试版和发布版库调试版对定位崩溃很有用代价是编译时间和磁盘翻倍-nomake examples -nomake tests跳过示例和测试能省下大量时间-skip按模块名整块跳过模块名要和源码顶层目录名一致写错不会报错只会静默不生效这是最容易踩的坑之一-opengl desktop用桌面 OpenGL 而非 ANGLE桌面项目一般这样选-mp开启多核编译。如果项目需要 WebEngine把-skip qtwebengine去掉但要额外准备 Python 和 Node 环境且编译时间会显著拉长建议单独一轮构建别和主库混在一起排错。3.2 参数生效的验证与常见误配configure 跑完会在构建目录生成config.summary这是判断参数是否真正生效的唯一可靠依据别只看屏幕滚动输出。重点核对三处Build type是否为 debug-and-release、Build options里 skip 的模块是否确实不在列表、Qt Sql下的驱动是否包含你需要的比如 SQLite 默认内置MySQL 需要额外指定。如果发现某个-skip没生效先检查模块名拼写再检查该模块是否被其他模块依赖而无法单独跳过。另一个高频误配是-prefix指向了已存在的 Qt 安装目录。nmake install 会往里覆盖文件如果那个目录是官方安装器装的 Qt混装后 qmake 的 mkspec 和库版本可能对不上出现“编译过了但运行崩”的玄学问题。我的习惯是 prefix 永远指向一个空目录或全新目录装完再在 Qt Creator 里手动添加这个 Kit不碰官方安装目录。提示configure 失败时不要急着重跑先看构建目录下的config.log里面记录了每个探测项的原始命令和返回码比屏幕输出详细得多。4. nmake 编译与安装从中间产物到可用 Kit4.1 分阶段编译与并行度控制configure 成功后在同一个 cmd 窗口环境变量还在里执行 nmake。Qt 的顶层 Makefile 支持分模块编译全量nmake会串起所有模块出问题时不好定位。我一般先编核心模块验证工具链再全量:: 先编 qtbase验证工具链和 configure 是否正确 cd /d D:\qt-build\5.15.16-msvc2019 nmake module-qtbase :: 核心通过后再全量编译 nmakemodule-qtbase是顶层 Makefile 提供的模块级目标只编 qtbase 这一块通常十几分钟能出结果是验证环境是否健康的低成本手段。全量nmake的并行度由-mp在 configure 阶段决定也可以在命令行用nmake /NOLOGO配合环境变量CL/MP调整但并行度过高在内存不足的机器上会触发链接器 OOM表现为fatal error C1060或链接进程被系统杀掉。16GB 内存的机器建议并行度控制在 8 以内32GB 以上可以放开。编译过程中如果某个模块报错nmake 默认会继续往下走最后汇总一堆失败。想快速定位第一个错误用nmake /K的反面——直接不加参数让它遇错即停或者把输出重定向到日志再搜errornmake build.log 21 findstr /i error build.log重定向的好处是编译几十分钟后还能回看屏幕缓冲区早就滚没了。日志里第一个error往往才是根因后面的多是连锁失败。4.2 安装与 Kit 注册全量编译通过后执行安装nmake install这一步把编译产物按 prefix 布局复制到D:\Qt\5.15.16\msvc2019_64包括 bin、lib、include、mkspecs、plugins。装完验证 qmakeD:\Qt\5.15.16\msvc2019_64\bin\qmake.exe -v输出应显示QMake version 3.1和Using Qt version 5.15.16。然后在 Qt Creator 里“工具 → 选项 → Kits → Qt Versions”添加这个 qmake 路径再新建一个 Kit编译器选 VS2019 的 cl.exe调试器选 cdb 或 VS 自带调试器。Kit 建好后用一个最小 Widgets 工程跑一遍 debug 构建能断点进 Qt 源码前提是编译时带了 debug 且保留了 pdb才算真正可用。注意debug 版库的 pdb 文件在 install 后位于 lib 目录如果后续要调试进 Qt 内部别在清理磁盘时把 pdb 删了删了就只能看汇编。5. 编译期避坑清单五条血泪记录5.1 现象configure 报 “Perl not found” 但明明装了原因通常是 Perl 装了但没进 PATH或者 PATH 里排在前面的某个目录有同名但不可执行的 perl。解决where perl确认实际解析到的路径把正确目录提到 PATH 最前重开 cmd 再试。别在当前窗口改 PATH 后直接重跑环境变量缓存可能没刷新。5.2 现象nmake 中途报 C1060 堆空间不足原因是并行编译的 cl.exe 进程太多内存被吃满。解决降低并行度或在 configure 时去掉-mp改用nmake /NOLOGO单线程慢编。也可以只编需要的模块用module-xxx目标逐个来避免一次性拉起全部。5.3 现象编译通过但运行时报 “找不到 Qt5Core.dll”原因是运行目录不在 PATH 里或 Kit 配置的 Qt 版本路径不对。解决开发期把D:\Qt\5.15.16\msvc2019_64\bin加进系统 PATH发布期用 windeployqt 收集依赖。别把 bin 目录直接拷到 exe 旁边当部署方案插件路径会乱。5.4 现象-skip qtwebengine写了但 WebEngine 还是被编了原因是模块名拼写和源码目录名不一致或者该模块被其他未跳过的模块依赖而被动拉起。解决对照源码顶层目录名核对拼写再看config.summary确认 skip 列表必要时把依赖它的模块一起 skip。5.5 现象install 后 qmake 能跑但 Creator 里新建工程链接失败原因是 Kit 里选的编译器架构和 Qt 库架构不一致比如 32 位 cl 配了 64 位库。解决Kit 的编译器必须和 vcvarsall 里指定的架构一致检查 cl 的dumpbin /headers输出确认目标机器类型再回 Creator 改 Kit。6. 增量重编与产物验证把一次编译变成可复用流程源码编译最烦的不是第一次而是改了 configure 参数或打了补丁之后的重编。Qt 的构建系统支持增量但前提是构建目录没被破坏。改 configure 参数的正确姿势是在构建目录里重新跑一次 configure它会复用已有中间产物然后nmake只有受影响的模块会重编。如果改了-prefixinstall 会往新目录复制旧目录残留需要手动清别指望它自动迁移。验证产物是否完整我习惯跑一个脚本化的冒烟测试而不是靠肉眼点 Creatorimport subprocess, os qmake rD:\Qt\5.15.16\msvc2019_64\bin\qmake.exe env os.environ.copy() env[PATH] rD:\Qt\5.15.16\msvc2019_64\bin; env[PATH] # 检查 qmake 版本与模块可用性 out subprocess.check_output([qmake, -query], envenv, textTrue) for key in (QT_VERSION, QT_INSTALL_PREFIX, QT_INSTALL_LIBS): line [l for l in out.splitlines() if l.startswith(key)] print(line[0] if line else f{key} MISSING) # 检查关键库文件是否存在 libs [Qt5Core, Qt5Gui, Qt5Widgets, Qt5Network, Qt5Sql] libdir rD:\Qt\5.15.16\msvc2019_64\lib for lib in libs: for suffix in (.lib, d.lib): p os.path.join(libdir, lib suffix) print((OK if os.path.exists(p) else MISS), p)这段脚本做两件事用qmake -query读出安装后的实际路径和版本确认 prefix 生效再逐个检查关键库的 release 和 debug 版本是否都在。d.lib后缀是 debug 版库的命名约定缺了说明-debug-and-release没真正生效。跑完这个脚本再进 Creator 建最小工程基本能排除“装是装了但不可用”的情况。从那以后我每次编 Qt 都强制走一遍“vcvarsall 固定环境 → configure 看 config.summary → 先 module-qtbase 再全量 → install 后跑冒烟脚本”这条链路中间任何一步跳过后面大概率要用更多时间还债。希望帮到你。本文还有配套的精品资源点击获取