05_Qt 核心模块概览——Qt Core、Gui、Widgets、Quick 的职责划分

Qt 核心模块概览：Qt Core、Gui、Widgets、Quick 的职责划分

引言

写到第五篇，我们已经创建过一个 Qt Widgets 项目，也知道了 QApplication、窗口和事件循环分别在做什么。

但当你打开 Qt 文档、查看 CMake 配置，或者在 Qt Creator 中添加类时，很快会遇到一串看似相近的名字：Qt Core、Qt Gui、Qt Widgets、Qt Qml 和 Qt Quick。

初学者最常见的困惑是：

Qt Gui 既然叫 GUI，为什么还不能直接使用 QPushButton？
Qt Widgets 和 Qt Quick 都能做界面，到底该选谁？
为什么控制台程序也要链接 Qt Core？
为什么 Widgets 程序使用 QApplication，而 Quick 程序通常使用 QGuiApplication？

如果只把模块名记成一张表，项目稍微复杂一点就会重新混乱。这一篇要建立的是一条更稳定的判断线：

Qt 的模块划分，本质上是在划分能力边界和依赖关系。需要什么能力，就依赖对应模块；不需要的模块，尽量不要主动建立依赖。

本文先从"为什么 Qt 不把所有功能塞进一个库"开始，再依次理解 Qt Core、Qt Gui、Qt Widgets、Qt Quick 的职责，最后给出实际项目的选型方法。

一、先建立全局地图：模块之间是什么关系？

先看一张简化后的依赖图。图中的箭头从"使用模块"指向"它直接依赖的模块"，表达的是代码依赖，而不是学习顺序或程序执行流程。

图 1：Qt 核心模块的能力边界与直接依赖。Widgets 与 Quick 是两条可选 UI 路线，不存在"先经过 Widgets，再进入 Quick"的关系。

这不是完整的 Qt 模块依赖图，但足够帮助我们理解入门阶段最重要的关系。

模块	核心职责	典型类或能力
Qt Core	非图形的基础能力	`QObject`、事件循环、容器、文件、线程、定时器
Qt Gui	图形系统的基础设施	窗口、屏幕、输入事件、图片、字体、绘图、OpenGL/Vulkan 抽象
Qt Widgets	传统桌面控件界面	`QWidget`、`QMainWindow`、按钮、布局、对话框
Qt Qml	QML 语言与运行时	QML 对象创建、C++ 与 QML 交互、属性绑定基础
Qt Quick	基于 QML 的现代 UI 框架	`Item`、`Rectangle`、动画、场景图渲染

可以先记住两句话：

在常见的 Qt 应用开发中，**Qt Core 是最基础、最广泛复用的模块。**Widgets、Gui 等模块也建立在 Core 提供的基础能力之上。
Gui 是图形基础设施，Widgets 和 Quick 是两条不同风格的界面路线。

这也是为什么下面两种写法代表完全不同的项目类型：

cmake 复制代码

# 纯业务、命令行或后台任务
target_link_libraries(MyTool PRIVATE Qt6::Core)

# 传统桌面窗口程序
target_link_libraries(MyApp PRIVATE Qt6::Widgets)

# QML / Qt Quick 图形界面程序
target_link_libraries(MyApp PRIVATE Qt6::Quick)

这里有一个重要细节：链接 Qt6::Widgets 时，CMake 会把它依赖的 Qt6::Gui 与 Qt6::Core 一并处理；链接 Qt6::Quick 时，也会带入它所需的底层能力。CMake 中链接上层模块时，通常会通过目标依赖关系自动带入它所依赖的 Qt 模块，因此我们一般只需要声明直接使用的模块。

⚠注意：Qt Module ≠ DLL ，文章讨论的是 Qt 的"模块划分"，CMake 中的 Qt6::Core、Qt6::Gui 等则是对应的 CMake target。不要简单把"模块"、"CMake target"、"DLL"当成同一个概念。

二、为什么 Qt 要这样分层？

从使用者角度看，模块划分似乎只是"头文件放在哪个目录"的问题；从框架设计角度看，它解决了至少四个实际问题。

