简介：这份压缩包面向具备HTML基础、希望用网页技术完成交互小项目的初学者与前端爱好者，围绕贪吃蛇这一经典案例，提供可直接运行的页面素材与配套图像资源，帮助理解HTML、CSS与JavaScript如何协作呈现一个小游戏。包内共3个文件，包含1个HTML页面以及JPG、PNG图片各1个，压缩后约86KB，体量轻便，适合快速导入本地环境查看结构与样式组织。已有1456人学习，说明该案例在入门练习中具有一定参考面。内容覆盖游戏区域与分数显示等页面结构设计，并延伸到键盘事件监听、定时器驱动状态更新、蛇身增长、食物随机生成、边界与自身碰撞判断，以及通过DOM操作刷新界面、借助CSS3动画改善移动观感等关键环节。读者可从中梳理一个完整小项目的模块划分与逻辑闭环，积累前端协同开发与问题拆解的思路，适合作为课堂示例或自学练手素材。

1. 一个 HTML 文件跑起来的贪吃蛇：它到底解决了谁的什么麻烦

用 html 语言做一个能玩的东西，是很多人从「会写标签」跨到「会写逻辑」的第一道坎。这份「用 html 做贪吃蛇」的资源，本质上是一个零依赖的单文件小游戏：一个 canvas 元素配两百来行原生 JavaScript，双击 HTML 文件就能跑，不用 npm install，也不用任何构建工具。它解决的是很具体的一类需求——课程设计要交一个能演示的成品、面试前想复盘一遍游戏循环和碰撞判定、或者单纯想找个足够小的项目把事件、定时器、数组操作串起来练一遍。适合已经会写 div 和 onclick、但还没独立搭过一个完整 tick 循环的人；也适合想给孩子演示「代码能变成游戏」的家长，改两行数字就能换难度。

2. 画布与网格：把 20×20 的棋盘搬上 Canvas 的坐标换算

贪吃蛇看着简单，真正开始写的第一道坎不是逻辑，是坐标。绝大多数新手版本写着写着就出现「蛇头明明碰到了食物却没吃到」「蛇穿墙穿一半卡住了」这类玄学问题，根子都在坐标系没理清。这一章把画布、格子、像素三者的关系钉死，后面所有代码才有地方落脚。

2.1 选 Canvas 而不是四百个 div

用 HTML 表格或者一堆绝对定位的 div 拼棋盘，是很多人第一反应。20×20 的格子就是 400 个节点，每一步都要改一批 class 来切换颜色，浏览器得重新算这 400 个元素的样式和布局。树枝长度短的时候看不出问题，蛇一长、速度一快，掉帧是必然的，而且在低配机器上表现差异极大——你在自己电脑上测着顺滑，交作业那台机器上就像慢动作。

Canvas 的思路完全不同：它只是一块位图，你在上面画矩形、清矩形，浏览器不需要维护 400 个 DOM 节点的状态。这里有个血泪经验——很多人第一次用 Canvas 会把它当成「能画图的 div」，每帧往上面叠加绘制而不清屏，结果蛇变成一条越拖越长的残影，看起来像显卡坏了。正确做法是每帧开头整块清掉。

先把画布和网格参数定下来，这几个常量后面会反复用到：

<!-- 宽高必须写成属性，不能只写 CSS --> <canvas id="game" width="400" height="400"></canvas>

const canvas = document.getElementById('game'); const ctx = canvas.getContext('2d'); const CELL = 20; // 每个格子 20px const COLS = canvas.width / CELL; // 20 列 const ROWS = canvas.height / CELL; // 20 行

CELL是整套代码的手感开关。400×400 的画布配 20px 格子，得到 20×20 的棋盘，这是最经典的难度；改成 16 就变成 25×25，格子更密、蛇一步跨得更小，整体节奏明显更紧。COLS和ROWS必须能整除canvas.width，否则右边或下边会剩一条不满一格的缝，画出来的蛇在边界上会有一格错位，肉眼看着特别难受。我一般会在初始化时加一句断言，把这个问题挡在最前面：

if (canvas.width % CELL !== 0 || canvas.height % CELL !== 0) { throw new Error('画布尺寸必须能被 CELL 整除'); }

2.2 内部状态只存格子坐标，绘制时才乘 CELL

