简介：面向Qt初、中级开发者的十余个基于Qt5/Qt6的小型项目合集，覆盖多媒体播放器、文件管理器、简单游戏、数据可视化等常见应用场景。各项目按功能模块组织，帮助熟悉Qt Creator开发流程，深入理解信号与槽机制、QWidgets与QML界面设计、模型视图架构等核心概念。资源共2000个文件，其中cpp和h源码为学习核心，qml和ui定义界面逻辑，pro/cmake等工程文件便于直接构建运行，bmp、png、ico等图像资源配套使用，压缩包整体约70.55MB，目录结构清晰，适合按需检索；资源中既有基础控件示例，也有动画交互演示。目前已有1206人学习下载。通过研究这些独立小项目，读者可掌握跨平台GUI开发技巧，并接触网络通信、多媒体播放、数据库操作等Qt特定模块；每个项目都是可动手改造的完整模板，既能巩固面向对象设计原则，也可作为后续项目开发的灵感库与练手素材，适用自学、课程设计或技术分享。
1. 解开这个压缩包之前，先弄清楚你要的是“跑通”还是“抄骨架”
一个标题写着“QT项目分享-QT6-QT5-十余个QT项目汇总-优质QT小项目.zip”的资源，下载下来之后大多数人是这样操作的：解压，看到一排骨灰级的子目录，随手点开一个.pro文件，结果 Qt Creator 要么报一堆红字，要么编译按钮干脆是灰的。于是结论变成“这个包是坏的”——其实它没坏，只是你的打开方式不对。这类合集真正的价值分两层：给新手当练手材料，给熟手当窗口框架的骨架库。前者需要把一个一个项目跑起来看效果，后者只需要从里面提取出“最小可运行模板”，然后把它改造成自己的小工具。这篇文就把两层价值分别拆开讲，从版本判断、环境搭配、构建细节到常见翻车点，全部按实际操作路径走一遍。
2. 先看 Qt5/Qt6 混装问题，再谈跑项目：版本差异才是最大的隐藏门槛
如果压缩包里全是 Qt5 项目或全是 Qt6 项目，事情反而简单，一套编译器从头编到尾就行。但标题里同时出现 Qt6 和 Qt5，意味着里面的子项目大概率是不同时期攒出来的，有的用老 API，有的用新模块。这时候你用同一个 Qt 版本去打开所有项目，一定会有几个编译失败。这不是项目代码质量差，而是 Qt6 对 Qt5 的兼容并不是“零成本无缝升级”。
2.1 Qt6 移除和改名了哪些东西：老项目编译失败的大头
在 Qt6 里，一批 Qt5 时代的类被移除、合并或者改了归属模块，这是老项目拿到 Qt6 下编译失败的第一大原因。常见的有这么几类：
QRegExp被QRegularExpression取代，Qt6 里老类直接没了，用到就必须改。QTextCodec从 QtCore 里剥出去了，Qt6 默认没这个类，要么启用core5compat模块，要么改用 UTF-8 相关接口。QDesktopWidget被移出 QtWidgets，获取屏幕尺寸的写法要换成基于QScreen的 API。- 字符串和编码相关的行为更严格，Qt6 默认源码按 UTF-8 处理，老项目如果依赖本地代码页，容易出现中文乱码。
- 构建标准也变了：Qt6 要求 C++17 起步，很多 Qt5 项目里写的是
CONFIG += c++11，编译器兼容还好，但遇到用 C++14 特性的依赖库时就需要动手调。
举一个典型的 Qt5 老代码在新版本下的报错现场：
// 老代码常见的写法（Qt5 时代） QRegExp rx("\\d+"); rx.indexIn("abc123def"); qDebug() << rx.cap(0); // Qt6 下的替代写法 QRegularExpression re("\\d+"); QRegularExpressionMatch match = re.match("abc123def"); if (match.hasMatch()) { qDebug() << match.captured(0); }这段差异说明两点。第一，QRegExp的核心用法变了，indexIn这种带状态的匹配方式被函数式接口取代，改代码时不光要换类名，还要改调用逻辑。第二，如果你在 Qt6 里强行保留老写法，编译器会直接报“找不到 QRegExp”，而不是给一个温和的弃用警告。遇到这种错误，先不要怀疑代码逻辑，去确认是不是版本迁移问题。
2.2 三分钟判断一个子项目属于 Qt5 还是 Qt6 时代
拿到一个未知来历的子目录，不要急着双击.pro编译，先做一次快速体检。我一般会按下面这个顺序看：
- 看工程文件里
QT +=写了哪些模块。出现core5compat说明作者已经为 Qt6 做过适配；出现charts、serialport、network这类模块要记下来，它们不是每个 Qt 安装包都默认带。 - 搜代码里的
#include，看有没有QRegExp、QTextCodec、QDesktopWidget。出现这三个，基本可以判定是 Qt5 时代写的。 - 看
CONFIG +=后面是c++11还是c++17。前者更可能是老项目，后者大概率面向 Qt6。 - 注意有没有
CMakeLists.txt。如果一个子项目同时放了.pro和CMakeLists.txt，优先用 CMake 方式构建，这是 Qt6 官方推荐的构建方向。
也可以直接在命令行里搜，速度快得多：
# 在子目录里搜旧类名，判断项目的 Qt5 痕迹 grep -rn "QRegExp\|QTextCodec\|QDesktopWidget" --include="*.cpp" --include="*.h" . # 查看工程文件声明的模块 grep "^QT" ./*.pro这个命令的输出会直接告诉你：哪些子项目带着 Qt5 旧类，哪些依赖额外的模块。搜完之后分类记录，比打开一个报错一次再回来查要高效得多。批量处理合集时，这种“先体检再编译”的习惯能省下大量来回试错的时间。
2.3 环境怎么配：Qt5.15 和 Qt6 LTS 各装一套，互不干扰
既然合集里新旧项目都有，最省心的办法不是用一个版本硬扛，而是把 Qt5 和 Qt6 各装一套，按项目年代切换构建套件。这个做法看起来费硬盘空间，实际上是确定性最高的一条路，能避开大量不必要的源码改造。
| 目的 | 推荐版本 | 原因 |
|---|---|---|
| 编译 Qt5 时代的小项目 | Qt 5.15 系列 | 这是 Qt5 的收尾版本，兼容 Qt5.6 到 Qt5.14 的大部分写法 |
| 编译新写的 Qt6 小项目 | Qt6 的 LTS 版本（如 6.5 或更新的 LTS） | 新 API、C++17、模块划分清晰，官方维护期长 |
| 老项目临时搬到 Qt6 | 不推荐，除非你愿意改代码 | Qt6 下的老代码需要替换旧类和调整构建参数 |
安装时有一个细节容易忽略：Qt6 安装器默认不会把所有模块都打勾。像 Qt Charts、Qt SerialPort、Qt Multimedia 这类模块，在 Qt5 时代是独立安装项，Qt6 里依然要靠你自己在组件列表里勾选。装完记得检查一下组件是否齐全，不然后面打开含charts的工程文件会直接报“Unknown module”。
两个版本并存时，真正容易出问题的是 PATH 环境变量。Windows 下如果 Qt5 的 bin 目录和 Qt6 的 bin 目录同时出现在 PATH 里，程序运行时找 DLL 的顺序就会变成玄学，跑出来的进程到底加载了哪个版本全看运气。我的习惯是 PATH 里只留当前主力版本，另一个版本的路径让 Qt Creator 自己管理，命令行编译需要时再临时指定。
3. 把合集里每个项目跑起来：Qt Creator 操作、依赖补齐与最小命令行
环境装好后，接下来的目标是一口气把合集里的项目逐个跑起来。这个阶段最常见的挫败感来自三个地方：构建套件选错导致按钮灰色、依赖模块缺失导致 qmake 直接中止、以及命令行编译时工具链选错导致满屏乱码。这一章把三条路都捋一遍。
3.1 构建套件选不对，项目就永远“灰色”：先学会挑 kit
打开一个.pro文件后，左下角的构建按钮如果是灰色的，或者显示“No kit is defined for this project”，问题基本不在代码，而在 Qt Creator 没给你这个项目找到一个能用的构建套件。Qt Creator 的 kit 等于一条完整工具链：编译器、qmake 路径、CMake 工具、调试器、目标平台位数。任何一个环节失效，这个 kit 就会从可用列表里消失。
处理步骤我习惯按下面这个顺序排查：
- 打开“工具 → 选项 → Kits”，看左侧有没有可用的 kit，右侧编译器一栏有没有黄色感叹号。
- 如果编译器那一栏是空的，检查本机是否装了对应的编译工具链。Windows 上最常见的组合是 Qt 版本自带 MinGW，而不是系统里随便哪个编译器都能配到 Qt 上。
- 确认 qmake 路径和编译器位数匹配。Qt6 的 MinGW 64 位套件不能配 32 位的 MinGW 编译器，反之亦然，这属于构建套件里最容易被忽略的硬约束。
- 回到项目，右键选择“Change Kit”，手动指定当前项目用的 kit。
这套动作解决的核心问题，是让 Qt Creator 知道用哪个 qmake 去解析你的.pro文件。特别注意：不同版本的 Qt 配不同版本的 qmake，如果你电脑里同时有 Qt5.15 和 Qt6，一定要确认选中的 kit 用的 qmake 来自正确的安装目录。
3.2 缺少模块的统一解法：先用维护工具补齐依赖，再考虑改代码
打开一个写了QT += charts的工程文件，Qt 告诉你“Project ERROR: Unknown module(s) in QT: charts”，这时候正确的反应不是删掉这行配置，而是回头查自己的 Qt 安装里到底有没有这个模块。Qt Charts 在 Qt5 和 Qt6 里都是一等公民模块，但都不默认安装，需要你手动补上。
补模块的通行做法是：
- 打开 Qt 自带的维护工具（通常在 Qt 安装目录下）。
- 登录账户后选择“添加/移除组件”。
- 按当前版本的筛选标签，找到你要的模块。以 Qt Charts 为例，它一般位于“Qt Framework”分类下。
- 勾选，开始安装，装完重启 Qt Creator。
这个动作做完之后，原来报“Unknown module”的工程文件一般就能正常解析了。如果补齐模块后仍然报错，再考虑是不是代码本身用了更高版本才有的子模块，比如 Qt6 里的charts下面细分了QtCharts命名空间，和 Qt5 有差异。这种时候才需要动.pro文件，但前提一定是“依赖确实没装错版本”。
3.3 用命令行在 Windows/Linux 上把子项目跑通的最小命令
Qt Creator 虽然方便，但排查问题时我还是经常落到命令行，因为编译日志更直白，不受编辑器缓存干扰。命令行构建 Qt 项目通常只需要三步：qmake 生成构建文件、调用对应的 make 工具编译、运行产物。
# 第一步：用 qmake 生成工程文件对应的 Makefile # 注意：这里的 qmake 必须来自当前项目所匹配的 Qt 安装目录 qmake your_project.pro -o Makefile # 第二步：调用平台对应的构建工具编译 # Windows + MinGW：mingw32-make # Windows + MSVC：在开发者命令行里用 nmake # Linux/macOS：make make -j4 # 第三步：运行可执行文件 ./your_project这三个命令看起来简单，实际运行时的坑在第二步。如果你在 Windows 上装了 MinGW 版本的 Qt，却在系统里用了 Visual Studio 的 nmake，或者反过来用 mingw32-make 去处理 MSVC 生成的 Makefile，都会得到一堆莫名其妙的链接错误。判断标准很简单：先看qmake是从哪个 bin 目录调出来的，然后使用与之配套的 make 工具。MinGW 和 MSVC 的构建产物不兼容，这是 Qt 跨工具链编译时最典型的翻车点。
另外，命令行编译时如果 PATH 里同时存在 Qt5 和 Qt6 的 bin 目录，qmake命令可能被前一个目录劫持，导致你明明想编 Qt6 项目结果用 Qt5 的 qmake。规避办法是执行前先echo $PATH看一眼当前环境，或者直接写全路径调用。
4. 从编译通过到真正能跑：库路径、编码和“可运行骨架”三件事
项目编译成exe不代表能双击运行。Qt 程序的运行依赖一堆动态库，还有方向稍微不对就乱码的编码处理。这一章讲的就是编译成功之后、运行成功之前最容易卡住的三个地方。
4.1 Release 版打不开、Debug 版正常？多半是库路径和 windeployqt 的问题
从 Qt Creator 里按 F5 跑得挺好，但到文件管理器里双击 exe 就是没反应，或者弹一个“缺少 DLL”的错误框——这是 Qt 桌面开发最经典的“本地能跑、分发就挂”问题。原因是 Creator 会把 Qt 的 bin 路径临时注入到进程环境里，程序运行时不缺 DLL；脱离了这个环境，exe 就成了“孤儿”。
解决办法是让 Qt 自己把需要的依赖搬到 exe 旁边，工具叫windeployqt，在 Qt 安装目录的 bin 下。
# 进入发布目录，然后执行部署命令 cd /path/to/your/release # 用与当前 exe 同版本的 windeployqt，避免版本错配 windeployqt your_project.exe # 可选：如果程序用了 CMake 构建，也可以用 # cmake --install . --config Release 先安装到干净目录再部署执行完之后目录里会出现 Qt6Core.dll、Qt6Widgets.dll、platforms 文件夹等一整套运行依赖，这是“能跑”的前置条件。需要注意两点：第一，windeployqt 的版本必须和编译用的 Qt 版本一致，拿 Qt6 的 windeployqt 去折腾 Qt5 的 exe，结果不可控；第二，部署完之后不要手动删掉那些看起来“多余”的 plugins 目录，很多运行期崩溃其实是在程序启动阶段加载插件失败，而不是代码逻辑问题。
4.2 中文乱码与源码编码：Qt5/Qt6 下必须主动调整的三处参数
中文乱码在 Qt 合集的示例项目里几乎是必现问题，因为它跟源码文件的编码方式直接相关。Qt6 默认按 UTF-8 读取源码，如果你用旧的 Visual Studio 默认代码页保存的.cpp文件，里面的字符串字面量就会被错误解码。
我的处理习惯分三处：
- 源码文件统一另存为 UTF-8 编码。Linux 下用
file -i确认单文件编码，Windows 下用编辑器的“另存为 UTF-8”功能，这个动作能消除一半乱码问题。 - 字符串字面量改成
QStringLiteral(...)或者少于必要场景时用QString::fromUtf8(...)。Qt5 时代很多代码喜欢直接tr("中文")，Qt6 下tr配合 UTF-8 源码一般没问题，但如果源码本身不是 UTF-8，就要靠fromUtf8兜底。 - 如果使用 MSVC 编译，在
.pro里强制指定 UTF-8 源码解析，避免编译器用本地代码页读源码。
# 在 .pro 文件里追加：MSVC 下强制源码按 UTF-8 解析 msvc { QMAKE_CXXFLAGS += /utf-8 }这个配置在 Qt5 和 Qt6 的 MSVC 工具链下都有效。它的原理是告诉编译器“这个项目的源文件是 UTF-8 编码”，让字符串字面量进入程序时保持原始字节。加上之后如果是界面文字乱码，再回头查字体；如果是日志乱码，再查输出通道的编码转换，排查方向就清晰多了。
4.3 从每个小项目里抽取最小可运行骨架：你最该抄的其实是 4 类文件
拿到十个项目，最忌讳的是每一个都从头到尾读代码，那既浪费时间又记不住。我的做法是每个项目只挑四样东西看，看完之后把最顺手的组合存成自己的“骨架模板”：
proj_template/ ├── myapp.pro # 工程配置：模块声明、构建参数、图标资源 ├── main.cpp # 入口：QApplication 初始化、主窗口创建 ├── mainwindow.h # 窗口类声明：槽函数、成员变量 └── mainwindow.cpp # 窗口实现：界面布局和业务逻辑这四类文件构成一个 Qt Widgets 应用的完整最小闭环。合集中的每个小项目，不管功能多花哨，底层都是这个结构。区别只在.pro里声明的模块不同、mainwindow里的控件和槽函数数量不同。把骨架抽出来之后，你之后做任何桌面小工具，都先复制这套骨架，再往里填业务代码，而不是从头新建工程、重新配一遍模块和编译器选项。
这个“抄骨架”的动作，也是后面把合集变成个人工具库的起点。不要把十个项目当成十份阅读理解，而是当成十份不同的界面布局、交互逻辑和模块用法的样板。
5. 避坑指南：打开这种 Qt 合集最容易踩的 4 个坑
下面这四条坑是我处理这类混合版本 Qt 合集时遇到频率最高的问题，每一条都按现象、原因、解决三个步骤展开，可以直接当排查手册用。
5.1 现象：.pro 文件直接报 “Unknown module(s) in QT: charts”
这是开头最容易遇到的一个报错，而且它出现在你的代码还没参与编译之前，容易让人误以为工程文件坏了。事实上，qmake 在解析工程文件阶段就会检查QT +=后面写的模块是否存在于当前版本中，发现没有就直接终止。原因通常是：你的 Qt 安装里没有勾选 Qt Charts 组件，老项目里写了QT += charts，新环境里查无此模块。解决办法分两步。第一，用 Qt 自带维护工具补装 Charts 或 SerialPort 这类非默认组件，这是首选方案；第二，如果补装不方便且你确定用不到图表功能，再考虑注释或删除QT += charts，但前提是你要确认代码里没有引用QtCharts的头文件，否则编译到中途还是会失败。更麻烦的一种情况是 Qt6 里 Charts 模块的导入写法有变化，少部分项目需要同时调整头文件和工程文件两处。遇到这种就先搜工程文件里的 charts 引用，再查代码里的 include 语句，一起改掉。
5.2 现象：编译日志出现 “No such file or directory”，但文件明明存在
这个现象很迷惑，因为你去资源管理器里看，路径是对的，文件就摆在那里。原因大概率出在路径本身包含中文或空格字符上。Qt Creator 对中文路径的支持虽然比早年好得多，但命令行工具链（尤其是 MinGW 系）对非 ASCII 路径仍然偶尔会失常。另外还有一种可能：项目启用了 shadow build，构建目录和源码目录分离，相对路径的基准变了，导致引用资源文件或头文件时找不到。解决办法并不复杂：把整个项目复制到一个纯英文、无空格的路径下（例如D:\qt_workspace\sample_proj），重新用 Creator 打开；如果还不行，检查工程文件里的相对路径写法，尽量用$$PWD作为基准而不是裸的相对路径。这个问题在合集里特别容易引爆，因为解压时很多人习惯放在“下载”或者其他带中文的目录里，一旦编译失败先怀疑代码，结果白白耽误时间。
5.3 现象：Debug 能跑、Release 崩，切 Qt5/Qt6 套件后行为不一致
Debug 和 Release 行为不一致是 Qt 程序里的经典问题，在混合版本合集里会被放大。常见原因有两个。第一，代码里存在未初始化的变量，Debug 模式下编译器会把内存区域清零，Release 下保留垃圾值，导致行为随机；第二，Release 编译时优化器对未定义行为的处理方式不同，代码里如果有指针悬空或越界访问，Debug 可能侥幸过关，Release 直接崩溃。结合本标题的场景还有一个更隐蔽的点：如果你在同一个构建目录下先用 Qt5 kit 编了一次，再切换 Qt6 kit 接着编，旧的构建产物没清干净，运行时会加载到版本不匹配的动态库。解决方法是养成“切换 kit 必清空构建目录”的习惯。具体操作是：项目右键选择“清除项目”，或者直接删掉构建目录，再重新构建。避免这个问题最简单的方法是让 Qt Creator 使用默认的 shadow build 目录布局，也就是每个 kit 一套独立的 build 目录，不要手动把构建输出指定到源码目录里。
5.4 现象：整个项目拷到另一台电脑上，exe 双击后提示缺少 Qt 动态库
这也是一条经验值问题。很多人把一个编译跑通的目录整个拷到另一台机器，里面的 exe 能看见，但双击就报找不到 Qt6Core.dll，或者即便拷了 DLL 又说找不到 plugin 目录。原因很简单：Qt 程序的运行依赖一堆动态库和插件，直接把 exe 拷走不代表依赖也跟着走了。正确做法不是手动拖 DLL，而是用部署工具把依赖树完整导出。Windows 下用windeployqt，Linux 下用ldd查看依赖再手工收集库。完整流程是：编译 Release 版本，把 exe 单独放到一个空目录，运行windeployqt app.exe，然后把整个目录压缩分发，而不是把源码工程目录连带着一堆中间文件发过去。这里还有一个额外提示：如果你分发的程序要用到 MySQL 或者其他第三方库，windeployqt不会自动帮你带上这些第三方依赖，需要把对应的 DLL 也放进 exe 所在目录。
6. 把小项目当模板库用：提取最小骨架，一小时改出自己的小工具
最后说一个长期受用的习惯：拿到这类合集，不要只停留在“跑通”层面，要把里面最顺手的一个项目降维成自己的模板库。做法很简单——选一个界面布局风格顺眼的子项目，把它跑通之后，复制一份出来，改掉类名、程序名和窗口标题，保留它的工程配置和代码框架，然后开始往里加自己的功能。
比如你在合集里找到一个带菜单栏、状态栏和工具栏的小窗口程序，这就是一个天然的主框架。你可以把菜单里的动作全部清空，保留它的窗口缩放逻辑和布局管理，再在中央区域放上自己要做的控件。这样一个界面骨架如果从零开始搭，少说要花半小时配置菜单、动作、快捷键、布局策略，而直接改造一个现成项目，十分钟就能把骨架立起来。很多熟手说“Qt 开发快”，快的其实不是写控件，而是这种模板复用带来的速度。
我现在每到一个新环境，第一件事就是把“最小可运行骨架”跑一遍：一个main.cpp里创建QApplication和主窗口，一个极简.pro文件声明待用的模块，确认这个环境下编译和运行都通，才开始写业务代码。这能提前暴露环境问题，而不是把环境问题混进业务缺陷里一起排查。
早年我拿到这种压缩包，习惯是把项目挨个点开看效果，看完就删，觉得自己“见过挺多项目”。直到后来真要做一个桌面工具时，才发现自己连一个能跑的窗口框架都要从零开始拼。现在的做法反过来了：每次打开一个合集，先选三个与目标最接近的项目，跑通两个，再用其中一个当骨架——这个顺序省下的时间，比闷头看代码多得多。希望帮到你。
本文还有配套的精品资源，点击获取