让不需要图形界面的程序保持轻量

许多程序根本不需要窗口：日志采集工具、命令行转换器、后台服务、测试程序、网络代理等。

它们依然很需要 Qt 的许多能力，例如：

QString 与 Unicode 文本处理；
QFile、QDir、QJsonDocument；
QTimer 和事件循环；
QThread、信号槽、网络模块；
跨平台路径与时间处理。

如果这些能力和窗口系统强制绑在一起，那么一个只处理文件的命令行工具也要初始化图形环境。这既没有意义，也会增加依赖和部署负担。

所以 Qt 将非图形基础能力放进 Qt Core，让这类程序只使用最必要的部分。

将"操作系统图形细节"与"界面控件"分开

Windows、macOS、Linux 的窗口系统并不相同。窗口创建、屏幕信息、键盘鼠标输入、剪贴板、高 DPI 缩放等，都是图形应用的底层问题。

这些能力由 Qt Gui 统一抽象。它主要解决三个问题：

如何创建和管理图形窗口；
如何接收鼠标、键盘、触摸等输入；
如何处理屏幕、字体、图片和绘制。

而按钮、菜单、表格、表单布局这些属于更高层的"界面控件"问题，交给 Qt Widgets 解决。

因此：

Qt Gui 不是"所有可见 UI 控件"的集合；它是构建图形应用所需的底层公共设施。

允许两种 UI 技术并存

桌面软件常见的传统控件界面，和强调动画、触摸、流畅视觉效果的现代界面，解决的问题并不完全一样。

Qt Widgets 适合成熟的桌面工具、管理系统和表单型软件；
Qt Quick 更擅长动态视觉效果、动画、触摸交互和高度定制的 UI。

二者共享 Qt Core 和 Qt Gui 的底层能力，但不会被迫使用同一套控件模型。这让 Qt 能覆盖更广的应用场景。

控制编译、部署和架构复杂度

模块边界也是工程边界。一个只做数据处理的库若只依赖 Qt Core，就不会因为引入了业务库而被动依赖窗口系统。

在大型项目中，这一点尤其重要。界面层可以选择 Widgets 或 Quick，应用层负责组织业务流程，核心业务层则尽量不感知具体 UI 技术：

图 2：一种适合逐步演进的项目分层。箭头表示代码依赖方向，两种 UI 层是替代路线，不是连续执行的两层。

这样做能让底层业务代码脱离界面存在，后面即使把 Widgets 界面替换成 Quick 界面，业务层也不需要推倒重来。

三、Qt Core：所有 Qt 程序的基础层

Qt Core 不负责显示按钮和窗口，但它是 Qt 最核心的模块。

Qt Core 并不等于"Qt 的非 GUI 小工具集合"，它实际上提供了 Qt 对象模型、事件系统、元对象机制、容器、字符串、线程等大量框架基础设施。

可以把它理解成 Qt 对标准 C++ 的一层工程化补充：它提供跨平台能力、对象模型、异步事件机制和常用工具类。

Qt Core 主要包含什么？

类别	常见类	用途
对象模型	`QObject`、`QMetaObject`	父子对象关系、信号槽、动态属性
安全观察	`QPointer`	QObject 销毁后自动置空
应用与事件	`QCoreApplication`、`QEventLoop`、`QTimer`	程序生命周期、事件分发、定时任务
文本与容器	`QString`、`QByteArray`、`QList`、`QVector`、`QHash`	文本、字节数据与容器操作
文件与数据	`QFile`、`QDir`、`QDateTime`、`QJsonDocument`	文件系统、时间、JSON 等
并发与同步	`QThread`、`QMutex`、`QSemaphore`	线程与同步控制

后续文章中要讲的信号槽、事件循环、对象树、线程亲和性，绝大多数都从 Qt Core 开始。

`QCoreApplication`：没有 GUI 的 Qt 应用对象

只使用 Qt Core 的程序通常创建 QCoreApplication：

cpp 复制代码

#include <QCoreApplication>
#include <QTimer>
#include <QDebug>