这是整套代码最重要的一条约定：蛇身、食物、方向，全部用「第几行第几列」的整数表示，取值范围是 0 到 COLS-1。只有在真正往画布上画的那一刻，才把格子坐标乘上CELL变成像素坐标。混着用是灾难的开始——你用像素坐标判断碰撞，用格子坐标画图，两边差一个偏移量，bug 会以「偶尔吃不到食物」这种形式出现，极难定位。

下面两个换算函数建议直接在文件开头写好，全局只用这两个入口：

// 格子坐标 -> 像素坐标（格子左上角） function cellToPixel(cx, cy) { return { x: cx * CELL, y: cy * CELL }; } // 像素坐标 -> 格子坐标（触屏点击、鼠标点击时用） function pixelToCell(px, py) { return { cx: Math.floor(px / CELL), cy: Math.floor(py / CELL) }; }

反向换算必须用Math.floor而不是Math.round。原因很直白：一个格子的横向范围是[cx*CELL, cx*CELL + CELL)，左闭右开。用四舍五入的话，点在第 3 格右半边（比如 x=69，CELL=20）会被算成第 4 格，用户点哪儿都偏一格。这个坑在纯键盘操作的版本里不会暴露，一旦加上触屏或鼠标就立刻翻车。

2.3 游戏循环：别用 setInterval 定时器

最省事的写法是setInterval(update, 150)，一百多行就能跑起来。它的问题在浏览器切到后台时暴露得最彻底：标签页不可见时定时器会被节流甚至暂停，切回来的一瞬间可能攒了好几次回调，蛇突然窜出去好几格然后撞墙，玩家完全不知道发生了什么。

现在通用的做法是requestAnimationFrame配一个时间累加器——渲染跟着屏幕刷新率走，逻辑步进按固定间隔消耗累积的时间：

let last = 0; // 上一帧时间戳 let acc = 0; // 累积未消耗的时间 let stepMs = 150; // 每 150ms 逻辑走一步 function loop(ts) { if (!last) last = ts; let dt = ts - last; last = ts; // 关键：单帧最多补 3 步，防止切标签页回来一次性跑飞 acc = Math.min(acc + dt, stepMs * 3); while (acc >= stepMs) { update(); // 只改数据，不绘制 acc -= stepMs; } render(); // 只绘制，不改数据 requestAnimationFrame(loop); } requestAnimationFrame(loop);

这段代码有三个参数值得掰开说。stepMs就是难度：150 是悠闲，100 是正常，70 以下开始考验反应，50 已经接近人类极限。acc的钳制上限stepMs * 3是后悔药——没有它，从后台切回来的那一帧dt可能是好几千毫秒，while会一口气跑几十步，蛇直接原地超度。用while而不是if则是为了保证逻辑步进和真实时间一致，低帧率设备上蛇不会变成慢动作。

update和render分开写看起来是多此一举，但它是后面所有功能的地基。你只有在数据和绘制解耦之后，才能做到「暂停时画面还在但逻辑不动」、才能做死亡动画、才能在不改逻辑的前提下换一套皮肤。新手版本里最常见的写法是update里顺手ctx.fillRect，改两次需求就得推倒重来。

提示：render()的第一行永远是ctx.clearRect(0, 0, canvas.width, canvas.height)。少了这一句，画面会糊成一团。

3. 蛇身、食物与碰撞：三段核心逻辑怎么写才不打架

画布准备好之后，真正的游戏逻辑其实只有三件事：蛇怎么长、食物放哪儿、什么时候算死。这三段代码单独看都不难，难在它们的执行顺序——顺序错一步，就会出现「吃到食物但没变长」「尾巴位置被判定成撞自己」这类看似灵异的现象。

3.1 蛇身用数组，头永远在索引 0

链表在教科书里更优雅，但在这个项目里纯属自找麻烦。蛇的规模不会超过几百节，数组的unshift和pop在这个量级上完全没有性能问题，而数组带来的好处是直观：snake[0]是头，snake[snake.length - 1]是尾，渲染时一个for循环从头画到尾。

let snake = []; // 蛇身数组，[0] 是蛇头 let dir = { x: 1, y: 0 }; // 当前方向：向右 let score = 0; function reset() { snake = [{ x: 10, y: 10 }, { x: 9, y: 10 }, { x: 8, y: 10 }]; dir = { x: 1, y: 0 }; score = 0; spawnFood(); }

