Qt5翻金币游戏源码解析：QGraphicsView与信号槽实现翻牌交互

简介：QT翻金币游戏源码是一套基于Qt5框架的跨平台小游戏完整工程，面向希望学习GUI布局、动画与窗口管理的Qt初中级开发者。工程围绕开始界面、菜单界面与关卡选择三部分展开，包含20个关卡的状态展示、自定义按钮悬停点击特效、金币翻转动画及界面平滑切换等实现，可用来对照理解信号与槽、QPropertyAnimation、QGraphicsView/QGraphicsScene和QSS样式表的落地方式。压缩包共104个文件、约13.53MB，以cpp与h源码、o目标文件、png图像、wav音效及rc/qrc资源文件为主，另含pro工程文件与可执行程序，目录可直接导入Qt Creator编译调试。目前已有911人学习，适合作为课程设计、Qt入门练习或界面交互案例的参考工程。

1. 解压先别急着点运行：这套翻金币 Demo 的定位

下载包解压出来是一个 .pro 文件加一组 .h/.cpp，这就是 Qt5 翻金币游戏源码的全部家当。用 Qt Creator 打开工程，选一套 Desktop Kit，点绿色三角，三十秒后弹出一个固定大小的窗口：一排排金币背面朝上，点一张翻一张，两张图案一致就消掉，不一致就翻回去，步数和用时在状态栏跳。玩法朴素，但恰因为它小，从界面搭建到状态判定整条链路都摊在源码里，不用翻文档也能顺着代码往下读。它适合三类人：正在学 Qt Widgets 想把信号槽、图形视图、事件分发串起来的初学者；需要一个能跑能改、代码量一两千行的实训底稿的人；以及想给自己小工具塞个关卡小游戏当彩蛋的开发者。它没有存档、没有排行榜、没有联网对战，价值就四个字：结构完整。

2. 工程骨架：Widgets + Graphics View 这套组合为什么够用

2.1 为什么翻牌游戏更适合 QGraphicsView 而不是堆按钮

初学者做翻牌，第一反应往往是往 QGridLayout 里塞一堆 QPushButton，每个按钮设个图标，点中就把 icon 换成正面的图。十六张牌的时候这套写法能跑，但牌数一涨就开始露怯：布局重算是全局的，加动画要给每个按钮单独挂 QPropertyAnimation，点击拾取还得靠按钮自身的 clicked 信号逐层转发，视觉上层叠、缩放、阴影这些效果基本做不了。翻牌游戏的核心交互是「在一个二维平面上拾取某一块矩形并让它独立变化」，这正好是 Graphics View 框架的强项。

QGraphicsScene 里放的是一堆 QGraphicsItem，每个 item 有自己的坐标、自己的 paint()、自己的 boundingRect()，框架帮你做碰撞检测和鼠标拾取。卡牌数量从 16 变成 48，你要改的只是洗牌循环里的配对数量，坐标是算出来的，不是布局管理器排出来的。棋盘的缩放、整体的淡入淡出，靠 QGraphicsView 的 transform 一行解决。至于为什么不用 QML：QML 写这套确实更清爽，但要引入 QtQuick 模块，对一个以「看懂 C++ 信号槽」为目标的练手项目来说，多一层语言就多一层劝退。这类小 Demo 用 Widgets + Graphics View 的组合，学习成本和运行开销都最低。

2.2 目录结构与 .pro 文件：五个源文件撑起一个游戏

按这类翻金币 Demo 的常见组织方式，源码目录不会太深，基本是「主窗口 + 棋盘 + 卡牌 + 配置」四块拼起来。下面这个结构是我读过和写过的同类工程里最典型的一种：

FlipCoin/ ├── FlipCoin.pro # qmake 工程文件，决定编译哪些源文件 ├── main.cpp # 入口，只做 QApplication 构造和主窗口 show ├── mainwindow.h/.cpp # 主窗口：菜单、HUD 标签、QGraphicsView 容器 ├── gameboard.h/.cpp # 棋盘：继承 QGraphicsScene，管洗牌、翻牌、判定 ├── carditem.h/.cpp # 单张卡牌：继承 QGraphicsObject，负责绘制和翻转动画 ├── levelconfig.h/.cpp # 关卡参数：配对数、列数、限时，从 JSON 读取 └── res/ ├── res.qrc # 资源清单 └── faces/*.png # 卡牌正面图案，成对存在