int main(int argc, char *argv[])
{
    QCoreApplication app(argc, argv);

    QTimer::singleShot(1000, [] {
        qInfo() << "任务执行完成";
        QCoreApplication::quit();
    });

    return app.exec();
}

这段程序没有窗口，却依然需要事件循环：QTimer::singleShot() 要等待一秒后才触发，lambda 中调用 quit() 后，app.exec() 才返回。

对应的 CMake 配置很小：

cmake 复制代码

find_package(Qt6 REQUIRED COMPONENTS Core)

qt_add_executable(CoreDemo main.cpp)
target_link_libraries(CoreDemo PRIVATE Qt6::Core)

这正是模块化带来的好处：一个后台任务可以使用 Qt 的事件驱动编程方式，却完全不触碰图形界面。

什么时候应该只用 Qt Core？

以下场景通常只需要 Qt Core，或以它为主要依赖：

命令行工具；
后台服务与守护进程；
文件转换、数据处理、日志工具；
不包含界面的业务库；
自动化测试中的非 UI 部分。

请注意，"使用 Qt"并不等于"必须显示窗口" 。只要程序不需要窗口、屏幕、图片绘制或控件，就不应该为了习惯而创建 QApplication。

四、Qt Gui：图形应用的基础设施层

当程序开始接触屏幕、窗口、图片、字体、键盘鼠标或图形绘制时，就会进入 Qt Gui 的范围。

Qt Gui 负责什么？

Qt Gui 包含的不是业务控件，而是它们赖以生存的图形基础能力：

QGuiApplication：图形应用的应用对象；
QWindow、QScreen：窗口与屏幕；
QMouseEvent、QKeyEvent、QTouchEvent：输入事件；
QImage、QPixmap、QIcon：图像和图标；
QFont、QColor、QPalette：字体、颜色与调色板；
QPainter：二维绘制 API；
图形 API 的相关抽象。

可以用下面的图理解它。Qt Gui 位于平台能力与上层图形方案之间，但 Widgets、Quick 和自定义绘制是并列消费者，不是依次经过的三个阶段：

图 3：Qt Gui 统一适配操作系统图形能力，上层方案根据项目需要选择。

`QGuiApplication`：有图形能力，但没有 Widgets 控件

QGuiApplication 继承自 QCoreApplication，因此它具备事件循环和 Core 的所有能力；同时它增加了图形应用所需的全局环境，例如屏幕、窗口系统集成和输入设备。

下面的代码读取当前主屏幕信息：

cpp 复制代码

#include <QGuiApplication>
#include <QScreen>
#include <QDebug>

int main(int argc, char *argv[])
{
    QGuiApplication app(argc, argv);

    QScreen *screen = app.primaryScreen();
    if (screen) {
        qInfo() << "屏幕尺寸：" << screen->size();
        qInfo() << "逻辑 DPI：" << screen->logicalDotsPerInch();
    }

    return 0;
}

它可以访问屏幕，却不能写：

cpp 复制代码

QPushButton button("确定"); // 不可用：QPushButton 属于 Qt Widgets

原因并不是 QGuiApplication "能力不够强"，而是按钮这一类控件根本不属于 Qt Gui 模块。Qt Gui 提供的是窗口和图形基础，Qt Widgets 才在这些基础上实现了可复用的传统控件。

一个容易混淆的边界：`QImage` 不等于界面

QImage、QPixmap 和 QPainter 都属于 Qt Gui，但它们只是图像数据和绘制能力，不代表你已经在写 Widgets。

例如，下面是离屏绘制一张图片：

cpp 复制代码

#include <QImage>
#include <QPainter>

int main()
{
    // 这里使用的是 QImage 的离屏图像处理和 QPainter 绘制，不需要创建窗口，也不需要启动 Qt 事件循环.
    // 因此这个示例甚至不需要创建 QGuiApplication。
    QImage image(320, 160, QImage::Format_ARGB32_Premultiplied);
    image.fill(Qt::white);

    QPainter painter(&image);
    painter.setPen(Qt::blue);
    painter.drawText(image.rect(), Qt::AlignCenter, "Hello Qt Gui");

    image.save("hello.png");
}

