企业官网建设流程全解析

1. 为什么H5小游戏至今仍是前端练手的最佳载体

2019年到2020年那会儿，H5小游戏迎来了一波集中爆发。当时各大平台都在推即点即玩的小游戏入口，开发者社区里也涌现出大量开源的小游戏合集。我手头这个项目就是那个时期沉淀下来的——一个收录了280多款H5小游戏的源码仓库，涵盖从最基础的打砖块、贪吃蛇，到稍复杂一些的跑酷、消除、塔防类玩法。

先说清楚这个项目是什么。它本质上是一个H5小游戏源码合集，每款游戏都是独立的HTML+CSS+JavaScript实现，不依赖复杂的构建工具，浏览器打开就能跑。能做什么？你可以用它来学Canvas渲染、学游戏循环、学碰撞检测、学状态管理，甚至学怎么用最朴素的代码写出流畅的交互。解决了什么问题？解决了很多前端开发者“想练手但不知道做什么”的困境——与其反复写TodoList和后台管理系统，不如拿一个完整的游戏源码来拆解，因为游戏对性能、逻辑、交互的要求比普通页面高得多。

适合谁来参考？刚入门前端、学过基础语法但缺乏项目经验的同学；想补一补Canvas和动画知识的中级开发者；以及想快速找一些轻量级小游戏嵌入自己项目的工程师。哪怕你只完整吃透其中五六个游戏的源码，对JavaScript的理解都会上一个台阶。

我自己的体会是，H5小游戏是前端领域里少有的能把数据结构、算法、渲染、交互、性能优化串在一起的教学场景。一个贪吃蛇就涉及队列操作、碰撞检测、定时器控制；一个打砖块就涉及向量反弹、矩形碰撞、多物体管理。这些东西在业务代码里很难集中练到，但在游戏里全是核心。

2. 280多款游戏源码的整体架构与分类思路

2.1 仓库目录结构与组织方式

拿到这个合集的第一件事，不是急着打开某个游戏玩，而是先看目录怎么组织的。280多款游戏如果平铺在一个文件夹里，找起来会非常痛苦。常见的组织方式有两种：按游戏类型分目录，或者按技术难度分目录。这个合集采用的是混合分类——先按类型分大类，大类下面再按实现复杂度排。

典型的目录结构大概长这样：

games/ ├── arcade/ # 街机类：打砖块、弹球、太空射击 ├── puzzle/ # 益智类：消除、数独、推箱子 ├── action/ # 动作类：跑酷、跳跃、躲避 ├── casual/ # 休闲类：贪吃蛇、Flappy、接球 ├── card/ # 棋牌类：记忆翻牌、接龙 ├── assets/ # 公共素材：音效、字体、通用工具函数 └── index.html # 合集入口页

每个游戏目录内部通常包含：index.html（入口）、game.js（核心逻辑）、style.css（样式）、assets/（该游戏专属素材）。有些做得规范的还会带一个README.md说明操作方式和实现要点。

注意：不要一上来就逐个打开玩。先花半小时把目录结构摸清楚，挑出你感兴趣的类型，再深入。280多个游戏全看一遍不现实，也没必要。

2.2 按技术难度分层的学习路径

我把这280多款游戏按实现难度大致分成四层，这个分层不是官方给的，是我自己拆解后总结的，方便你规划学习顺序：

这个分层的逻辑是：每一层只引入一到两个新的核心概念。入门级只需要理解“怎么在Canvas上画东西”和“怎么让东西动起来”；进阶级开始引入重力和速度的概念；高级要处理多个系统之间的协调；挑战级则涉及架构设计。

2.3 为什么这些游戏大多不用框架

你翻一遍源码会发现，这280多款游戏里，绝大多数是纯原生JavaScript写的，没有用React、Vue，甚至连jQuery都很少见。这不是因为作者不会框架，而是刻意为之。

原因有三。第一，游戏的核心是Canvas渲染和游戏循环，框架擅长的是DOM操作和状态绑定，两者关注点不同。第二，用原生写能让你看清每一行代码在干什么，没有框架的抽象层遮挡。第三，这些游戏体量小，引入框架反而增加复杂度。