工程文件本身没什么玄机，但它是新手第一个绊倒的地方，值得单独看一眼：

QT += core gui widgets # Qt5 起 widgets 必须显式声明，只在 gui 里是编不出 QWidget 的 TARGET = FlipCoin # 生成的可执行文件名 TEMPLATE = app # 应用工程，不是 lib CONFIG += c++11 # Demo 里常用的 lambda 连接需要 C++11 SOURCES += main.cpp \ mainwindow.cpp \ gameboard.cpp \ carditem.cpp \ levelconfig.cpp HEADERS += mainwindow.h \ gameboard.h \ carditem.h \ levelconfig.h RESOURCES += res/res.qrc # 图案资源打进二进制，避免发布时漏图

这段 qmake 里真正容易出错的是第一行：QT += widgets在 Qt4 时代不需要，Qt5 之后 QWidget 系列被拆到独立模块，只写QT += core gui会在链接阶段报一堆未定义符号，而报错信息通常指向 moc 生成的中间文件，看着像是代码问题，实际是模块没引进来。第二处是RESOURCES，把图片打进 .qrc 之后，运行时路径是:/faces/1.png这种带冒号的形式，而不是相对路径，写错了在开发机上因为工作目录巧好能找到文件而不报错，一打包给别人就满屏空白卡牌。CONFIG += c++11也别省，源码里但凡是connect(card, &CardItem::clicked, this, &GameBoard::onCardClicked)这种新式连接，缺了它编译直接过不去。

2.3 三类核心对象与信号槽数据流

整个游戏跑起来只有三类对象在动：主窗口负责把控件摆好、把 HUD 数字刷新；棋盘持有全部卡牌、维护「当前翻开了哪两张」这个临时状态；卡牌个体只管自己长什么样、被点没被点。三者之间用信号槽串起来，形成一条单向的数据流：卡牌被点击 → 棋盘接收并判定 → 棋盘发出状态变化 → 主窗口更新标签。

// mainwindow.cpp —— 主窗口只做装配，不碰游戏规则 MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent) { m_scene = new GameBoard(this); // 棋盘负责全部游戏逻辑 m_view = new QGraphicsView(m_scene, this); m_view->setRenderHint(QPainter::Antialiasing); m_view->setHorizontalScrollBarPolicy(Qt::ScrollBarAlwaysOff); // 关掉滚动条，棋盘按窗口大小铺 m_view->setVerticalScrollBarPolicy(Qt::ScrollBarAlwaysOff); setCentralWidget(m_view); // 棋盘不知道 UI 长什么样，只发数值；主窗口负责把数值翻译成文字 connect(m_scene, &GameBoard::movesChanged, this, [this](int moves) { m_stepsLabel->setText(QStringLiteral("步数：%1").arg(moves)); }); connect(m_scene, &GameBoard::timeChanged, this, [this](int sec) { m_timeLabel->setText(QStringLiteral("用时：%1 s").arg(sec)); }); connect(m_scene, &GameBoard::levelFinished, this, &MainWindow::onLevelFinished); m_scene->startLevel(1); // 从第一关开始 }

这段代码值得琢磨的是职责边界。棋盘类里没有任何一个 QLabel，它只通过movesChanged、timeChanged、levelFinished三个信号往外播报状态；主窗口也用 lambda 就地消化，不做转发。这样拆的好处是，哪天你想把 HUD 从 QLabel 换成自绘的仪表盘，或者换个皮肤，改的只是主窗口那几十行，棋盘一行都不用动。参数上startLevel(1)的入参是关卡序号，关卡参数从 levelconfig 里取，所以后面加关卡只要往 JSON 里添一条，不用改逻辑代码。

3. 核心模块拆解：一次翻牌从点击到判定的完整链路

3.1 洗牌与配对数：怎么保证不出现「孤牌」

配对游戏最怕出现奇数张牌或者某张图案只出现一次，那样关卡永远通不了。正确的做法是先生成「对数」再打乱，而不是先铺满随机数再想办法配对。这也是这类源码里唯一一处需要动点脑筋的算法，我把它拆开看：

