连连看小程序核心算法拆解：棋盘生成、连通判定与消除逻辑

简介：一份基于 C# 开发的连连看休闲小游戏完整源码，面向初学 C# 与游戏编程的开发者，用于理解图形匹配消除类项目的整体实现，适合作为自学练手、课程设计或毕设参考。资源共 42 个文件，压缩包约 4.57MB，包含工程链接与项目配置（sln/vcproj/dsp/rc）、工程源码与头文件（cpp/h），以及位图、图标、音频、CHM 帮助文档等辅助资源，目录层次完整，便于按模块定位和对照学习。核心模块涵盖面向对象设计、Windows 窗口界面搭建、点击事件处理、消除匹配判定、计时与动画控制、异常与资源管理，可结合描述中的搜索算法思路理解常见游戏逻辑。已有 759 人学习/浏览，适合入门者通过查看源码、运行可执行文件，观察关卡状态切换与玩家反馈循环，从而掌握从工程组织、逻辑拆分到界面交互的小游戏开发全流程。

1. 连连看小程序：为什么消除逻辑比界面更值得拆开看

某开发者偶然拿到一份“连连看小程序游戏源码”，本来以为换套图标、调调配色就能交差，打开页面逻辑才发现真正花时间的是三件事：棋盘随机生成、两点之间是否连通、以及死局之后的重排。把这三件事做扎实，连连看其实就完成了一大半。这份源码是小程序原生页面加一套纯 JavaScript 实现的棋盘算法，不依赖游戏引擎，适合刚入门小程序又想接触一点算法的新手拿来跑通全流程，也适合想快速做一款带关卡、道具、计分排行的休闲游戏的人直接在上面改。

2. 工程结构两件事：页面骨架与算法模块的分工

2.1 目录结构与职责边界

先看这份源码的目录，整体是一个很标准的小程序工程分层：

├── app.js ├── app.json ├── app.wxss ├── pages │ └── game │ ├── game.js │ ├── game.json │ ├── game.wxml │ └── game.wxss ├── utils │ ├── board.js # 棋盘初始化、洗牌、重排 │ ├── link.js # 连通性判定、路径检测 │ └── level.js # 关卡参数配置 └── assets ├── icons # 各类型图标 └── sounds # 消除/点击音效

职责边界分得很清楚：pages/game只负责页面渲染、用户点击事件和状态管理；utils/board.js负责棋盘的生成、打乱和死局检测；utils/link.js只做一件事——判断两个格子之间是否存在合法消除路径。页面里不写算法，算法文件里不碰Page实例，这样后续做单元测试或在 Node 环境里单独跑算法验证都非常方便。

这种分离带来的直接好处是：想调消除难度，不需要动 UI 代码；想在网页端复刻同一套逻辑，直接把这几个工具文件拷贝过去就能用。小程序端和 Web 端最大的差别只是渲染层，棋盘逻辑是完全通用的。

2.2 页面骨架：WXML 的网格渲染与点击事件绑定

页面部分用小程序原生的view组件渲染一个二维网格。棋盘数据放在data.board里，是一个二维数组，外层循环渲染行，内层循环渲染每一格。