初始三节长度是经过考虑的：两节看着太短，玩家不容易意识到「这是条蛇」；四节以上开局就有撞自己的风险。初始位置放在中间偏左、朝右走，是留给玩家反应时间的余量。

每一步的更新逻辑只有十几行，但顺序不能动：

function update() { consumeInput(); // 先消费方向输入，见第 4 章 const head = { x: snake[0].x + dir.x, y: snake[0].y + dir.y }; // 1. 先判死，死了就直接 return，不做后续增删 if (isDead(head)) { state = 'over'; return; } // 2. 头先入队 snake.unshift(head); // 3. 再判断是否吃到食物，决定砍不砍尾巴 if (head.x === food.x && head.y === food.y) { score += 1; spawnFood(); } else { snake.pop(); } }

顺序为什么必须是「入队 → 判断 → 决定出队」？因为没吃到食物时，尾巴恰好在这一步让出位置。如果你先pop再判断碰撞，尾巴那一格会提前空出来，蛇头进入原本的尾巴位置就不会被判定为撞到自己，长蛇急转弯时会出现「擦着尾巴穿过去」的穿模。反过来，如果你先判断碰撞再入队，判死用的是旧头位置，整个判定全错。

绘制部分同样简单，一个循环铺满：

function render() { ctx.clearRect(0, 0, canvas.width, canvas.height); // 画食物 const f = cellToPixel(food.x, food.y); ctx.fillStyle = '#e74c3c'; ctx.fillRect(f.x + 1, f.y + 1, CELL - 2, CELL - 2); // 画蛇，蛇头用另一个颜色 for (let i = 0; i < snake.length; i++) { const p = cellToPixel(snake[i].x, snake[i].y); ctx.fillStyle = i === 0 ? '#2c3e50' : '#27ae60'; ctx.fillRect(p.x + 1, p.y + 1, CELL - 2, CELL - 2); } }

每个矩形向内缩 1px 是廉价但有效的视觉技巧：格子之间会留出一条约 2px 的缝，蛇身一节一节看得清清楚楚。不缩的话整条蛇是一坨连在一起的色块，长到十几节之后根本分不清头在哪儿。CELL - 2和+1是一对，改了其中一个另一个必须跟着改，这算是个小陷阱。

3.2 食物生成：直接随机一定会出事

最直觉的写法是Math.floor(Math.random() * COLS)生成两个数。这个写法在游戏开始的前十秒毫无问题，玩家也察觉不到异常，等蛇长到二十节以后，食物开始频繁落在蛇身上——视觉上它被蛇盖住了，玩家看不到目标却被要求去吃，体验直接崩掉。更糟的是如果吃掉判定用的是坐标相等，蛇头扫过那格时分数会莫名其妙加一。

标准做法是先枚举所有空格子，再从中随机取一个：

function spawnFood() { const free = []; for (let y = 0; y < ROWS; y++) { for (let x = 0; x < COLS; x++) { if (!snake.some(s => s.x === x && s.y === y)) { free.push({ x, y }); } } } if (free.length === 0) { state = 'win'; // 满屏，通关，别忘了这个分支 return; } food = free[Math.floor(Math.random() * free.length)]; }

这段的复杂度是 O(COLS × ROWS × 蛇长)，在 20×20 的棋盘上最多几万次比较，一帧内完成毫无压力，不需要优化。但如果你把网格调大到 100×100，这个函数在蛇很长时就会被调用得比较吃力，那时候可以把蛇身坐标拼成"x,y"塞进一个 Set，每次查询变成 O(1)。这个优化现在不做，是因为它会让代码多二十行而收益为零。

free.length === 0的分支很多人会漏。蛇填满整个棋盘时如果没有这个判断，Math.floor(Math.random() * 0)得到 0，free[0]是undefined，下一次渲染访问food.x直接抛异常，页面白屏，玩家看到的是「游戏玩着玩着崩了」。

3.3 碰撞判定要分成三类，尾巴那一节要特殊对待

撞墙、撞自己、反向撞，这三类看起来可以合并，实际上规则完全不同。撞墙取决于你是想穿墙还是想死——这是两个截然不同的游戏设计，穿墙版本更休闲，撞死版本更紧张，代码里最好用一个显式开关控制，别靠注释。

const WALL_KILL = true; // true = 撞墙死；false = 从另一边穿出来 function isDead(head) { // 类型一：边界 if (WALL_KILL) { if (head.x < 0 || head.x >= COLS || head.y < 0 || head.y >= ROWS) return true; } else { head.x = (head.x + COLS) % COLS; // 穿墙：取模绕回 head.y = (head.y + ROWS) % ROWS; } // 类型二：撞自己，注意排除最后一节 // 没吃到食物时尾巴会让位，头进到尾原本的位置是合法的 for (let i = 0; i < snake.length - 1; i++) { if (snake[i].x === head.x && snake[i].y === head.y) return true; } // 类型三：反向已经在输入层拦掉了，这里不再判 return false; }

循环条件写snake.length - 1是这个函数里唯一需要动脑的地方。假设蛇是[(5,5),(4,5),(3,5)]，头向右走到(6,5)，尾巴(3,5)会在同一步pop掉。但如果蛇头走到(3,5)——也就是尾巴当前位置——它其实完全合法，因为尾巴马上就走。把所有节都算进去，长蛇连续转圈的时会被误杀，玩家会觉得「明明没撞到却死了」，这种 bug 复现率低、投诉率高，属于典型的口口相传的差评来源。

穿墙版本的取模写法也要注意：(head.x + COLS) % COLS里的+ COLS不能省。JavaScript 的%对负数返回负值，-1 % 20等于-1而不是19，少了这个加法，蛇一穿过左边界就直接跑到画布外面去了。

4. 方向输入：用缓冲队列治住 180 度自杀和连按失控

键盘输入看着是最没技术含量的一块，实际上是新手版本里 bug 密度最高的地方。我见过不止一个人卡在这里：逻辑全对，但玩起来就是「有时候会莫名其妙死」，而且完全无法复现。

4.1 keydown 会重复触发，这是第一个雷

浏览器在按住方向键不放时会持续触发keydown，触发频率由操作系统设置决定，通常在 30ms 一次。这意味着一步 150ms 的逻辑里，同一个方向可能被触发四五次。如果每次触发你都直接改dir，问题不大——同方向重复赋值没有副作用。

真正的雷在于「一帧内连续两次有效转向」。玩家向右走，手快，先按上再按左，两次事件都在同一个 150ms 窗口内到达。第一次把方向改成上，第二次检查时——如果检查的是「当前方向」，上是左的垂直方向，不算反向——于是方向被改成左。下一次update执行时，蛇头朝左，紧挨着自己身体，直接撞死。玩家看到的画面是「我就按了个上，蛇自己回头把自己咬死了」。

let currentName = 'right'; // 当前生效的方向 const queue = []; // 待消费的方向队列 const VEC = { up: { x: 0, y: -1 }, down: { x: 0, y: 1 }, left: { x: -1, y: 0 }, right: { x: 1, y: 0 } }; const OPPOSITE = { up: 'down', down: 'up', left: 'right', right: 'left' }; const KEYMAP = { ArrowUp: 'up', ArrowDown: 'down', ArrowLeft: 'left', ArrowRight: 'right', w: 'up', s: 'down', a: 'left', d: 'right', W: 'up', S: 'down', A: 'left', D: 'right' }; function pushDir(name) { // 比较对象是队列里最后一个方向，不是当前生效方向 const lastDir = queue.length ? queue[queue.length - 1] : currentName; if (name === lastDir) return; // 同向，忽略 if (name === OPPOSITE[lastDir]) return; // 反向，丢弃 if (queue.length >= 2) return; // 最多缓冲 2 个 queue.push(name); } document.addEventListener('keydown', (e) => { const name = KEYMAP[e.key]; if (!name) return; e.preventDefault(); // 阻止方向键滚动页面 pushDir(name); }); // 每个逻辑步开始时消费一个 function consumeInput() { if (queue.length === 0) return; currentName = queue.shift(); dir = VEC[currentName]; }

这里有几个参数和判断值得单独说。

比较对象必须是队列尾部，不是currentName。这是整个函数的核心。如果拿currentName去比，队列里攒的第二个方向就没法跟第一个方向做校验，反向拦截会失效。改成跟队尾比，无论队列里排了几个，每一个新方向都跟它前面那个做检查，逻辑就闭合了。

队列上限 2 是手感的关键。不限制的话，玩家在 150ms 内快速连按四个方向，队列会攒四个，蛇在接下来四个逻辑步里完全不听指挥地乱走，操作感像延迟了半秒。限制成 2 个，意味着最多预输入两次转向，玩家能做出「拐弯后立刻再拐」的连招，同时不会失控。这个数字我试过 1，快速连续拐弯会吞键；试过 3，偶尔会觉得蛇在自作主张。2 是平衡点。

e.preventDefault()不能省。方向键默认行为是滚动页面，400px 高的画布加上页面顶部的说明文字，按几下方向键整个页面就往下跑了，玩家看不到棋盘。

4.2 大小写和输入法都要覆盖

e.key在按住 Shift 时返回的是大写W，开着中文输入法时可能返回Process之类完全无关的值。不处理大写，玩家不小心按了 Shift 之后 WASD 就全失效了，而他自己完全不知道发生了什么——这类问题最消耗排查时间。输入法则需要在keydown里检查e.isComposing：

document.addEventListener('keydown', (e) => { if (e.isComposing) return; // 中文输入法正在组词，不响应 const name = KEYMAP[e.key]; if (!name) return; e.preventDefault(); pushDir(name); });

4.3 触屏和鼠标：pointer 事件一次覆盖三端

移动端是这类小游戏的主要使用场景，只做键盘等于放弃一半用户。触屏滑动的实现要点有两个：一是用pointerdown/pointerup而不是touchstart/touchend，因为 pointer 事件在桌面端用鼠标也能触发，调试时不用每次都开手机模拟器；二是一定要设一个滑动阈值，否则一次普通的点击会被判定成一个随机方向。

let startPt = null; const SWIPE_MIN = 24; // 滑动判定阈值，单位 px canvas.addEventListener('pointerdown', (e) => { startPt = { x: e.clientX, y: e.clientY }; e.preventDefault(); }); canvas.addEventListener('pointerup', (e) => { if (!startPt) return; const dx = e.clientX - startPt.x; const dy = e.clientY - startPt.y; startPt = null; if (Math.hypot(dx, dy) < SWIPE_MIN) return; // 太小，当点击处理 const name = Math.abs(dx) > Math.abs(dy) ? (dx > 0 ? 'right' : 'left') : (dy > 0 ? 'down' : 'up'); pushDir(name); });

SWIPE_MIN取 24 是在手机和桌面上都试过的手感值，低于 15 容易误判，高于 40 需要滑很远才生效。判定方向用绝对值比较而不是算角度，够用且没有三角函数开销，也避免了对角滑动时的抖动。

配套的 CSS 一行都不能少：

canvas { touch-action: none; /* 关键：禁止浏览器接管手势，否则滑动会滚页面 */ user-select: none; /* 防止长按选中画布 */ max-width: 100%; /* 小屏自适应，别让画布溢出 */ display: block; margin: 0 auto; }

touch-action: none是最容易漏的一行。漏了它的表现是：手指在画布上滑动，游戏没反应，整页却在上下滚。很多人会以为是 JS 事件没绑上，花半小时加console.log排查，实际上是浏览器在更早的层级就把手势接管了。

5. 避坑与排查：五个让我整段重写的翻车现场

这一节列的都是真实会卡住人的问题，每条按「现象 → 原因 → 解决」写。遇到这些现象，先别怀疑逻辑写得对不对，按顺序对一遍，八成能直接定位。

现象一：从其他标签页切回来，蛇瞬间窜出去老远然后撞死。

原因：requestAnimationFrame在页面不可见时暂停，切回来那一帧的ts减去last得到一个几千毫秒的差值，累加器塞满，while一口气跑了二三十步。解决：给累加器加钳制acc = Math.min(acc + dt, stepMs * 3)，单帧最多补三步。同时在document.visibilitychange里把last重置为 0，切回来时重新计时。这两道保险我一般一起上。

现象二：快速按上再按左，蛇原地掉头把自己咬死。

原因：一帧内接受了两次转向，第一次生效后第二次没跟「上一次输入」做反向校验。解决：完整照搬第 4.1 节的输入队列，比较对象是队尾而不是当前方向。这个问题还有一个隐蔽变体——如果队列里已经有两条，玩家再按又要覆盖，所以上限判断queue.length >= 2也必须在push之前。

现象三：吃到食物分数涨了，但蛇没变长，或者蛇变长了但食物还在原地。

原因：update里的增删顺序错了。三种错法我都见过：先pop再判食物、先判食物再unshift、spawnFood在unshift之前执行导致新食物生成在还没入队的头位置上。解决：死记住一个顺序——unshift新头 → 判断食物 → 吃到就不pop，没吃到才pop→spawnFood。

现象四：本机跑得很顺，换个浏览器或者手机上整体模糊、格子边缘发虚。

原因：canvas 的渲染尺寸由width/height属性决定，CSS 的width/height只控制显示尺寸。两者不一致时浏览器会拉伸位图，画面就糊了。另一个常见诱因是坐标里出现了0.5这种小数——比如为了画圆角用了半像素偏移，抗锯齿会把边缘糊成灰边。解决：属性写 400，CSS 里也写 400px（小屏自适应时用max-width: 100%而不是改属性），绘制坐标一律取整。真需要高分辨率屏清晰度，就按devicePixelRatio放大画布属性再用ctx.scale缩回来，别直接拉伸。

现象五：手机上滑一下，游戏没动，整个网页跟着滚。

原因：浏览器把画布上的触摸手势当成页面滚动。解决：canvas { touch-action: none; }加上pointerdown里e.preventDefault()。如果这两条都加了还是滚，检查一下 canvas 外面是不是套了overflow: auto的容器，那个容器会抢走触摸行为。

现象六（这条不致命但很典型）：重开一局后，蛇一出生就朝着上一局死时的方向走。

原因：reset()只重置了snake、food、score，漏了dir、currentName和queue。解决：把所有可变状态集中到一个reset()里，并且养成习惯——以后每加一个全局变量，先想它要不要进reset，不进就得写注释说明为什么。输入队列尤其容易漏，上一局残留的方向会在游戏开始的第一个 tick 被消费掉。

6. 从能玩到耐玩：速度曲线、最高分与一份调参对照表

一个能玩的贪吃蛇大概两百行，一个让人愿意多玩几分钟的版本，多出来的部分基本都在「反馈」上。最难的一步其实是速度曲线——固定 150ms 走到底的话，前三十秒很舒服，一分钟后就开始无聊，因为玩家没有任何变强或变强的错觉。

常见做法是随分数阶梯提速。我在文件开头留一个基准值，每次吃到食物时重算，而不是每帧都算：

const BASE_MS = 150; // 初始步进 const MIN_MS = 70; // 速度上限，再快就不是人玩的了 function updateSpeed() { // 每吃 5 个食物提速 4ms，但永远不低于 MIN_MS stepMs = Math.max(MIN_MS, BASE_MS - Math.floor(score / 5) * 4); }

这三个数字是调出来的，不是拍出来的。BASE_MS决定新手能不能活过前二十秒，150 比较宽容；MIN_MS是硬性天花板，70ms 相当于每秒钟走十四步，20×20 的棋盘上反应时间已经不够用了，再调低只会让人骂街；4ms / 5 分的斜率决定了「变快」这件事玩家能不能感知到——每 5 分提速 4ms，大约要吃到 25 分才会明显感觉节奏变了，这个节奏恰到好处，太陡的话玩家会产生「这游戏在欺负我」的挫败感。

最高分的存储用localStorage就够了，不用上任何后端：

function saveBest() { const best = Number(localStorage.getItem('snake_best') || 0); if (score > best) { localStorage.setItem('snake_best', String(score)); return score; } return best; }

注意localStorage里读出来永远是字符串，忘了Number()就会踩到"9" > 10为true的坑——分数超过 10 分之后最高分就再也刷新不了了，而且不报错，纯静默失败。另外file://协议下部分浏览器对localStorage有限制，如果你打算双击 HTML 直接打开，最好在读写外面包一层try/catch，失败就退化成内存变量，别让游戏直接崩掉。

调参的时候直接对着这张表改，改一个值跑一局，比凭感觉乱调快得多：

最后说一个自检习惯。我在每次改完这套代码、准备发给别人之前，会强制走一遍固定的五步：开局连续快速按上左两下，确认不会自杀；让它撞一次墙，确认死亡判定和重开正常；重开一局，确认方向和输入队列都被清空；把手机横竖屏各滑一次，确认页面不跟着滚；最后切到别的标签页停十秒再切回来，确认蛇没有窜出去。这五步十分钟能跑完，漏掉任何一步都可能被打回重做。希望帮到你。

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