// gameboard.cpp —— 生成成对数据后做 Fisher-Yates 洗牌 void GameBoard::initBoard(const LevelConfig &cfg) { QVector<int> faces; const int pairCount = cfg.pairCount; // 配对数，8 对就是 16 张牌 // 第一遍：每张图案放两份，天然保证成对，绝不会出现孤牌 for (int i = 0; i < pairCount; ++i) { faces << i << i; } // 第二遍：Fisher-Yates 原地洗牌，复杂度 O(n) for (int i = faces.size() - 1; i > 0; --i) { const int j = QRandomGenerator::global()->bounded(i + 1); std::swap(faces[i], faces[j]); } // 第三遍：按行列坐标铺到场景里，坐标是算出来的，方便改列数 const qreal cardW = 96, cardH = 96, gap = 8; for (int idx = 0; idx < faces.size(); ++idx) { const int row = idx / cfg.cols; const int col = idx % cfg.cols; auto *card = new CardItem(faces.at(idx)); card->setPos(col * (cardW + gap), row * (cardH + gap)); addItem(card); // GameBoard 本身是 QGraphicsScene connect(card, &CardItem::clicked, this, &GameBoard::onCardClicked); } }

pairCount是关卡唯一的数量参数，第 3 遍循环里idx / cols和idx % cols把一维下标翻成行列，所以哪怕你把列数从 4 改成 6，卡牌的排布也不用重写。洗牌用QRandomGenerator::global()而不是老式的qrand()，前者在 Qt5.10 之后是官方推荐，内部线程安全，不用自己播种。std::swap要记得#include <utility>，部分 MinGW 编译器的标准库头文件不会间接带进来，报错指向swap未定义，看着莫名其妙。

有人会问为什么不直接std::shuffle，也可以，但要额外传一个随机数引擎对象，对 Demo 规模来说多写三行没意义。真正的坑在别处：如果这张表的资源图片只有 12 张，而你配了 8 对（16 张），那么QPixmap(":/faces/%1.png".arg(faceId))在 faceId 超过 11 时会加载失败，卡牌正面变成一块空白，但逻辑上它仍然是可配对的——游戏能通，只是看着像少了几张图。这种「逻辑正确、资源缺失」的 bug 靠肉眼很难发现，建议在 initBoard 里加一句Q_ASSERT(pairCount <= resFaceCount)，让它在 debug 构建时直接崩在源头。

3.2 翻牌状态机：一把布尔锁解决「连点三张」的经典翻车点

新手写翻牌最容易在同一个地方栽跟头：手快连着点三张，第三张的判定和第一张的翻回动画搅在一起，最后出现两张正面朝上却都翻回去，或者三张同图却只消掉一对。根因是「等待两张牌比对结果」这段时间里，界面是仍然可点的。解决办法不是禁用鼠标，而是加一把逻辑锁，让棋盘知道「我现在正忙」。

// gameboard.cpp —— 点击入口只做三件事：校验、翻开、凑够两张就上锁 void GameBoard::onCardClicked(CardItem *card) { // 已翻开 / 已配对 / 棋盘正在等待上一次比对动画 —— 三种情况一律忽略 if (card->isFaceUp() || card->isMatched() || m_locked) { return; } card->flipTo(true); // 翻到正面，内部启动动画 m_pending.append(card); // 暂存待判定队列 if (m_pending.size() == 2) { ++m_moves; emit movesChanged(m_moves); m_locked = true; // 关键：立刻上锁，拦住第三张 QTimer::singleShot(600, this, &GameBoard::resolvePending); // 600ms 留够动画时间 } } // 600ms 后统一结算，此时界面上的动画已经播完 void GameBoard::resolvePending() { CardItem *a = m_pending.at(0); CardItem *b = m_pending.at(1); if (a->faceId() == b->faceId()) { a->setMatched(true); // 配对成功，标记后不可再点 b->setMatched(true); ++m_matchedPairs; if (m_matchedPairs == m_config.pairCount) { emit levelFinished(m_moves, m_elapsed); // 通关，把成绩抛给主窗口 } } else { a->flipTo(false); // 不匹配，两张一起翻回去 b->flipTo(false); } m_pending.clear(); m_locked = false; // 解锁，允许下一轮点击 }

m_locked这个布尔量是整个交互的核心，它存在的唯一意义就是把「两张牌翻开到判定完成」这段时间标记为不可交互窗口。QTimer::singleShot(600, ...)里的 600 就是留白时长，必须大于等于单张卡牌的翻转动画时长（下一节会讲到动画曲线），否则用户会看到牌还没翻到位就被翻回去，观感很差。对QGraphicsObject调用singleShot时传的上下文对象是this，棋盘被销毁时这个定时器会自动取消，不会野指针回调，这是 Qt5 的父子对象机制顺手给的后悔药。

