从零开发连连看小游戏：技术路线、心得与优化思考

作者：Eddygit
日期：2026-10-08
项目：连连看 Lianliankan

前言

连连看是一款家喻户晓的消除类益智游戏。规则看似简单——找出相同图案的方块对，用不超过2个拐点的折线连接即可消除——但背后涉及的寻路算法、状态管理和用户体验设计却很有讲究。本文分享我用纯 HTML/CSS/JavaScript 从零开发这款小游戏的全过程，包括技术路线选择、核心算法实现、踩过的坑以及未来的优化方向。

一、技术路线

1.1 为什么选择纯前端单文件架构？

面对"做个连连看"这个需求，技术选型有三个方向：

对于连连看这种小型游戏，单文件方案的优势非常明显：一个 index.html 搞定一切，不需要 npm、webpack、vite，任何人拿到文件双击就能玩。这种"零门槛"体验在分享场景下尤为重要。

1.2 技术栈详情

• HTML5：语义化标签 + Canvas 元素（路径绘制）
• CSS3：Flexbox 布局、linear-gradient 渐变背景、transition/transform 动画、@keyframes 关键帧
• JavaScript (ES6)：const/let、箭头函数、模板字符串、解构赋值、Array.from
• Canvas 2D API：路径绘制、阴影效果

1.3 DOM + Canvas 混合渲染

这是一个关键设计决策：

• 方块用 DOM 元素（<div>）：天然支持 click 事件、hover 效果、CSS 动画，开发效率高
• 连接路径用 Canvas：线条绘制是 Canvas 的强项，带阴影的曲线效果用 CSS 很难实现

两者通过绝对定位重叠在游戏板区域内，各司其职。这种"DOM 管交互，Canvas 管特效"的混合模式在小游戏中非常实用。

二、核心算法：分类枚举寻路

2.1 问题定义

给定一个 R×C 的网格，每个格子要么为空（0），要么有图案（1~N）。判断两个非空格子 A(r1,c1) 和 B(r2,c2) 之间是否存在一条路径，满足：

1. 路径只经过空格子（起点和终点除外）
2. 路径的拐点数不超过 2

2.2 网格设计：带边界空白

0 0 0 0 0 0 0 0   ← 空白边界行
0 1 2 3 1 2 3 0
0 3 2 1 3 2 1 0
0 1 1 2 3 2 3 0
0 0 0 0 0 0 0 0   ← 空白边界行

在实际棋盘外围添加一圈空白格子，是连连看开发中的经典技巧。它解决了两个问题：

1. 路径可以绕过棋盘边缘——这在连连看中是合法的
2. 避免边界条件判断——不需要写 if (r < 0 || r >= rows) 之类的检查

2.3 三种情况枚举

0拐点（直线连接）：

function canConnectStraight(r1, c1, r2, c2) {
  if (r1 === r2) {  // 同行
    const [minC, maxC] = c1 < c2 ? [c1, c2] : [c2, c1];
    for (let c = minC + 1; c < maxC; c++) if (grid[r1][c] !== 0) return false;
    return true;
  }
  if (c1 === c2) {  // 同列
    // ...类似逻辑
  }
  return false;
}

1拐点（L形连接）：只有两个候选拐点——(r1,c2) 和 (r2,c1)。检查拐点位置为空，且拐点到两端都是直线可达即可。

2拐点（U形/Z形连接）：遍历所有中间行或中间列，检查是否存在一条经过两个拐点的可行路径。这是最耗时的情况，时间复杂度 O(R×C)。

2.4 算法复杂度分析

对于 10×12 的困难模式，最坏情况约 10×12×12 = 1440 次格子访问，完全在毫秒级内。

三、技术心得

3.1 状态管理的简洁之道

没有引入 Redux、Vuex 等状态管理库，而是用几个全局变量：

let grid = [];       // 棋盘数据
let selected = null; // 当前选中的方块
let score = 0;       // 得分
let remaining = 0;   // 剩余方块数

对于这种规模的游戏，全局变量 + 函数调用的方式足够清晰。过度工程化反而增加理解成本。

3.2 动画策略

方块消除动画用 CSS transition 实现，而非 JavaScript 动画循环：

.tile.removed { opacity: 0; transform: scale(0); }

添加 removed class 即可触发动画，浏览器自动处理过渡，性能远好于 JS 逐帧修改。

3.3 无解检测的重要性

这是开发中容易忽略的问题。随机布局的连连看在消除过程中可能出现死局——所有剩余方块都无法连接。如果不处理，玩家会陷入"怎么点都没反应"的困惑。