当然也有少数用了一些轻量库，比如用howler.js处理音效，用matter.js做物理模拟。但核心逻辑依然是手写的。我的建议是：先看纯原生的版本，理解原理后，再去看用了库的版本，对比差异。

3. 核心游戏循环与渲染机制拆解

3.1 游戏循环：所有游戏的发动机

不管什么类型的H5游戏，底层都有一个游戏循环（Game Loop）。这是整个游戏的心脏，负责每一帧更新状态、渲染画面。理解游戏循环，等于拿到了读懂所有游戏源码的钥匙。

最朴素的游戏循环用requestAnimationFrame实现：

function gameLoop(timestamp) { // 1. 计算时间差 const deltaTime = timestamp - lastTime; lastTime = timestamp; // 2. 更新游戏状态 update(deltaTime); // 3. 渲染画面 render(); // 4. 请求下一帧 requestAnimationFrame(gameLoop); } let lastTime = 0; requestAnimationFrame(gameLoop);

这三步——update、render、requestAnimationFrame——是所有游戏循环的基本骨架。区别只在于update里做什么、render里画什么。

为什么用requestAnimationFrame而不是setInterval？因为前者会跟随浏览器的刷新率，通常是60帧每秒，而且在页面不可见时会自动暂停，省电省性能。setInterval则不管页面状态，固定时间间隔执行，容易造成卡顿和资源浪费。

实操心得：很多新手写游戏时用setInterval(fn, 16)来模拟60帧，结果在低性能设备上帧率不稳，游戏体验很差。换成requestAnimationFrame后，配合deltaTime计算，游戏速度就和帧率解耦了，快慢设备上表现一致。

3.2 deltaTime：让游戏速度与帧率无关

上面代码里的deltaTime是个关键概念。如果不处理它，游戏在60帧设备上跑得正常，在30帧设备上就会慢一倍。因为每一帧移动的距离是固定的，帧数少了，单位时间移动的距离就少了。

正确的做法是：速度乘以时间差。比如一个物体速度是每秒移动100像素，那么这一帧应该移动100 * (deltaTime / 1000)像素。这样不管帧率是60还是30，物体每秒移动的距离都是100像素。

function update(deltaTime) { const speed = 100; // 像素/秒 player.x += speed * (deltaTime / 1000); }

这个细节在280多款游戏里，做得规范的都会处理，做得粗糙的会直接写死每帧移动量。你拆解源码时可以留意这个区别，能帮你判断哪些源码质量更高、更值得学。

3.3 Canvas渲染的三种典型模式

翻完这些游戏，渲染方式大致分三类：

第一类：全量重绘。每一帧先用clearRect清空整个画布，再重新画所有元素。这是最常见的做法，简单直接，适合元素不多的游戏，比如贪吃蛇、打砖块。

第二类：局部重绘。只清空和重绘发生变化的区域，适合元素多、但每帧变化少的游戏，比如塔防。实现起来复杂一些，需要记录脏矩形。

第三类：分层Canvas。用多个Canvas叠在一起，背景层不动，只重绘前景层。适合有静态背景的游戏，比如跑酷。背景只需要画一次，前景每帧重绘。

// 分层Canvas的典型结构 <canvas id="bg"></canvas> <!-- 背景层，画一次 --> <canvas id="game"></canvas> <!-- 游戏层，每帧重绘 --> <canvas id="ui"></canvas> <!-- UI层，按需重绘 -->

注意：分层Canvas虽然性能好，但要注意层级顺序和事件穿透问题。上层Canvas如果不需要交互，记得设置pointer-events: none，否则会挡住下层的事件。

4. 从源码中提炼的六个核心模块实现

4.1 碰撞检测：游戏世界的物理规则

碰撞检测是游戏里出现频率最高的逻辑之一。280多款游戏里，碰撞检测的实现方式五花八门，但归根结底就几种。

矩形碰撞是最常用的，判断两个矩形是否重叠：

function isColliding(a, b) { return a.x < b.x + b.width && a.x + a.width > b.x && a.y < b.y + b.height && a.y + a.height > b.y; }

这个逻辑很直观：两个矩形不碰撞的情况只有四种——a在b左边、a在b右边、a在b上边、a在b下边。排除这四种，剩下的就是碰撞。

圆形碰撞用于球类游戏，判断两个圆心距离是否小于半径之和：

function isCircleColliding(a, b) { const dx = a.x - b.x; const dy = a.y - b.y; const distance = Math.sqrt(dx * dx + dy * dy); return distance < a.radius + b.radius; }

像素级碰撞最精确但最慢，用于需要高精度的场景，比如不规则图形的碰撞。实现方式是逐个像素比对，性能开销大，小游戏里很少用。

实操心得：很多新手做碰撞检测时，直接用物体的绘制坐标来判断，结果发现“明明看着没碰到就判定碰撞了”。原因是绘制坐标是左上角，而视觉中心在物体中间。解决办法是统一用中心点坐标，或者在做碰撞判断时把坐标转换成中心点。这个坑我在拆解打砖块源码时踩过，砖块和球的碰撞总是提前触发，后来发现是坐标系没对齐。

4.2 对象池：解决频繁创建销毁的性能问题

在射击类、跑酷类游戏里，子弹、障碍物会频繁生成和销毁。如果每次都new一个对象，再让它被垃圾回收，时间长了会造成内存抖动，游戏卡顿。对象池就是解决这个问题的。

思路很简单：预先创建一批对象，不用的时候标记为“空闲”，需要的时候从池子里取，用完还回去，而不是销毁。

class ObjectPool { constructor(factory, size) { this.pool = []; this.factory = factory; for (let i = 0; i < size; i++) { const obj = factory(); obj.active = false; this.pool.push(obj); } } get() { for (const obj of this.pool) { if (!obj.active) { obj.active = true; return obj; } } // 池子不够就扩容 const obj = this.factory(); obj.active = true; this.pool.push(obj); return obj; } release(obj) { obj.active = false; } }

这个模式在280多款游戏里，凡是涉及大量动态对象的，基本都会用到。你拆解源码时，看到active标记、pool数组这类命名，大概率就是对象池。

4.3 状态机：管理游戏的各种状态

稍微复杂一点的游戏都有多个状态：开始界面、游戏中、暂停、结束。如果不用状态机，代码里会充斥大量的if (gameState === 'playing')判断，难以维护。状态机把这些状态和对应的行为封装起来，逻辑清晰得多。

一个简单的状态机实现：

const State = { MENU: 'menu', PLAYING: 'playing', PAUSED: 'paused', GAME_OVER: 'gameover' }; class GameStateMachine { constructor() { this.state = State.MENU; this.handlers = {}; } on(state, handler) { this.handlers[state] = handler; } transition(newState) { this.state = newState; if (this.handlers[newState]) { this.handlers[newState](); } } }

在游戏循环里，根据当前状态决定update和render的行为：

function update(deltaTime) { switch (fsm.state) { case State.PLAYING: updateGame(deltaTime); break; case State.PAUSED: // 什么都不做 break; case State.GAME_OVER: updateGameOver(deltaTime); break; } }

注意：状态切换时要注意清理上一个状态的残留数据。比如从“游戏中”切到“结束”，要清空子弹、重置分数，否则下一局开始时会带着上一局的状态。这个坑很常见，我在拆解一个跑酷游戏时发现，重新开始后分数没清零，查了半天才发现是状态切换时没重置。

4.4 音效管理：别让音效成为性能瓶颈

H5游戏的音效通常用Audio对象或Web Audio API实现。前者简单，后者强大但复杂。280多款游戏里，大部分用的是Audio对象，少数用Web Audio API做音效合成。

用Audio对象播放音效的常见问题：同一个音效短时间内多次播放会重叠或卡顿。比如射击游戏里连续开火，如果每次都new Audio()，会创建大量对象，性能急剧下降。

解决方案是音效池，和对象池思路一样：

class SoundPool { constructor(src, size = 5) { this.pool = []; for (let i = 0; i < size; i++) { const audio = new Audio(src); audio.volume = 0.5; this.pool.push(audio); } this.index = 0; } play() { const audio = this.pool[this.index]; audio.currentTime = 0; audio.play(); this.index = (this.index + 1) % this.pool.length; } }

这样同一时刻最多有5个音效实例在轮转，不会无限创建。

实操心得：移动端浏览器对音效有自动播放限制，必须用户交互后才能播放。所以游戏开始前通常要有一个“点击开始”的按钮，在点击事件里初始化音频上下文。这个限制在280多款游戏里，做得规范的都会处理，做得粗糙的会直接play()然后被浏览器拦截，导致没声音。

4.5 输入处理：键盘、鼠标、触摸的统一

H5游戏要同时支持键盘、鼠标、触摸三种输入方式。如果每种都单独写一套逻辑，代码会很乱。好的做法是抽象出统一的输入接口。

class InputManager { constructor() { this.keys = {}; this.mouse = { x: 0, y: 0, clicked: false }; this.touches = []; window.addEventListener('keydown', e => this.keys[e.code] = true); window.addEventListener('keyup', e => this.keys[e.code] = false); window.addEventListener('mousemove', e => { this.mouse.x = e.clientX; this.mouse.y = e.clientY; }); window.addEventListener('mousedown', () => this.mouse.clicked = true); window.addEventListener('mouseup', () => this.mouse.clicked = false); window.addEventListener('touchstart', e => { this.touches = Array.from(e.touches); }); } isKeyDown(code) { return !!this.keys[code]; } }

游戏逻辑里只调用input.isKeyDown('ArrowLeft')这样的接口，不关心底层是键盘还是触摸。这样换平台时不用改游戏逻辑。

4.6 存档系统：用localStorage保存进度

很多游戏需要保存最高分、关卡进度、解锁状态。H5游戏最常用的方案是localStorage，简单够用。

const SaveSystem = { save(key, data) { try { localStorage.setItem(key, JSON.stringify(data)); } catch (e) { console.warn('存档失败', e); } }, load(key, defaultValue = null) { try { const data = localStorage.getItem(key); return data ? JSON.parse(data) : defaultValue; } catch (e) { return defaultValue; } } };

注意：localStorage有容量限制，通常5MB左右。存分数、进度没问题，存大量游戏数据就不够了。另外，用户清除浏览器数据会丢失存档，重要数据要考虑其他方案。在280多款游戏里，涉及存档的基本都用localStorage，少数用IndexedDB存更复杂的数据。

5. 实操：从零拆解一款游戏源码的完整流程

5.1 选定目标与准备工作

面对280多款游戏，怎么选第一个拆解目标？我的建议是选你玩过的、规则简单的、代码量在300行以内的。贪吃蛇、打砖块、记忆翻牌都是好选择。别一上来就挑塔防或RPG，容易劝退。

选定后，准备工作有三步。第一，把游戏跑起来，玩几遍，搞清楚规则和交互。第二，打开开发者工具，看控制台有没有报错，看网络请求加载了哪些资源。第三，把源码文件通读一遍，不求全懂，先有个整体印象。

5.2 逐行拆解：以贪吃蛇为例

假设我们选了一款贪吃蛇。拆解流程如下。

第一步，找入口。打开index.html，看引入了哪些JS文件，找到主逻辑文件。通常是game.js或main.js。

第二步，找游戏循环。搜索requestAnimationFrame或setInterval，定位到游戏循环的位置。这是理解整个游戏的起点。

第三步，找数据结构。贪吃蛇的核心数据是蛇身。通常用一个数组表示，数组的每个元素是{x, y}坐标。找到这个数组的定义，理解它是怎么增长的、怎么移动的。

// 典型的蛇身数据结构 let snake = [ { x: 10, y: 10 }, // 蛇头 { x: 9, y: 10 }, { x: 8, y: 10 } // 蛇尾 ];

第四步，找移动逻辑。蛇的移动本质是：在头部前面加一个新坐标，去掉尾部最后一个坐标。如果吃到食物，就不去尾部，蛇就变长了。

function moveSnake() { const head = { ...snake[0] }; head.x += direction.x; head.y += direction.y; snake.unshift(head); if (吃到食物) { // 不删尾部，蛇变长 generateFood(); } else { snake.pop(); } }

第五步，找碰撞检测。蛇撞墙或撞自己就游戏结束。撞墙判断蛇头坐标是否超出边界，撞自己判断蛇头坐标是否和蛇身其他坐标重合。

第六步，找渲染逻辑。用fillRect画蛇身和食物，用clearRect清空画布。

走完这六步，一款贪吃蛇就拆解完了。整个过程大概两三个小时，但收获比看十篇教程都大。

5.3 改造与扩展：把学到的用起来

拆解完不是终点，改造才是。我通常会给拆解的游戏加一两个新功能，验证自己是不是真的懂了。

给贪吃蛇加功能，可以试试这些：加一个“加速”按钮，按住时蛇移动更快；加障碍物，随机生成几块石头；加双人模式，两条蛇同屏竞技；加皮肤系统，蛇身颜色可切换。

每加一个功能，你都会遇到新的问题：加速怎么和游戏循环配合？障碍物怎么和蛇身碰撞检测？双人模式怎么处理两套输入？这些问题逼着你去查资料、改代码，学习效果远超被动阅读。

实操心得：改造时建议用Git管理代码，每加一个功能提交一次。这样改崩了可以回滚，也能清楚看到自己每一步改了什么。我拆解280多款游戏的过程中，养成了每款游戏单独建一个分支的习惯，方便对比不同游戏的实现差异。

6. 常见问题与排查技巧实录

6.1 游戏卡顿与性能问题排查

问题表现：游戏运行不流畅，帧率低，操作有延迟。

排查思路：打开开发者工具的Performance面板，录制几秒游戏过程，看哪部分耗时最长。常见原因有四个。

第一，渲染开销过大。每帧重绘的元素太多，或者用了复杂的绘制操作（如阴影、渐变）。解决办法是减少重绘范围，或者用离屏Canvas预渲染静态元素。

第二，垃圾回收频繁。每帧创建大量临时对象，触发GC。解决办法是用对象池，复用对象。

第三，碰撞检测复杂度过高。O(n²)的碰撞检测在元素多时会很慢。解决办法是用空间分割（如四叉树）减少检测次数。

第四，音效播放过多。同时播放大量音效会占用CPU。解决办法是限制同时播放的音效数量，用音效池。

6.2 移动端适配的坑

问题表现：在电脑上正常，在手机上显示错位、触摸不灵、画面模糊。

排查思路：移动端适配主要处理三个问题——视口、像素比、触摸事件。

视口问题：HTML里要加<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no">，否则页面会按桌面宽度渲染，然后缩放，导致模糊和错位。

像素比问题：高清屏的devicePixelRatio可能是2或3，Canvas的CSS尺寸和实际像素尺寸不一致，导致模糊。解决办法是设置Canvas的width和height为CSS尺寸乘以像素比，然后用ctx.scale缩放。

const dpr = window.devicePixelRatio || 1; const rect = canvas.getBoundingClientRect(); canvas.width = rect.width * dpr; canvas.height = rect.height * dpr; ctx.scale(dpr, dpr);

触摸事件问题：移动端的touchstart和click有300ms延迟，影响操作手感。解决办法是用touchstart代替click，或者引入fastclick库。另外，触摸事件要调用e.preventDefault()阻止默认行为，否则会触发页面滚动。

注意：e.preventDefault()要谨慎使用，用多了会导致页面无法滚动。只在游戏区域内阻止默认行为，游戏区域外保持正常滚动。

6.3 源码阅读中的常见困惑

困惑一：变量命名混乱。很多小游戏的源码是个人练手作品，命名不规范，a、b、x1、y2满天飞。解决办法是先看变量被赋值的地方，再看被使用的地方，通过上下文推断含义。必要时可以重命名变量，帮助理解。

困惑二：逻辑分散在多个文件。有些游戏把逻辑拆得很碎，一个功能分散在好几个文件里。解决办法是画调用关系图，从入口函数开始，一层层往下追，把调用链理清楚。

困惑三：没有注释。280多款游戏里，有注释的是少数。解决办法是自己补注释，读一段代码，用自己的话写一句注释。这个过程本身就是最好的学习。

困惑四：用了不熟悉的API。遇到没见过的Canvas API或JavaScript特性，直接查文档。MDN是最好的参考，每个API都有示例和兼容性说明。

6.4 独家避坑技巧汇总

拆解了这么多游戏，我总结了几条别人不太会提的经验。

技巧一：先跑通再拆解。拿到源码先确保能跑起来，再开始读代码。跑不通的代码读起来事倍功半，可能是缺资源、缺依赖，或者代码本身有bug。

技巧二：用断点代替console.log。在关键位置打断点，单步执行，看变量怎么变化。比到处打日志高效得多，也不污染代码。

技巧三：改参数看效果。把游戏里的速度、大小、颜色等参数改一改，看画面怎么变。这是理解参数作用最快的方式。

技巧四：对比同类游戏。280多款游戏里，同类游戏有很多。把两三款贪吃蛇放一起对比，看它们的数据结构、碰撞检测、渲染方式有什么不同。对比学习比单独看一款收获大得多。

技巧五：建立自己的代码片段库。拆解过程中遇到好的实现，比如对象池、状态机、音效管理，摘出来存到自己的片段库里。下次写游戏直接复用，不用重新造轮子。

技巧六：别追求一次全懂。有些游戏的算法比较复杂，第一遍看不懂很正常。先跳过，把能懂的部分搞懂，过段时间再回来看，往往就豁然开朗了。我拆解一个塔防游戏时，寻路算法看了三遍才明白，第一遍完全懵。

7. 如何把这280多款游戏变成自己的技术资产

7.1 建立个人游戏开发工具箱

拆解过程中，你会发现很多重复出现的模式：游戏循环、对象池、状态机、碰撞检测、输入管理、音效管理、存档系统。这些可以抽出来，做成自己的游戏开发工具箱。

我的做法是建一个game-toolkit目录，每个模块一个文件，写清楚用法和示例。下次做新游戏时，直接引入这些模块，只写游戏特有的逻辑。这样开发效率能提升好几倍。

工具箱里的模块不需要多完美，够用就行。比如碰撞检测，先实现矩形和圆形两种，遇到新需求再补。音效管理，先实现基本的播放和池化，复杂的音频处理以后再说。

7.2 从模仿到创新的路径

拆解280多款游戏，最终目的不是记住这280多款，而是具备独立开发游戏的能力。路径大概是：模仿一款游戏，改造成自己的版本，然后组合多个游戏的元素做一款新游戏，最后完全原创。

模仿阶段，照着源码敲一遍，理解每一行。改造阶段，加功能、换素材、调参数，做出不一样的东西。组合阶段，把贪吃蛇的移动逻辑、打砖块的碰撞检测、跑酷的滚动地图拼在一起，做一个混合玩法的游戏。原创阶段，有了前面的积累，你自然会有自己的想法。

我自己的经验是，拆解到第20款左右时，就开始有“这个功能我可以自己写”的感觉了。到第50款时，看新游戏的源码，基本能猜到它的实现思路。这个量变到质变的过程，只有真正动手拆解才能体会到。

7.3 持续学习的资源与方向

280多款游戏拆完后，下一步可以往这些方向深入：WebGL和Three.js做3D游戏，Web Audio API做专业音效，WebSocket做多人对战，物理引擎做更真实的模拟，游戏AI做智能对手。

资源方面，MDN的Canvas教程和Web API文档是基础，GitHub上的开源游戏项目是进阶，游戏开发相关的书籍和论文是深入。但最重要的还是动手，看再多不如自己写一款。

提示：别贪多。280多款游戏不需要全拆，挑20到30款不同类型的深入拆解，比泛泛看280款收获大得多。质量比数量重要，深度比广度重要。

最后分享一个我自己的习惯：每拆解完一款游戏，写一篇简短的笔记，记录这款游戏的核心技术点、我踩的坑、我做的改造。这些笔记积累下来，就是一份属于自己的游戏开发知识库。过段时间回头看，能清楚看到自己的成长轨迹。这个习惯坚持了几年，对我帮助极大，推荐你也试试。