补充一句状态顺序：m_pending一定要在resolvePending末尾 clear，而不是在开头清。因为levelFinished信号可能在中间发出，如果槽函数里做了「重置关卡」的操作，而此时队列已经空了、锁又没释放，就会出现新关卡第一张牌点不动的玄学现象。

3.3 绘制与翻转动画：QPainter 打底，属性动画补帧

卡牌的视觉分正面和背面两套，用 QPainter 在 paint() 里按状态分支绘制是最省事的写法。翻转效果不用真的做 3D 旋转，把宽度从 cardW 缩到 0 再展开到 cardW，中间切换正反面标志，人眼就会读成「翻过来」——这类 Demo 普遍这么干，效果和成本最划算。

// carditem.cpp —— 绘制按 m_faceUp 分支，动画驱动的是 scaleX 属性 void CardItem::paint(QPainter *p, const QStyleOptionGraphicsItem *, QWidget *) { p->setRenderHint(QPainter::Antialiasing, true); const QRectF r = boundingRect(); if (!m_faceUp) { // 背面：深色圆角块 + 一个简单符号，正式项目里换 QPixmap 即可 p->setPen(QPen(QColor(120, 92, 30), 2)); p->setBrush(QColor(120, 92, 30)); p->drawRoundedRect(r, 8, 8); p->setPen(Qt::white); p->drawText(r, Qt::AlignCenter, QStringLiteral("?")); } else { // 正面：白底描边 + 加载 qrc 里的图案 p->setPen(QPen(QColor(180, 140, 40), 2)); p->setBrush(QColor(255, 244, 214)); p->drawRoundedRect(r, 8, 8); p->drawPixmap(r.toRect(), QPixmap(QStringLiteral(":/faces/%1.png").arg(m_faceId))); } } // 翻转：先把宽度压扁到 0，中途换面，再展开 void CardItem::flipTo(bool faceUp) { m_faceUp = faceUp; // 先改状态，paint 立刻反映 auto *anim = new QPropertyAnimation(this, "scaleX", this); anim->setDuration(260); anim->setStartValue(1.0); anim->setKeyValueAt(0.5, 0.05); // 中点压到几乎为零，制造「牌立起来」的错觉 anim->setEndValue(1.0); anim->setEasingCurve(QEasingCurve::InOutQuad); anim->start(QAbstractAnimation::DeleteWhenStopped); // 播完自删，避免动画对象堆积 update(); }

scaleX得自己用Q_PROPERTY声明在CardItem类头里，配套写 getter/setter，setter 里改成员再update()；不然 QPropertyAnimation 找不到这个属性，运行时会打印 "you're trying to animate a non-existing property"，然后动画悄无声息地什么也不做——这条警告藏在控制台里，很容易被忽略。setKeyValueAt(0.5, 0.05)里的 0.05 不是 0，留一点点宽度是为了避免某些渲染后端在完全压扁时出现闪烁。动画时长 260ms、缓存曲线InOutQuad，这两个参数和上一节说的 600ms 留白是配套的，改动任意一个都要回头看另一个，不然节奏就乱了。DeleteWhenStopped这个结束策略也别省，一局游戏翻几十次，每次 new 一个动画对象不释放，内存曲线肉眼可见地往上爬。

3.4 计时、步数与通关判定

计时器用QTimer一秒一跳就够，别用 16ms 的高频定时器去刷界面，那是给逐帧动画用的，翻牌游戏的时间精度到秒级，白白浪费 CPU 还把电量吃掉。步数的递增时机在第 3.2 节里跟着配对一起做，因为只有凑够两张才算「一步」，单张翻开不计。

// gameboard.cpp —— 关卡启动时同时拉起计时器 void GameBoard::startLevel(int levelIndex) { resetBoard(); // 清场景、清计数、解锁 m_config = LevelConfig::load(levelIndex); // 从 JSON 取关卡参数 initBoard(m_config); // 铺牌 m_elapsed = 0; m_moves = 0; emit movesChanged(0); emit timeChanged(0); if (!m_timer) { m_timer = new QTimer(this); connect(m_timer, &QTimer::timeout, this, [this] { ++m_elapsed; emit timeChanged(m_elapsed); if (m_config.timeLimit > 0 && m_elapsed >= m_config.timeLimit) { m_timer->stop(); emit levelFailed(m_elapsed); // 超时，交给主窗口弹提示 } }); } m_timer->start(1000); // 1000ms 一个 tick，精度足够 }