代码没有创建窗口，却使用了 Qt Gui 的图像和绘制能力。以后学习 paintEvent()、自定义控件和图表绘制时，会频繁接触这些类。

五、Qt Widgets：传统桌面软件的控件体系

如果你用 Qt Creator 创建的是默认 Widgets Application，那么你正在使用的就是 Qt Widgets。

它建立在 Qt Core 和 Qt Gui 之上，提供传统桌面应用最常见的控件、布局和窗口框架。

Qt Widgets 提供什么？

类别	代表类	解决的问题
基类	`QWidget`	所有传统控件的共同基类
顶层窗口	`QMainWindow`、`QDialog`	主窗口、对话框、窗口组织
常用控件	`QPushButton`、`QLabel`、`QLineEdit`	输入、展示和操作
布局管理	`QHBoxLayout`、`QVBoxLayout`、`QGridLayout`	自适应排列控件
复杂控件	`QTableView`、`QTreeView`、`QTabWidget`	表格、树、分页等桌面交互
辅助组件	`QFileDialog`、`QMessageBox`、`QAction`	文件选择、提示框、菜单命令

为什么 Widgets 适合桌面工具？

Widgets 的设计目标是高效构建以窗口、表单、菜单、工具栏、表格为核心的桌面软件。它的优势很直接：

控件体系成熟，桌面软件常用组件齐全；
与菜单栏、工具栏、停靠窗口、快捷键等桌面交互天然匹配；
C++ 中直接创建和操作控件，调试路径清晰；
大量工业软件、内部工具和配置类程序都有成熟实践。

例如一个最小 Widgets 窗口：

cpp 复制代码

#include <QApplication>
#include <QPushButton>

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);

    QPushButton button("点击我");
    button.resize(240, 80);
    button.show();

    return app.exec();
}

与 QGuiApplication 相比，这里使用的是 QApplication。它在事件循环和图形能力之上，增加了 QWidget 控件体系所需的应用级支持。三种 Application 的完整继承与选型关系会在第九节用图说明。

因此，如果程序使用 Qt Widgets 控件体系，通常应使用 QApplication 作为应用对象。

Widgets 中的对象树和布局

Widgets 的另一个重要特点是"控件树"。例如：

cpp 复制代码

auto *window = new QWidget;
auto *layout = new QVBoxLayout(window);
auto *label = new QLabel("请输入姓名", window);
auto *edit = new QLineEdit(window);

layout->addWidget(label);
layout->addWidget(edit);
window->show();

这里的 label 和 edit 以 window 为父对象。窗口销毁时，Qt 的对象树会处理这些子控件的销毁。QVBoxLayout 则负责让控件随着窗口大小变化而重新排列。

这是一种典型的命令式 C++ UI 编程方式：开发者通过创建对象、设置属性、加入布局来构造界面。

六、Qt Quick：面向现代动态界面的 QML 框架

Qt Quick 是 Qt 的另一条 UI 路线。它通常与 QML 一起使用，用声明式方式描述界面，再由 Qt 的场景图系统完成高效渲染。

先分清几个概念：

QML 是描述对象与属性关系的声明式语言，以及支持这门语言运行的相关机制；
Qt QML 为QML提供引擎，让QML 与 C++具备交互的能力；
Qt Quick 是 UI 框架，提供基于 QML 的可视化 UI 类型、场景图、动画等。

所以，"使用 Qt Quick"通常意味着"使用 QML 写界面，并用 C++ 承担业务、数据和系统能力"。

一个最小的 Qt Quick 界面

Main.qml：

qml 复制代码

import QtQuick

Window {
    width: 360
    height: 220
    visible: true
    title: "Qt Quick Demo"

    Rectangle {
        anchors.fill: parent
        color: "#f3f6fb"

        Text {
            anchors.centerIn: parent
            text: "Hello Qt Quick"
            font.pixelSize: 28
            color: "#1f3a5f"
        }
    }
}

对应的 main.cpp：

cpp 复制代码

#include <QGuiApplication>
#include <QQmlApplicationEngine>

