很多人在网上搜“Qt 编译及安装”，其实是想离线装一套定制版 Qt，或者要交叉编译，又或者只是被官方安装器卡到崩溃。我前前后后自己编译过不少次 Qt，从懵懂时期照着抄参数疯狂踩坑，到后来能给团队搭出一套自动化构建环境，中间积累了不少经验。这篇文章就围绕 Qt 编译及安装这件事，把从需求判断、环境准备、configure 参数选择，到真实编译流程和常见报错的完整链路讲清楚。适用人群比较广：被“必须从源码构建 Qt”逼上梁山的应用开发者、想裁剪模块减少包体积的嵌入式工程师、以及要在自定义环境下搭建 Qt 工具链的构建管理员，都能从这里找到直接能用的方案。
1. 别急着装：先搞清楚什么情况下必须源码编译 Qt
1.1 官方安装器和包管理器其实能覆盖 80% 的场景
大多数人日常写 Qt 程序，官方在线安装器或者系统包管理器已经完全够用。Windows 上用官方在线安装器勾选需要的组件，Linux 上用 apt、yum 或者 dnf 装 qt6-base-dev，macOS 用 Homebrew 装 qt，这些方式得到的 Qt 都是官方已经编译好的二进制发行版，开箱即用。
真正需要自己源码编译的场景，我在实际项目里遇到过几类。一是产品需要严格裁剪，比如嵌入式设备上跑 Qt Quick 应用，屏幕 800x480，内存 512MB，官方完整版带一堆你用不到的模块，光安装目录就好几个 GB，这种时候按需裁剪模块编译就是刚需。二是你手上有定制补丁，公司内部对某个 Qt 模块做过二次开发和优化，这种情况下不可能用官方二进制，必须带着补丁从源码走一遍。三是交叉编译场景，要给 ARM 开发板、Android 或 iOS 编译对应的 Qt 库，官方安装器不一定提供你需要的 target 平台工具链，源码编译几乎是唯一出路。还有一种被很多人忽视的需求：你要调试 Qt 框架自身。如果程序崩溃时想看栈帧里 libQt6Widgets.so 的内部状态，预编译版通常只有 release 符号，调试起来极其痛苦，编译一个 debug 版才能看清底层逻辑。
如果你只是写 QWidget 程序，用的是 Windows 桌面加 MSVC 工具链，那源码编译大概率是自我折腾，时间和风险都不划算。先确认需求再动手，比什么都重要。
1.2 源码编译不是免费午餐：先看一下成本账
很多人第一次编译 Qt 时对代价完全没概念，我这里直接把实际消耗摆出来。以一台 8 核 16GB 内存的机器为例，从 Qt 6.5.x LTS 源码编译全套核心模块加常用模块，release 配置，用 Ninja 并行编译，大概需要 40 分钟到 1 个多小时。如果带着 qtwebengine 模块一起编译，时间会直接爆炸，按编译单元数量估算，5 到 8 个小时都有可能，而且内存占用很容易突破 8GB，链接阶段经常把机器卡到无响应。
磁盘占用也是一笔大账。Qt 源码仓库完整克隆下来约 2GB 到 4GB，构建目录中途会膨胀到 10GB 到 30GB（取决于模块数量），安装目录按模块裁剪情况大约 2GB 到 5GB。想源码编译 Qt，“预留 30GB 可用磁盘 + 16GB 内存”是比较舒服的起步条件。如果机器配置太寒酸，且没有云编译环境，我的建议是优先把不必要的模块全部跳过，并用小幅并行编译参数稳住构建过程。
1.3 判断你真正需要的是哪一层
还有一个很容易被忽略的分层问题：你需要的到底是“完整 Qt 库”还是“某个独立模块”。Qt 的仓库是一个 supermodule，里面包含了 qtbase、qtdeclarative、qtmultimedia、qttools 等十几个子仓库。如果只是想让一个特定的模块修个 bug，可以只克隆单模块进行构建和测试，不一定非要编译整个 Qt。官方提供了一个init-repository脚本，允许用--module-subset参数只拉取你关心的子模块组合，这个待会在环境准备一节详细说。
2. 源码编译前的环境清单：工具链和构建系统决定成败
2.1 Qt 5 和 Qt 6 的构建体系差异巨大
先把这个坑摆出来，很多人照着老教程操作 Qt 6 时懵了半天，原因就是构建体系从 Qt 5 到 Qt 6 发生了根本性变化。
Qt 5 时代，构建流程是./configure生成 Makefile，然后make && make install。虽然也支持 CMake，但官方主推的是 qmake 那一套。到了 Qt 6，官方把构建系统彻底切换到了 CMake 加 Ninja：configure 脚本本质上变成了 CMake 的前置封装，configure 之后不再直接生成 Makefile，而是生成一套 CMake 工程，你需要用cmake --build . --parallel <N>来编译，再用cmake --install .执行安装。
这个变化对用户的直接影响有三个。第一，先决条件里多了 CMake 和 Ninja 两个工具，版本还不能太低；第二，编译命令变了，不能用旧的 make 全流程思维；第三，configure 参数虽然大量兼容，但细节选项越来越多，有些旧参数已经移除或改名。我建议所有做 Qt 6 源码编译的人，先把官网的 “Qt on Linux / Windows / macOS” 构建文档通读一遍再动手，别拿两三年前的博客硬套。
2.2 Windows 平台：MSVC 优先，MinGW 只能作为备选
Windows 上编译 Qt 的第一步是选工具链。这里我强烈建议优先选 MSVC，也就是 Visual Studio 2019 或 2022（或者单独安装 Build Tools）。原因很实际：Qt 官方在 Windows 上对 MSVC 的支持最成熟，后续你装各类第三方库时，预编译库绝大多数都是 MSVC ABI，用 MinGW 会遇到链接器不兼容的麻烦。
工具链安装好后，并不是直接在普通 cmd 里敲命令，而是要打开“x64 Native Tools Command Prompt for VS 2022”这类专用命令行环境。它会自动把 cl.exe、nmake、环境变量都配好，你手动处理容易漏掉路径配置，导致 configure 阶段死活检测不到编译器。如果是 MSVC 2019，对应的是 VS 2019 的命令行入口；如果是 Build Tools 版本，入口名字略有差异，本质一致。
MinGW 在 Qt 6 时代属于“能跑但不是官方最优路径”。官方对每个 Qt 版本都有对应的受支持 MinGW 版本，比如 Qt 6.5 对应 MinGW 11.2 左右。如果你执意用 MinGW，务必将 MinGW 的 bin 目录加入 PATH，并用 mingw32-make 而不是 make。但我个人不推荐在 Windows 上靠 MinGW 编译新版本 Qt，调试配第三方库时太痛苦了。
2.3 Linux 平台：先把依赖装齐再动手
Linux 上源码编译 Qt 最容易卡在 configure 阶段的依赖检查。以 Ubuntu/Debian 系为例，除了编译器 g++ 之外，常规需要的开发包包括：build-essential、cmake、ninja-build、libgl1-mesa-dev、libfontconfig1-dev、libxkbcommon-dev、libx11-xcb-dev、libwayland-dev、libxcb-*相关开发包，以及libssl-dev。
我在干净容器里编译 Qt 时，最典型的问题是报Basic XLib functionality test failed。这个报错表面上是 xlib 相关检测失败，实际上绝大多数情况下是系统缺少 xcb 和 OpenGL 相关开发库。建议在 configure 之前就把这些包全部装上，不要心存侥幸。如果做的是无界面嵌入式或服务器端程序，可以用-no-opengl -no-xcb这类选项关闭相关特性，减少依赖面。
2.4 获取源码：supermodule 和单模块怎么选
获取 Qt 源码有两种典型姿势。第一种是克隆官方 supermodule 仓库，然后切换到目标分支，再用init-repository拉取所有子模块：
git clone https://code.qt.io/qt/qt5.git -b 6.5 # 以 6.5 分支为例 cd qt5 perl init-repository --module-subset=qtbase,qtdeclarative,qttools,qttranslations,qtmultimedia--module-subset可以只初始化项目真正需要的子模块，能大幅减少克隆时间和磁盘占用。注意init-repository是 Perl 脚本，所以系统里需要安装 Perl，Windows 上官方也要求装一个 Perl 环境，比如 Strawberry Perl 或 ActivePerl。
第二种是只克隆单个子仓库，比如只编译 qtbase：
git clone --single-branch --depth 1 https://code.qt.io/qt/qtbase.git -b 6.5这种方式能快速拿到 qtbase 源码，但你要注意，单独构建 qtbase 时，很多 configure 逻辑是以整个 Qt 仓库结构为前提的，部分模块查找可能会出问题，实际操作中我更推荐 supermodule + 模块子集方案，构建时路径清晰，后面补模块也方便。
3. configure 参数怎么定：从省事到省命的几组关键选项
3.1 必定要理的三个基础参数：prefix、opensource、release
configure 这一步是 “Qt 编译及安装” 全流程里最需要动脑子的环节。参数没选对，后面编译几个小时甚至全部推倒重来都很正常。我最先讲三个最基础的参数：
-prefix /opt/Qt/6.5.3 # 指定安装路径 -opensource # 选择开源版 -confirm-license # 预先确认许可证，避免交互式卡住-prefix指定了最终cmake --install的安装目录。这里有个讲究：我建议编译前就把 prefix 想好，不要装完再移动。Qt 的安装目录里很多路径会被写入各类配置文件和 CMake 包元数据中，移动目录后可能导致find_package(Qt6)失效。宁可一开始就决定好安装在/opt/Qt还是/home/you/Qt，也别等编译完再做搬迁。
编译配置上，Qt 同时支持-release、-debug和-debug-and-release。应用开发者如果只是发布产品，直接用-release最省时间省空间；如果还要调试 Qt 内部，务必在 configure 阶段选择-debug-and-release，否则后补很麻烦。个人体会是，新手不要碰-static，静态编译 Qt 要处理插件静态链接、第三方依赖静态化等一系列问题，配置复杂度远高于动态版，第一次源码编译就挑战全静态版，几乎注定踩坑。
3.2 模块裁剪是省时间省磁盘的头号武器
模块裁剪用-skip <module>参数。我特别建议避开qtwebengine，这个模块基于 Chromium 内核，代码量巨大、编译时间和内存消耗在所有模块里一骑绝尘，绝大多数桌面应用用不到它。
下面是我常用的一个裁剪组合：
-skip qtwebengine -skip qtwebview -nomake examples -nomake tests-skip控制的是编译哪些模块，-nomake控制的是是否生成 examples 和 tests 的构建目标。example 和 test 代码不仅编译时间长，还会增大安装目录和构建目录的体积。在做应用交付或嵌入式裁剪时，这两项完全可以不要。不过我要提醒一句：如果你后续要用 Qt 自带的 demo 验证某些功能是否正常，那examples可以留着，代价是得多等一段时间。
3.3 外部依赖的处理：OpenSSL 和系统库
很多人在 Qt 程序里遇到 HTTPS 请求失败才发现问题，根源就是 Qt 的网络模块没有开启 TLS 支持。源码编译时，如果 configure 阶段没有正确配置 OpenSSL，编译出来的 Qt 在调用QNetworkAccessManager访问 HTTPS 时会直接失败。
Qt 6 在 Windows 上建议用-openssl-runtime，这种方式允许 Qt 在运行时动态加载系统里的 OpenSSL DLL；如果希望链接静态库，可以用-openssl-linked。Linux 上更常见的是-system-openssl，直接使用系统 OpenSSL 开发包，前提是libssl-dev已安装。
此外还有 ICU 库。如果你不编译 qtwebengine 或不做复杂的文本断字、多语言排序功能，缺 ICU 一般也能跑。部分 Qt 模块对 ICU 有硬性要求，configure 失败时会明确提示，到时按提示补包或加-no-icu再做权衡即可。
3.4 一套完整参考配置
综合以上分析，我在 Linux 上给 Qt 6.5 常用配置大概长这样：
./configure -prefix /opt/Qt/6.5.3 \ -release -opensource -confirm-license \ -skip qtwebengine -skip qtwebview \ -nomake examples -nomake tests \ -system-openssl -qt-libpng -qt-libjpeg-qt-libpng和-qt-libjpeg表示让 Qt 使用自带的图像格式库，避免外部依赖版本不一致的麻烦。在 Windows MSVC 环境下把./configure换成configure.bat，其他参数类似。注意如果安装路径的目录权限受限，要用管理员权限运行命令行或提前创建好目录。
4. Linux / Windows 双平台完整编译实操流程
4.1 Linux 上从 configure 到 cmake --install 的完整链路
Linux 的完整流程分四步，但有几个细节值得单独说。
第一步，进入源码根目录，检查工具链：
gcc --version cmake --version ninja --version版本检查不只是走个形式：如果 GCC 版本太老，Qt 6 的部分新特性在编译期就会报不支持的错误；CMake 版本最好不低于 3.20（具体以官方要求为准），Ninja 建议 1.10 以上。
第二步，执行 configure。这里我推荐源码外构建的 Out-of-source 方式，也就是建一个独立的 build 目录，在 build 目录里调用源码目录下的 configure 脚本：
mkdir build cd build ../configure -prefix /opt/Qt/6.5.3 \ -release -opensource -confirm-license \ -skip qtwebengine -skip qtwebview \ -nomake examples -nomake tests \ -system-openssl这种方式的优势非常明显：如果某次编译中途出事，或者你想换一组 configure 参数重新构建，直接把 build 目录删掉即可，源码目录保持干净。在 Qt 5 时代源码内构建是常见姿势，但 Qt 6 下构建目录分离已经是很成熟的实践，值得沿用。
第三步，正式编译：
cmake --build . --parallel 8--parallel 8对应 8 个并行任务。这个参数我劝大家量力而行，并不是越大越好。我有一台 16 核 32GB 内存的机器，曾经为了快用--parallel 16，结果链接阶段多个大模块同时进入 ld，内存直接飙到 25GB 以上，整个系统卡到鼠标都不动。如果你内存只有 16GB，用 4 到 6 更稳。编译过程中如果看到某个文件长时间卡住不推进，通常是系统在做大型链接或代码生成，耐心等，不要盲目 Ctrl+C。
第四步，安装：
cmake --install .安装阶段通常比较快，主要工作是复制构建产物到 prefix 目录。如果 prefix 在系统目录且当前用户没有写权限，需要sudo cmake --install .，或者一开始就把 prefix 指到用户可写的目录，比如/home/you/Qt/6.5.3。
4.2 Windows MSVC 环境下的完整流程
Windows 上的操作逻辑和 Linux 一致，但环境入口必须正确。打开 “x64 Native Tools Command Prompt for VS 2022”，依次执行：
git clone https://code.qt.io/qt/qt5.git -b 6.5 cd qt5 perl init-repository --module-subset=qtbase,qtdeclarative,qttools,qttranslations,qtmultimedia mkdir build cd build ..\configure.bat -prefix D:\Qt\6.5.3-msvc -release -opensource -confirm-license -skip qtwebengine -skip qtwebview -nomake examples -nomake tests -openssl-runtime cmake --build . --parallel 8 cmake --install .注意configure.bat在 Windows 上对于路径反斜杠比较敏感，尽量用D:\Qt\...这样明确的全路径。如果安装路径带中文或空格，会极大增加 configure 和后续 CMake 的解析风险，我建议不要使用任何带空格或非 ASCII 字符的路径。
Windows 编译时还有两个容易出问题的点。一个是防御软件实时扫描会把 CPU 占用拉高，几千个小源文件的编译过程会被拖得非常慢，条件允许的话可以暂时把源码目录和构建目录加入排除列表。另一个是自定义 shell 环境不完整，用 PowerShell 而不是专用命令行环境时，cl.exe 可能不被识别，报错信息通常是 C 编译器无法找到这类字样。
4.3 编译过程中的现场监控与常见异常判断
编译一旦启动，不要干等着。我习惯另开一个终端监控磁盘和内存：
df -h # 查看剩余磁盘 free -h # 查看内存余量如果磁盘剩余空间逼近构建目录预期大小的 1.5 倍以下，就要警惕了。Qt 编译过程中有些中间文件非常大，特别是 Qt WebEngine 或 Qt QML 编译器相关的生成代码，峰值磁盘占用可能超出预期。我见过有人编译到一半磁盘写满，然后整个构建目录处于半损坏状态，最后只能全部删除重新来过。
还有一个小技巧：Ninja 在构建过程中会自动检测 CPU 核心数并默认高并行，如果你没有用--parallel指定并行度，在低配机器上很容易 OOM。我建议只要机器内存低于 32GB，就显式指定--parallel参数，宁可编译时间拉长半小时，也不要用系统卡死的代价去换几分钟加速。
5. 安装完成不是终点：环境变量与 Qt Creator 配置
5.1 让系统找到 Qt：PATH 和 CMAKE_PREFIX_PATH
cmake --install .结束并不代表你的 Qt 马上就能被系统识别。如果你是在 Linux 上安装到了自定义目录，使用 CMake 构建 Qt 项目时，find_package(Qt6)默认搜索的路径列表里没有你新装的 Qt，必须用CMAKE_PREFIX_PATH指明位置：
export CMAKE_PREFIX_PATH=/opt/Qt/6.5.3 export PATH=/opt/Qt/6.5.3/bin:$PATH把这两行写进~/.bashrc是常规操作。Windows 下可以使用setx PATH "D:\Qt\6.5.3-msvc\bin;%PATH%"把 Qt 的 bin 目录加入系统 PATH。之所以要加 bin 目录，是因为 Qt 的运行时库（如 Qt6Core.dll / libQt6Core.so）都在这里面，程序运行时需要找到它们。
如果是 Linux 系统级安装且使用了默认 prefix/usr/local，一般不需要手动设置 CMAKE_PREFIX_PATH，系统 CMake 搜索逻辑会自然命中。定制路径只要加好环境变量，就能正常工作。
5.2 Qt Creator 里添加自己编译的 Qt 版本
很多人的日常开发环境是 Qt Creator。装上自定义编译的 Qt 后，如果直接打开旧项目，Qt Creator 很可能仍然用着默认的 Qt 版本，项目编译用的不是你自己编出来的库。
正确配置顺序是这么走的。打开 Qt Creator，进入菜单“工具 -> 选项 -> Kits -> Qt Versions”。在 Qt Versions 页面点击“Add”，选择安装目录下bin/qmake的路径（Qt6 仍然会生成 qmake 作为 CMake 兼容和辅助工具）。确认 Qt Creator 能正确识别到版本号后，再切到“Kits”标签页，找到对应的构建套件，在 Qt version 下拉框中选到你刚添加的版本，并将编译器设定为与你编译 Qt 时一致的工具链。
这里有个高频错误：用 MSVC 编译出来的 Qt，在 Qt Creator 里 Kit 的编译器却选了 MinGW 或 GCC，运行时会出链接错误。编译器和 Qt 库必须是同一套 ABI，这个原则贯穿始终。
5.3 用 CMake 写个小样例验证安装是否成功
验证安装的最好方式不是看版本号，而是实际编译一个最小可运行程序。新建一个目录，放 CMakeLists.txt 和 main.cpp：
cmake_minimum_required(VERSION 3.16) project(qt_demo) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) find_package(Qt6 REQUIRED COMPONENTS Widgets) qt6_add_executable(qt_demo main.cpp) target_link_libraries(qt_demo Qt6::Widgets)main.cpp 写一个最简单的窗口：
#include <QApplication> #include <QLabel> int main(int argc, char *argv[]) { QApplication app(argc, argv); QLabel label("Qt 源码编译安装验证成功"); label.show(); return app.exec(); }然后执行：
mkdir build && cd build cmake .. cmake --build . ./qt_demo窗口能弹出来就说明 Qt 编译安装这条链路已经打通。如果find_package找不到 Qt6，优先检查 CMAKE_PREFIX_PATH 是否指向正确的安装目录，再确认安装目录下是否存在lib/cmake/Qt6/Qt6Config.cmake文件。
6. 我踩过的坑：编译安装常见报错与排查记录
6.1 configure 阶段最常见的一组报错
configure 阶段是失败率最高的环节，我总结了几个高频问题：
| 报错现象 | 真实原因 | 解决办法 |
|---|---|---|
GL/gl.h: No such file or directory | 缺少 OpenGL 开发头文件 | 安装 libgl1-mesa-dev，或使用-no-opengl关闭 |
Basic XLib functionality test failed | 缺少 xcb / xlib 相关开发库 | 安装 libx11-xcb-dev、libxkbcommon-dev 等 |
Perl not found | 缺少 Perl 环境 | 安装 perl，确保 perl 在 PATH 中 |
C compiler cannot create executables | 编译器环境未正确初始化 | Windows 用专用命令行环境；Linux 检查 g++ 是否安装 |
| 找不到 CMake | Qt6 对构建系统强制要求 | 安装 CMake 3.20 以上和 Ninja，重试 |
遇到 configure 报错，第一反应不是猜，而是去翻出错信息上方几千行中的ERROR:前缀说明。Qt configure 的逻辑很成熟，真正致命的错误一般都会明确打印出缺失项或测试失败项。
6.2 编译阶段：OOM、磁盘爆满和链接器崩溃
编译阶段最常见的三大元凶，我在前面其实已经提过几次，这里集中圈一下重点。
内存不足是排第一位的。Qt 的编译并行度高时，每个编译单元都可能吃掉几百 MB 内存，链接阶段更是吃内存大户，尤其是libQt6WebEngineCore这类巨型库，链接时的内存峰值常常突破 10GB。排查方法是在编译期间持续观察free -h或任务管理器。解决方案是按比例调低--parallel，比如内存 16GB 用 4，内存 32GB 用 8。曾经有个同事在 8GB 内存的虚拟机上用默认 Ninja 全并行编译，连续 3 次被 OOM Killer 杀掉进程，后来改成--parallel 2才顺利完成，虽然花了接近 3 小时，但至少能跑完。
第二个是磁盘爆满。构建目录里会存在大量.o文件、.a静态库和 CMake 临时文件。我建议在 build 开始前用df -h查一下剩余空间，至少确保比预计构建目录大小的 2 倍还宽裕。用完的源码包和中间目录及时清掉，避免后续操作被垃圾文件干扰。
第三个是链接器崩溃，多见于 Windows 平台。MSVC 的link.exe在某些大库链接时可能报LNK1102: out of memory，或者fatal error LNK1248: image size exceeds max size。这类问题一般和堆内存限制有关。优先办法是减少单次链接规模，最简单的操作还是降并行度。如果还不行，检查是否开启了/DEBUG符号生成，release 配置下符号信息通常会小一些。
6.3 安装后的环境问题很隐蔽
编译安装成功不代表万事大吉，环境问题往往更隐蔽。
有一次我在 Linux 上源码编译完 Qt，写的小程序运行时报error while loading shared libraries: libQt6Core.so.6: cannot open shared object file。原因很简单：程序运行时找到不到安装目录下的.so库。我当时的解决方法是确认用户目录的.bashrc里已经加入了 PATH，并检查是否需要设置LD_LIBRARY_PATH。实际上 Qt 把库路径写进了 Qt 的安装目录，但运行时系统并不自动感知。两个典型解决思路：一是把export LD_LIBRARY_PATH=/opt/Qt/6.5.3/lib:$LD_LIBRARY_PATH写进 profile；二是在可执行文件运行时通过ldd查看库解析情况。
Windows 上同样的现象通常是The code execution cannot proceed because Qt6Core.dll was not found。解决办法就是把 Qt 安装目录的 bin 放入 PATH，或者直接把相关 DLL 复制到 exe 同级目录。
还有一个更隐蔽的问题：当系统里同时存在官方包管理器装的 Qt 和你自己源码编译的 Qt 时，路径优先级会决定程序用哪个版本的库。排查时用ldd或 Windows 的 Dependencies 工具看实际加载路径，不要凭感觉猜。
6.4 重新构建的心态：不要硬着头皮修，推倒重来的成本往往更低
很多人（包括我）在源码编译 Qt 时都有过这种经历：编译到一半发现一个 configure 参数没加对，于是想只改参数然后继续构建。Qt 的 CMake 构建系统能感知部分配置变化，但如果你改的是-prefix、模块列表这类影响全局的参数，继续构建的结果通常是各种诡异报错。
我现在的原则是：只要动了关键的 configure 参数，就把整个 build 目录删掉，重新走一遍 configure。理由很简单，Qt 的配置关系盘根错节，某个模块的开启与关闭会影响其他模块的编译宏、链接库列表、plugin 配置，部分参数无法被增量构建正确覆盖。删掉 build 目录重来，看起来浪费时间，实际上通常比在损坏的配置上修修补补更能保证结果正确。
顺带说一句，源码目录也可以随时保持干净。Git 管理的仓库里，只要不修改源码文件，删掉 build 目录对源码零影响，configure 会重新生成全部构建文件。这也是 Out-of-source 构建的一个隐藏福利：你有无限次“反悔”的机会。
写在最后的几点体会
把 Qt 编译及安装这套流程完整走一遍，比用官方安装器点几下鼠标学到的东西多得多。我现在看到源码里某个模块的功能实现，能快速脑补出它在不同 configure 参数下会被如何裁剪，遇到某些网络或图形相关的问题，也能第一时间想到是不是构建库时把对应功能关掉了。建议第一次动手的人，先按下面的顺序来：确认需求、装好工具链、想清楚 configure 参数、用最小模块组合跑通一次，再逐步增加需要的模块。先求跑通，再求完整，这个策略能帮你在 Qt 源码构建这条路上少吃 90% 的苦头。如果你后面还要做交叉编译或制作定制化 Qt 套件，这套源码编译的底子就是最关键的起步能力。