关卡参数放在外部 JSON 里，是想加难度时不用重新编译。这套字段不多，一张表就能说清：

levelFailed和levelFinished两个信号分开播报，主窗口那边可以根据不同信号给出「通关」或「超时」两套文案和音效。计时器在resetBoard()时记得stop()，重开关卡不停止的话，上一关的定时器还在跑，秒数就会越跳越快——这是重开功能加进去之后最常见的回归 bug。

4. 把它跑起来：三套系统上的构建、调试与打包

4.1 环境准备：Qt5 版本与编译器怎么选

这类源码对 Qt5 的小版本不挑，5.9 以上都能编，但编译器要跟 Qt 的构建套件对上：官方安装器给的 MinGW 版就配 MinGW 的 Kit，MSVC 版就配对应版本的 Visual Studio 工具链，混着用会在链接阶段报一堆 ABI 不匹配的符号错误，而且这种报错信息又长又没头绪，属于典型的新手劝退现场。安装 Qt 时至少勾一个 Desktop 套件，MinGW 版自带编译器最省事，不需要额外装 Visual Studio。

Linux 下一般用发行版包管理器装qt5-default（或qtbase5-dev）加qmake、make、g++三件套。macOS 用官方安装器的 clang 套件即可，如果从包管理器装，装完记得跑一句qmake -v确认路径，防止和系统里已有的其他 Qt 版本打架。判断环境是否就绪的标准很简单：命令行敲qmake -v能打印出 Qt 版本，且这个版本指向你打算用的那一套。版本号输出了但指向别的安装目录，是最容易骗过自己的情况，编译能过，运行时却报找不到某版本的库。

4.2 qmake 命令行构建与 Creator 里的两处必改项

习惯命令行的可以直接建个独立构建目录，源码目录保持干净：

# 在源码同级建 build 目录，避免中间文件污染工程 mkdir -p build && cd build # 生成 Makefile，release 构建；debug 调试时换成 CONFIG+=debug qmake ../FlipCoin.pro CONFIG+=release # 并行编译，-j 后面跟核数；Windows + MinGW 用 mingw32-make -j8 make -j8

qmake的参数里CONFIG+=release决定优化等级和是否带调试符号，跑性能或者发给别人之前用 release，自己排查崩溃就切 debug。../FlipCoin.pro这个相对路径不能省，qmake 允许你把 Makefile 生成在任意目录，靠的就是它反推源码位置。编译完成后产物名由 .pro 里的 TARGET 决定，Windows 上是release/FlipCoin.exe，Linux/macOS 就在当前目录的FlipCoin。

在 Qt Creator 里跑，有两处必须自己核对。一是左下角的 Kit 选择，装完 Qt 之后如果同时存在多个套件，默认选中的可能不是你刚装的那个；二是项目 → 运行配置里的「工作目录」，图形界面项目默认是构建目录，如果你的代码里有按相对路径读关卡 JSON 的地方，工作目录不对就会读到空配置，卡牌一张都不出来。稳妥做法是把 JSON 也塞进 qrc，用:/config/levels.json读，路径问题一次性根治。

4.3 发布打包：windeployqt 打不全的三个依赖

Qt 程序不是什么绿色单文件，Windows 上必须把 Qt 的 DLL 一起带上。官方工具windeployqt能把大部分依赖扫出来：

# 先建个干净的发布目录，别在构建目录里直接打包 mkdir -p deploy && cp build/release/FlipCoin.exe deploy/ cd deploy # 扫依赖并拷入 Qt5Core/Gui/Widgets、平台插件和图片格式插件 windeployqt --release --no-translations FlipCoin.exe

--no-translations是砍掉翻译文件，小游戏用不上，能省几 MB。打包完先在本机双击跑一遍，重点看是不是白窗口、是不是缺图，然后换一台没装 Qt 的机器再验一次。这一轮很容易暴露三个问题：一是平台插件缺失，现象是程序启动立刻退出，命令行里会打印「This application failed to start because no Qt platform plugin could be initialized」，本质是platforms/qwindows.dll没拷过去；二是图片格式插件缺失，PNG 在 Qt 里通常能靠内置支持，但如果你用了 JPG 或 WebP，需要额外确认imageformats目录在；三是 qrc 里引用的路径大小写，Linux 打包到 Windows 或者反向搬运时，大小写敏感差异会让图片集体消失。