int main(int argc, char *argv[])
{
    QGuiApplication app(argc, argv);
    QQmlApplicationEngine engine;

    engine.loadFromModule("ModuleDemo", "Main");
    if (engine.rootObjects().isEmpty()) {
        return -1;
    }

    return app.exec();
}

在 Qt 6 中，可以这样配置 CMake：

cmake 复制代码

cmake_minimum_required(VERSION 3.21)
project(ModuleDemo LANGUAGES CXX)

find_package(Qt6 REQUIRED COMPONENTS Quick)
qt_standard_project_setup()

qt_add_executable(ModuleDemo main.cpp)

qt_add_qml_module(ModuleDemo
    URI ModuleDemo
    VERSION 1.0
    QML_FILES Main.qml
)

target_link_libraries(ModuleDemo PRIVATE Qt6::Quick)

请留意：Qt Quick 程序通常使用 QGuiApplication，不是 QApplication。因为它需要图形窗口和输入系统，但它没有使用 QWidget 控件体系。

声明式 UI 和命令式 UI 的区别

对比同一个"显示文本"的需求：

Widgets：先创建对象，再逐步设置属性。

cpp 复制代码

auto *label = new QLabel("当前温度：25℃");
label->setAlignment(Qt::AlignCenter);
label->setStyleSheet("font-size: 24px;");

Quick：直接描述界面应当呈现的状态。

qml 复制代码

Text {
    text: "当前温度：25℃"
    anchors.centerIn: parent
    font.pixelSize: 24
}

两者不是简单的"新旧替代"关系，而是两种不同的 UI 构建方式：

维度	Qt Widgets	Qt Quick
主要语言	C++	QML + C++
UI 表达方式	命令式创建对象	声明式描述状态
擅长场景	表单、工具、菜单、复杂桌面控件	动画、触摸、动态视觉界面
渲染模型	以传统控件绘制为主	基于场景图的渲染体系
初学重点	控件、布局、信号槽	QML 属性、绑定、组件、C++ 交互

Qt Quick 的优势与学习成本

Qt Quick 在动画、状态变化、缩放适配和触摸交互方面表达力很强。例如一个属性变化可以自然带上动画：

qml 复制代码

Rectangle {
    width: 80
    height: 80
    color: "steelblue"

    Behavior on x {
        NumberAnimation { duration: 250 }
    }
}

但它也要求开发者理解 QML 的属性绑定、JavaScript 表达式、组件边界，以及 C++ 对象暴露给 QML 的方式。对于第一个桌面管理工具，直接从 Widgets 开始往往更直观；对于产品化界面或嵌入式屏幕，Quick 则常常更合适。

七、不要混淆：Qt Gui、Widgets、Quick 到底差在哪？

可以把三者放在同一个问题下比较：它们各自回答什么问题？

模块	它主要回答的问题	它不负责什么
Qt Gui	怎样对接窗口系统、屏幕、输入、图片和绘制？	不提供 `QPushButton`、`QTableView` 等传统控件
Qt Widgets	怎样高效组织桌面窗口、表单、菜单和控件？	不以 QML 的声明式动画界面为主要目标
Qt Quick	怎样用 QML 构建动态、可组合、可动画化的界面？	不提供 Widgets 那套传统桌面控件体系

一个很实用的判断方法是先问"项目需要哪类能力"，再选择对应模块：

图 4：四类需求是独立判断项。模块可以按需叠加，但 Widgets 与 Quick 通常只选择一条作为主 UI 路线。

八、如何为项目选择模块？

下面不是硬性规定，而是入门阶段足够可靠的选型建议。

场景一：命令行文件处理工具

需求：读取 CSV，转换为 JSON，输出日志，不显示窗口。

选择：Qt Core。

程序通常由 QCoreApplication 提供事件循环，并按需使用 QFile、QJsonDocument、QString 等类。

不要创建 QApplication，也不要链接 Widgets。

场景二：内部管理工具、配置工具、工业桌面软件

需求：主窗口、菜单栏、工具栏、表格、树、设置对话框、文件选择。

选择：Qt Widgets。

程序使用 QApplication，界面可以由 QMainWindow、QTableView、QDialog 等控件组成。

这是传统桌面应用最稳妥的起点，也是本专栏接下来控件、布局、Designer 章节的主线。