<view class="board" wx:if="{{board.length}}"> <view class="row" wx:for="{{board}}" wx:for-item="rowData" wx:key="index"> <view class="cell {{cell === 0 ? 'empty' : ''}} {{selected && selected.row === rowIndex && selected.col === colIndex ? 'selected' : ''}}" wx:for="{{rowData}}" wx:for-item="cell" wx:for-index="colIndex" >function createBoard(rows, cols, types) { // 外层加一圈 0 作为边界，实际可玩区域是 1 ~ rows, 1 ~ cols const board = Array.from({ length: rows + 2 }, () => new Array(cols + 2).fill(0) ); const cellCount = rows * cols; const ids = []; // 每种图标按对填入，保证总数为偶数 for (let i = 0; i < cellCount / 2; i++) { const type = (i % types) + 1; ids.push(type, type); } shuffle(ids); let idx = 0; for (let r = 1; r <= rows; r++) { for (let c = 1; c <= cols; c++) { board[r][c] = ids[idx++]; } } // 生成后必须保证至少存在一对可消除的格子，否则重新生成 if (!hasAnyMove(board)) { return createBoard(rows, cols, types); } return board; }

这里要注意rows * cols必须是偶数，否则无法保证所有图标成对出现。shuffle用的是经典的 Fisher-Yates 洗牌，从数组尾部往前遍历，每次随机交换一个位置，保证每个排列出现的概率均等。

生成之后立刻做一次hasAnyMove校验，这是很关键的一步。如果不校验，可能出现一个开局就无解的局面，玩家还没开始玩就卡死。递归重新生成是一种简单粗暴但有效的兜底策略，实际项目中可以加一个最大重试次数上限，防止极端情况下无限递归。

3.2 连通性判定：直线、一次拐弯、两次拐弯

这是整个连连看最核心的算法。两个格子能够消除，需要满足两个前提：图标类型相同；两点之间能找到一条路径，路径最多拐两个弯，且路径上的格子全部为空。

先实现最基础的直线段检查，这个函数会被上层反复调用：

function isStraightClear(board, p1, p2) { // 判断 p1 到 p2 之间的直线路径是否全部为空，不包含 p1 和 p2 本身 if (p1.row === p2.row) { const minCol = Math.min(p1.col, p2.col); const maxCol = Math.max(p1.col, p2.col); for (let c = minCol + 1; c < maxCol; c++) { if (board[p1.row][c] !== 0) return false; } return true; } if (p1.col === p2.col) { const minRow = Math.min(p1.row, p2.row); const maxRow = Math.max(p1.row, p2.row); for (let r = minRow + 1; r < maxRow; r++) { if (board[r][p1.col] !== 0) return false; } return true; } return false; }

接着写一次拐弯的判定。一次拐弯的路径可以看作经过一个拐点 C，C 的两个候选位置分别是(a.row, b.col)和(b.row, a.col)。拐点本身必须是空格，并且从起点到拐点、拐点到终点这两段直线都要通畅。

function isOneCorner(board, a, b) { const c1 = { row: a.row, col: b.col }; const c2 = { row: b.row, col: a.col }; if (board[c1.row][c1.col] === 0) { if (isStraightClear(board, a, c1) && isStraightClear(board, c1, b)) { return true; } } if (board[c2.row][c2.col] === 0) { if (isStraightClear(board, a, c2) && isStraightClear(board, c2, b)) { return true; } } return false; }

最后是两次拐弯。常见的做法是枚举法：假设路径形如「横-竖-横」或「竖-横-竖」，枚举中间那条连线所在的行或列，检查三段路径是否全部通畅。

function isTwoCorner(board, a, b) { const totalRows = board.length; const totalCols = board[0].length; // 水平方向的两次拐弯：a -> 同列某行 -> 同列b所在行 -> b for (let r = 0; r < totalRows; r++) { const midA = { row: r, col: a.col }; const midB = { row: r, col: b.col }; if (board[midA.row][midA.col] === 0 && board[midB.row][midB.col] === 0) { if ( isStraightClear(board, a, midA) && isStraightClear(board, midA, midB) && isStraightClear(board, midB, b) ) { return true; } } } // 垂直方向的两次拐弯：a -> 同行某列 -> 同行b所在列 -> b for (let c = 0; c < totalCols; c++) { const midA = { row: a.row, col: c }; const midB = { row: b.row, col: c }; if (board[midA.row][midA.col] === 0 && board[midB.row][midB.col] === 0) { if ( isStraightClear(board, a, midA) && isStraightClear(board, midA, midB) && isStraightClear(board, midB, b) ) { return true; } } } return false; }

把三个判定串起来就是对外主函数：

function isLinkable(board, a, b) { const typeA = board[a.row][a.col]; const typeB = board[b.row][b.col]; if (!typeA || !typeB || typeA !== typeB) return false; if (a.row === b.row && a.col === b.col) return false; if (isStraightClear(board, a, b)) return true; if (isOneCorner(board, a, b)) return true; if (isTwoCorner(board, a, b)) return true; return false; }

这段逻辑里有个容易误判的细节：isStraightClear只判断路径上的格子是否为空，不判断两端类型。所以主函数里必须先做「类型相同且非 0」的检查，再去做路径判定，否则isOneCorner里把起点或终点当拐点传入时会出现误判。

3.3 死局检测与重排兜底

死局检测的思路很简单：遍历棋盘上所有非空格子，任意两两配对，只要出现一对满足「类型相同且路径连通」，就说明当前局面还有解。一旦找不到任何一对，就判定为死局。

function hasAnyMove(board) { const cells = []; for (let r = 0; r < board.length; r++) { for (let c = 0; c < board[r].length; c++) { if (board[r][c] !== 0) { cells.push({ row: r, col: c }); } } } for (let i = 0; i < cells.length; i++) { for (let j = i + 1; j < cells.length; j++) { const a = cells[i]; const b = cells[j]; if ( board[a.row][a.col] === board[b.row][b.col] && isLinkable(board, a, b) ) { return true; } } } return false; }

这个函数的复杂度是 O(n²)，一个 8×8 的棋盘最多 64 个非空格子，两两配对大约两千组，每组做一次路径检测，在开发者工具上耗时在毫秒级，完全够用。但如果把棋盘扩大到 15×15，配对数量会涨到上万组，这个函数就会成为性能瓶颈。常见优化是先按图标类型分组，不同类型之间不存在消除可能，配对时只扫描同类型组内。这份源码在常规尺寸下没有做这个优化，性能和可读性之间的取舍是对的。

重排函数则把所有非空格子的类型值收集起来洗牌，再重新填回去：

function reshuffle(board, maxAttempts = 10) { const cells = []; for (let r = 0; r < board.length; r++) { for (let c = 0; c < board[r].length; c++) { if (board[r][c] !== 0) { cells.push({ row: r, col: c, type: board[r][c] }); } } } for (let attempt = 0; attempt < maxAttempts; attempt++) { const types = cells.map((item) => item.type); shuffle(types); for (let i = 0; i < cells.length; i++) { board[cells[i].row][cells[i].col] = types[i]; } if (hasAnyMove(board)) { return board; } } // 重试多次仍然无解，退回重新生成整盘 return createBoard(8, 8, 6); }

maxAttempts这个参数很重要。如果不加限制，hasAnyMove返回false后就一直洗牌递归，极端布局可能出现比较深的递归层数，虽然不至于崩掉，但会让调试变的棘手。设置一个上限，洗牌洗不出来就直接重新生成一整盘，逻辑更干脆。

3.4 开局参数与用户可调配置

创建棋盘的参数落在utils/level.js里：

const levels = { easy: { rows: 6, cols: 6, types: 4, timeLimit: 120 }, normal: { rows: 8, cols: 8, types: 6, timeLimit: 180 }, hard: { rows: 10, cols: 10, types: 8, timeLimit: 240 }, }; function getLevelById(id) { return levels[id] || levels.normal; }

types的数量和rows * cols / 2的关系决定难度：图标种类越少，相同图标越多，匹配越容易，同时死局概率也越高。一个需要特别留意的比例关系是，当types接近rows * cols / 2时，每种图标只出现两次，连通的路径选择极少，几乎每隔几步就要触发重排，玩家体验会非常差。在实际调参数时，建议控制rows * cols / 2不小于types * 3。

4. 交互与状态管理：从点击到消除的完整链路

4.1 点击流程与选中态控制

页面的核心交互是：第一次点击选中一个格子，第二次点击执行判定。判定结果分三种：同一格子则取消选中；图标不同或路径不通则提示并清空选中态；满足消除条件则执行消除。

Page({ data: { board: [], score: 0, remainPairs: 0, time: 0, selected: null, status: 'playing', // playing | paused | finished }, onTileTap(event) { if (this.data.status !== 'playing') return; const { row, col } = event.currentTarget.dataset; const { board, selected } = this.data; const type = board[row][col]; // 点击空格直接忽略 if (type === 0) return; // 还没有选中任何格子，记下当前选中位置 if (!selected) { this.setData({ selected: { row, col } }); return; } // 点击同一个格子，取消选中 if (selected.row === row && selected.col === col) { this.setData({ selected: null }); return; } // 类型不一致，提示并取消选中 if (board[selected.row][selected.col] !== type) { this.showToast('图标不一致'); this.setData({ selected: null }); return; } // 核心判定：路径是否连通 if (!isLinkable(board, selected, { row, col })) { this.showToast('路径不通'); this.setData({ selected: null }); return; } this.eliminatePair(selected, { row, col }); }, });

这里有个容易被忽略的设计决策：每次点击都通过event.currentTarget.dataset拿坐标，而不是在bindtap里传索引值。dataset拿到的数据一定是字符串，所以row和col在比较时要注意类型统一——源码里比较用的是selected.row === row，row经过数字比较没问题，但如果你在dataset里拼了字符串，记得用parseInt转换，否则会得到"1" !== 1的诡异结果。

4.2 消除动作与数据更新

消除操作要遵守小程序setData的原则：不能直接修改this.data.board里的嵌套元素再赋值，应该先复制一份数组，修改副本，再整体 setData。

eliminatePair(a, b) { const board = this.data.board.map((row) => row.slice()); board[a.row][a.col] = 0; board[b.row][b.col] = 0; this.setData({ board, selected: null, remainPairs: this.data.remainPairs - 1, score: this.data.score + 10, }); // 消除动画结束后再判断是否通关 this.playEliminateAnimation(a, b); if (this.data.remainPairs <= 0) { this.finishGame(); } }

map(row => row.slice())是二维数组拷贝的最小可靠方案，浅拷贝一维数组还不够，因为内层数组是引用类型，直接改内层元素会污染原来的data.board。

消除动画的实现上，常见做法是给被消除的格子加一个缩小和淡出的 CSS 类，动画时长 200ms 左右，动画结束后再把格子置空。如果动画和置空同时做，玩家会看到半透明残影，视觉上像「消除了一块但另一块还留着」，这也是很多初版连连看给人不流畅感的原因。

4.3 计时、暂停与恢复

计时逻辑用setInterval每秒更新一次，这里最关键的是生命周期配对：在onHide里清掉定时器，在onShow里恢复计时。否则玩家切到后台再回来，时间已经偷偷清零。

onShow() { if (this.data.status !== 'playing') return; this.timer = setInterval(() => { const nextTime = this.data.time - 1; if (nextTime <= 0) { this.timeoutGame(); return; } this.setData({ time: nextTime }); }, 1000); }, onHide() { if (this.timer) { clearInterval(this.timer); this.timer = null; } },

需要注意onShow里先判断status，这一步不能省。如果玩家已经通关或者超时，回到页面后不应该再恢复计时。timeoutGame里要把status改为finished，这样才能保证后续点击不会穿透到底层棋盘。

计分规则可以做得更细：基础分按消除次数给分，连击、剩余时间加成放在二次开发时扩展。源码里这套现成的流程本身是单机模式，单机模式下分数存本地即可，不需要走网络请求，也省去了域名配置的麻烦。

4.4 轻量反馈：音效与震动

音效部分源码里用了非常轻量的方案：点击和消除各播放一个短音效，音频文件放在assets/sounds下。小程序播放音效的标准做法是创建一个InnerAudioContext实例，在页面加载时初始化，事件触发时调用play()。

onLoad() { this.clickSound = createAudio('/assets/sounds/click.mp3'); this.eliminateSound = createAudio('/assets/sounds/eliminate.mp3'); },

音效的开关建议做成一个全局配置，存到本地存储里。这个小细节能直接决定玩家能不能在安静环境下用你的游戏，也确实是在二开时经常被遗忘的点。

5. 避坑记录：开发者工具、真机与长时间对局下的翻车点

5.1 消除后格子残留，棋盘上留下「消不掉的块」

现象：点击两个可消除格子后，路径检查已通过，但界面上其中一个格子仍然显示图标。

原因：最常见的是在eliminatePair里用this.data.board[a.row][a.col] = 0直接改了原数组，没有调用setData。小程序里修改this.data并不会同步触发视图更新，视图层拿到的还是旧数据。还有一种可能是board数组的拷贝只做了一维slice()，内层数组仍是同一份引用，修改时污染了上一次渲染的数据。

解决：每次消除都map(row => row.slice())做深拷贝，改完整个副本后一次性setData({ board })。如果对性能有要求，可以只更新被修改的两个格子对应的行，但要注意行索引不变时小程序可能不会刷新该行，这种情况下把改动行换成新数组也能触发更新。

5.2 分数已经加了，界面上的分数纹丝不动

现象：控制台打印this.data.score已经是 110，但页面显示还停在 100。

原因：在普通变量上执行this.data.score += 10，虽然this.data里的值变了，但没有走setData，视图层没有收到更新指令。

解决：所有会影响界面的数据变更，统一走this.setData。顺手把「分数只在消除成功时才更新」的逻辑也确立下来：路径不通的点击不扣分不涨分，避免玩家用快速乱点刷分。

5.3 图标在开发者工具里正常，真机上一片空白

现象：本地调试所有图标显示正常，预览到手机上有部分格子显示为空白方块或加载失败的占位图。

原因：资源路径大小写不一致，或者引用了开发者工具本地的临时文件路径。手机上没有开发者工具的本地文件映射，所以路径写到本地临时目录的资源全部加载失败。

解决：所有图片统一放到项目内的assets/icons目录，引用路径从根目录写起，如/assets/icons/type-1.png。命名规范为全小写，避免Type-1.png和type-1.png在 Mac 和 Linux 上表现不一致导致的线上事故。如果是网络图片资源，则必须在小程序后台配置 downloadFile 合法域名，否则真机一定会拦截。

5.4 重排之后依然无解，玩家卡死在当前局面

现象：点击「刷新」道具后，界面上的格子位置变了，但随后几步发现整个棋盘没有任何可消除的对子。

原因：重排函数只把类型值打乱重新填入，没有在填入后执行hasAnyMove校验。当棋盘接近尾声、空格很多时，随机洗牌有相当大概率洗出无解排列。

解决：重排完成后必须调用hasAnyMove，无解则继续洗牌，并设置最大尝试次数。超过次数就放弃洗牌，直接生成新棋盘，宁可让玩家重新开始，也不能让玩家面对一个没有出口的局面。

5.5 页面切后台再回来，倒计时直接归零

现象：玩家把小程序切到后台去回消息，回来发现游戏已经超时，或者时间少了远超过实际离开的时长。

原因：setInterval在页面进入后台时没有被清理。小程序页面切到后台后定时器并不会自动暂停，而是继续执行，可能因为系统调度产生积压，恢复前台后一次性补执行多次回调。

解决：在onHide里clearInterval，在onShow里重新启动计时器，同时记录暂停时的时间差。更稳的方式是使用时间戳记录开始时间，每次onShow时用当前时间减去开始时间计算剩余时间，而不是依赖定时器的累积次数。

6. 二次开发：加关卡配置、刷新道具，和一套自检清单

6.1 把棋盘参数全部抽成关卡配置

utils/level.js已经定义了三个难度档位，但切关卡时页面里如果写死了createBoard(8, 8, 6)，配置就形同虚设。改造思路是给Page加一个levelId字段，在onLoad里从options读取，再传给createBoard：

onLoad(options) { const levelId = options.level || 'normal'; const level = getLevelById(levelId); this.setData({ board: createBoard(level.rows, level.cols, level.types), remainPairs: (level.rows * level.cols) / 2, time: level.timeLimit, levelId, }); this.startTimer(); }

这样新增关卡只需要往levels对象里加一项，不需要碰页面代码。

6.2 加一个「刷新」道具

道具系统的接入方式是在data里维护一个tools对象，在点击道具时调用对应的工具函数。刷新道具的核心逻辑就是调用前面实现的reshuffle：

useRefreshTool() { if (this.data.tools.refresh <= 0) return; const board = this.data.board.map((row) => row.slice()); reshuffle(board); this.setData({ board, tools: { ...this.data.tools, refresh: this.data.tools.refresh - 1, }, }); }

加「炸弹」道具也很简单：遍历棋盘找出一组isLinkable为 true 的对子，直接置空这两个格子。区别是刷新不改剩余对数，炸弹会减少剩余对数，同时要增加对应分数。道具数量建议用本地存储持久化，避免玩家重进游戏后道具清零，导致付费道具功能失去意义。

6.3 每次改完必过的验证清单

代码改完先别急着发布，按这个清单在开发者工具和真机上各过一遍：

• 开局可解性：进入游戏后连续消除，看是否在接近尾声时出现无解局面。
• 边界点击：棋盘四个角、空位、已经被消除的格子，点击后无报错。
• 暂停恢复：切后台 30 秒再回前台，时间是否只减少了实际离开的时长。
• 道具逻辑：把道具数量改成 0 再点道具按钮，确认不会出现负数或报错。
• 连续快速点击：两个手速很快地连点不同格子，确认选中态不会错乱。
• 低端真机表现：在低端机上连续消除 30 对，观察setData是否导致明显卡顿。

其中开局可解性这一条最容易踩坑，因为棋盘生成用了递归重试，如果新关卡尺寸变大后没有设置递归上限，极端情况下会导致页面卡死。建议在createBoard里也加一个最大重试次数。

我从这个项目里学到最深刻的一点，是「改之前先想清楚数据在哪里改变」。好几次都是图省事直接改了this.data里的嵌套数组，结果渲染出现诡异残留，排查了半天才发现是浅拷贝的问题。从那以后，我每次改完都会强制自己在开发者工具里跑一遍自动消除脚本，再上真机验证一遍暂停恢复；这些不酷的检查，反而帮我挡住了大多数上线前的低级事故。希望帮到你。

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