5. 踩坑记录：这套源码换台机器就容易卡住的五处

5.1 构建与运行期的三个高频问题

现象一：编译报undefined reference to vtable for CardItem。原因是有 Q_OBJECT 宏的类没有被 moc 处理，而 moc 只处理头文件里声明的类，或者被#include "xxx.moc"显式包含的 cpp 内类。解决：检查 carditem.h 里是不是漏了Q_OBJECT，或者类只写在 .cpp 里却忘了在文件末尾#include "carditem.moc"；另外 .pro 的 HEADERS 里必须列出这个头文件，qmake 靠它决定哪些文件送进 moc。

现象二：程序能启动，但整个视图一片空白，卡牌一张不显示。原因通常不是逻辑问题，而是坐标全叠在 (0,0)，或者是 item 加进去了但没设置场景矩形，QGraphicsView 自动 fitInView 时算出来可视区域是空的。解决：在铺牌之后根据行列数和卡牌尺寸setSceneRect(内容包围盒)，再在 resizeEvent 里调用一次fitInView(sceneRect(), Qt::KeepAspectRatio)。这个坑很容易被误判成「洗牌没执行」，白花时间在算法里找问题。

现象三：Debug 能跑，Release 一运行就崩，没有任何堆栈。这是典型的未定义行为被优化器暴露，翻牌项目里高发的是悬空指针——卡牌被removeItem之后仍留在某个队列里，或者定时器回调里访问了已销毁的 item。解决：debug 构建带符号先复现，或者在 release 里也打开QMAKE_CXXFLAGS_RELEASE += -g保留调试符号；同时检查所有QTimer::singleShot和 lambda 捕获，捕获裸指针的地方一律改成捕获 QPointer，对象没了自动置空。

5.2 逻辑与体验层面的两个隐蔽问题

现象四：手速快的时候，翻牌判定会错乱，出现三张同图只消一对。原因就是第 3.2 节说的锁没加或者加晚了，m_locked在追加队列之后才设置，中间存在一个极短的可重入窗口。解决：把m_locked = true移到m_pending.append(card)之前，或者干脆在点击入口最前面判m_pending.size() >= 2就直接返回，双保险。这类并发式点击问题在真机上比在开发机上更容易复现，因为开发时开着调试器点了会慢一拍，玄学得很。

现象五：切关卡之后，新关卡的计时从上一关的秒数接着走。原因是startLevel复用了同一个 QTimer 实例，resetBoard()里没有stop()。解决：重置流程里加if (m_timer) m_timer->stop();，并且把m_elapsed和m_moves一并归零再发信号。重开、切关、返回菜单三条路径都要走同一个 reset 函数，别图省事各写一遍，血泪经验是各写一遍必然漏一处。

6. 二次开发：把翻金币改成能拿得出手的小作品

6.1 一个改动最小、效果最明显的方向

如果只允许改一处，我会选「把静态资源换成可配置的主题包」。现在的正面图案写死在:/faces/%1.png，把它抽成配置项之后，换皮就变成了换目录：

// carditem.cpp —— 图案路径从外部注入，而不是硬编码 void CardItem::setFaceSource(const QString &pattern) { // pattern 形如 ":/themes/fruit/%1.png"，%1 由 faceId 填充 m_facePattern = pattern; update(); // 立即重绘，正面已经翻开的话会即时反映新图案 } // gameboard.cpp —— 铺牌前统一设置，主题由关卡配置带进来 const QString pattern = m_config.themePattern.isEmpty() ? QStringLiteral(":/faces/%1.png") : m_config.themePattern; // ... 在创建 card 之后调用 card->setFaceSource(pattern);

这段改完，配合 qrc 里多挂几套图，你就有了一套能换主题的翻牌游戏；再做一层「通关解锁下一套主题」的逻辑，一个完整的小闭环就成立了。验证方式很直接：改 JSON 里的 themePattern、重新编译、跑一局，看正面图案是否整体切换，顺便确认 qrc 里新加的目录确实被RESOURCES收录——资源没加进 .qrc 是最常见的「代码对但图不显示」。

我自己的习惯是每次动完这类资源路径相关的代码，都强制走一遍「release 构建 + 拷到干净目录 + 断网运行」，因为开发机上总有些环境因素在替你兜底，一旦打包出去就原形毕露。这个流程看着笨，但它替我省下的排查时间远比敲这几行命令多。希望帮到你。

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