场景三：嵌入式仪表盘、车机界面、触摸屏产品

需求：流畅动画、全屏展示、分辨率适配、触摸操作、品牌化视觉效果。

选择：Qt Quick。程序通常使用 QGuiApplication，界面用 QML，底层业务与设备通信用 C++。

场景四：需要自定义图像生成或绘制的程序

需求：生成缩略图、绘制报表图片、操作像素、访问屏幕信息。

选择：至少需要 Qt Gui，可以使用 QImage、QPainter 等类；是否再加 Widgets 或 Quick，取决于是否还需要相应的 UI。

场景五：一个项目能同时使用 Widgets 和 Quick 吗？

可以，但不建议把它当成默认方案。

Qt 提供了将 Quick 内容嵌入 Widgets 的能力，例如 QQuickWidget；也可以在适当场景下嵌入传统控件。但混用意味着要同时处理两套 UI 生命周期、样式、输入和渲染边界，调试成本更高。

对于初学者，更好的原则是：

一个应用优先确定一条主 UI 路线。只有当某个局部界面确实需要另一套技术的独特能力时，再有目的地混用。

九、从模块到应用对象：三种 Application 的选择

模块选择最终会反映到 main() 中的应用对象选择上。

应用对象	适用模块与场景	能否使用 QWidget
`QCoreApplication`	Core：命令行、服务、后台任务	不可以
`QGuiApplication`	Gui、Quick：图形窗口、QML 界面	不可以
`QApplication`	Widgets：传统控件桌面程序	可以

继承关系与项目选择规则如下：

图 5：左侧是类继承关系，右侧是项目选型。继承链不代表程序要依次创建三个 Application 对象。

子类会拥有父类的能力，但这不意味着每个程序都应该选最底下的 QApplication。正确原则是：

选择能满足当前程序需求的最小应用对象。

例如，Quick 程序使用 QGuiApplication 已经足够；为了"看起来更全面"而换成 QApplication，只会额外引入 Qt Widgets 依赖，并没有获得实际收益。如果 Quick 程序本身没有使用 QWidget，则没有必要为了 Quick 而使用 QApplication。

十、初学者最常见的四个误区

误区一：`Qt Gui` 就是"做界面的模块"

不准确。Qt Gui 是图形界面的基础设施模块。它能处理窗口、屏幕、字体、图像和输入，但不等于 Widgets 控件库。

如果你要使用 QPushButton，需要的是 Qt Widgets；如果你要在 QML 中使用 Rectangle 和动画，需要的是 Qt Quick。

误区二：Quick 是 Widgets 的升级版

不准确。Qt Quick 并不是"Widgets 的新版本"，而是另一种 UI 技术路线。两者解决的重点不同：一个偏成熟桌面控件体系，一个偏声明式与动态视觉界面。

选择时看产品和交互需要，而不是单纯按"新旧"判断。

误区三：只要创建窗口，就必须使用 `QApplication`

不准确。只有使用 QWidget 体系时才需要 QApplication。纯 QWindow 或 Qt Quick/QML 应用通常使用 QGuiApplication。

误区四：一个项目直接把所有模块都链接上最省事

短期可能省了一两行配置，长期会模糊依赖边界。尤其是共享业务库，更应避免让它依赖 Widgets 或 Quick。

从一开始让依赖表达真实需求，后续拆分模块、编译测试和跨平台部署都会更轻松。

十一、一个实用的分层建议

当你的程序从一个窗口成长为多个功能模块时，可以按照图 2 的方式组织依赖：界面层只负责展示与交互，应用层编排业务流程，领域层保存核心规则，基础设施层封装文件、网络、数据库等具体实现。

其中，domain 和通用业务代码尽量只依赖 Qt Core 或标准 C++；infrastructure 按需依赖 Core、Network、Sql 等模块；界面层则根据主 UI 路线依赖 Qt Widgets 或 Qt Quick / Qt Qml。

这不是要求你在第一个 Hello World 项目中就搭建复杂架构，而是希望你从现在开始有一个方向：界面依赖应当停留在界面层，业务代码不应到处出现 QWidget。