解决方案是每次消除后检查 hasAnyMatch()，若无解则自动洗牌。洗牌后还要验证有解性，最多重试10次。

3.4 响应式设计

const maxW = Math.min(window.innerWidth - 40, 720);
tileSize = Math.floor((maxW - padding * 2 - gap * (cols - 1)) / cols);
tileSize = Math.max(32, Math.min(tileSize, 60));

根据窗口宽度动态计算方块大小，设定 32~60px 的范围，兼顾小屏可用性和大屏美观性。

四、实战经验

4.1 Canvas 坐标对齐

Canvas 和 DOM 元素的位置必须精确对齐。由于 Canvas 的 top/left 需要加上 padding 偏移，而路径坐标基于格子中心计算，初版曾出现路径偏移的 bug。解决方法：

const x = (path[i].c - 1) * (tileSize + gap) + tileSize / 2;
const y = (path[i].r - 1) * (tileSize + gap) + tileSize / 2;

注意格子坐标从1开始（因为有边界行），所以是 c - 1。

4.2 消除时序控制

点击第二个方块后，流程是：绘制路径 → 等待300ms → 消除方块 → 清除路径。用 setTimeout 控制时序，让玩家看到连接路径后再消除，视觉反馈更清晰。

4.3 难度平衡

三档难度的参数设计经过权衡：

• 简单：6×8=48格，8种图案，5次提示——让新手快速上手
• 中等：8×10=80格，12种图案，3次提示——平衡挑战和乐趣
• 困难：10×12=120格，16种图案，2次提示——考验眼力和策略

图案种类太少会导致初始无解概率高，太多则难以找到匹配。8~16 种是经验上的较好范围。

五、存在问题

5.1 hasAnyMatch 性能瓶颈

当前的无解检测对所有方块对做 O(n²) 遍历：

for (let i = 0; i < tiles.length; i++)
  for (let j = i + 1; j < tiles.length; j++)
    if (tiles[i].t === tiles[j].t && findPath(...))
      return true;

困难模式下 120 个方块，最坏情况 7140 次 findPath 调用。虽然单次很快，但每次消除后都检测，累积起来可能有感知延迟。

5.2 洗牌可能改变游戏状态

自动洗牌会打乱方块位置，玩家之前观察的记忆全部失效，可能影响游戏体验。更好的做法是在洗牌前给出提示，让玩家有心理准备。

5.3 移动端触摸精度

小屏幕上方块尺寸可能只有 32px，手指点击容易误触相邻方块。未做触摸区域扩展和手势支持。

六、优化空间

6.1 算法优化

可以按图案类型分组，只检查相同图案的方块对，减少无效遍历：

const groups = {};  // { type: [{r,c}, ...] }
for (const tile of tiles) {
  (groups[tile.t] ||= []).push(tile);
}
for (const type in groups) {
  const same = groups[type];
  for (let i = 0; i < same.length; i++)
    for (let j = i + 1; j < same.length; j++)
      if (findPath(...)) return true;
}

6.2 游戏体验增强

• 连击系统：快速连续消除给予额外得分和视觉特效
• 粒子效果：方块消除时迸发粒子，增强反馈感
• 音效：消除、选中、错误等操作的音效反馈
• 关卡模式：预设布局，固定挑战

6.3 PWA 改造

添加 manifest.json 和 Service Worker，支持离线游玩和安装到桌面：

{
  "name": "连连看",
  "short_name": "Lianliankan",
  "start_url": "./index.html",
  "display": "standalone"
}

6.4 代码工程化

如果项目继续扩展，可以考虑：

• 拆分 CSS 和 JS 为独立文件
• 引入 ESLint + Prettier 规范代码
• 使用 TypeScript 增强类型安全
• 添加单元测试（特别是寻路算法）

七、总结

开发连连看的过程是一次很好的算法实践和工程权衡的练习。核心收获：

1. 简单问题也有深度：连连看规则一句话能说清，但寻路算法、无解检测、用户体验都需要认真设计
2. 合适的技术选型比先进更重要：纯单文件方案在这个场景下完胜 React+Webpack
3. 算法要和场景匹配：分类枚举法不是最优算法，但它的逻辑清晰、实现简单、性能够用，就是最合适的选择
4. 用户体验细节决定成败：无解检测、路径动画、提示功能这些"锦上添花"的东西，恰恰是让游戏可玩的关键

希望这篇分享对同样想开发小游戏的开发者有所启发。完整代码已开源在 GitCode 仓库，欢迎交流。

本文为原创内容，转载请注明出处。