下面这个例子不推荐使用，将界面和控制层进行了耦合，未来业务层不太好进行拆解

cpp 复制代码

// 不推荐
class DeviceManager
{
public:
    void connectDevice(QWidget* parent);
};

建议业务和UI像下面这样区分开：

cpp 复制代码

// 更合理
class DeviceManager
{
public:
    bool connectDevice();
};

UI 层：

cpp 复制代码

if (!manager.connectDevice()) {
    QMessageBox::warning(...);
}

十二、总结

现在回到文章开头的几个问题：

Qt Core 提供事件循环、对象模型、容器、文件、线程等非图形基础能力；
Qt Gui 提供窗口系统、屏幕、输入、图像、字体和绘制等图形基础设施；
Qt Widgets 在 Gui 之上提供传统桌面控件与布局体系；
Qt Quick 借助 QML 提供声明式、动态化的现代 UI 框架；
QCoreApplication、QGuiApplication、QApplication 的选择，取决于程序所使用的能力边界。

整套选择关系可以回看图 4：先判断程序需要非图形基础、图形基础、传统桌面控件还是动态 QML 界面，再按需链接对应模块。这个判断是能力组合，不是从 Core 一路走到 Quick 的必经流程。

模块划分不是为了让 Qt 看起来复杂，而是为了让你能够按需组合能力。理解这层边界后，面对新的 Qt 类时就可以先问自己两个问题：

它属于哪个模块？
我的项目是否真的需要这个模块？

下一篇将进入 Qt Core 中最常用的一部分：QString、QList、QVector、QMap 等基础数据类型与容器。理解它们的使用场景和性能特征，才能写出更自然、更可靠的 Qt 代码。

下一篇预告：《Qt 基本数据类型与容器------QString、QList、QVector、QMap 性能对比》

05_Qt 核心模块概览——Qt Core、Gui、Widgets、Quick 的职责划分

Qt 核心模块概览：Qt Core、Gui、Widgets、Quick 的职责划分

引言

一、先建立全局地图：模块之间是什么关系？

二、为什么 Qt 要这样分层？

让不需要图形界面的程序保持轻量

将"操作系统图形细节"与"界面控件"分开

允许两种 UI 技术并存

控制编译、部署和架构复杂度

三、Qt Core：所有 Qt 程序的基础层

Qt Core 主要包含什么？

QCoreApplication：没有 GUI 的 Qt 应用对象

什么时候应该只用 Qt Core？

四、Qt Gui：图形应用的基础设施层

Qt Gui 负责什么？

QGuiApplication：有图形能力，但没有 Widgets 控件

一个容易混淆的边界：QImage 不等于界面

五、Qt Widgets：传统桌面软件的控件体系

Qt Widgets 提供什么？

为什么 Widgets 适合桌面工具？

Widgets 中的对象树和布局

六、Qt Quick：面向现代动态界面的 QML 框架

一个最小的 Qt Quick 界面

声明式 UI 和命令式 UI 的区别

Qt Quick 的优势与学习成本

七、不要混淆：Qt Gui、Widgets、Quick 到底差在哪？

八、如何为项目选择模块？

场景一：命令行文件处理工具

场景二：内部管理工具、配置工具、工业桌面软件

场景三：嵌入式仪表盘、车机界面、触摸屏产品

场景四：需要自定义图像生成或绘制的程序

场景五：一个项目能同时使用 Widgets 和 Quick 吗？

九、从模块到应用对象：三种 Application 的选择

十、初学者最常见的四个误区

误区一：Qt Gui 就是"做界面的模块"

误区二：Quick 是 Widgets 的升级版

误区三：只要创建窗口，就必须使用 QApplication

误区四：一个项目直接把所有模块都链接上最省事

十一、一个实用的分层建议

十二、总结

`QCoreApplication`：没有 GUI 的 Qt 应用对象

`QGuiApplication`：有图形能力，但没有 Widgets 控件

一个容易混淆的边界：`QImage` 不等于界面

误区一：`Qt Gui` 就是"做界面的模块"

误区三：只要创建窗口，就必须使用 `QApplication`