一个下午，游戏我蹲在电脑前改了三小时贪吃蛇。代码不是游戏那种满屏霓虹渐变的酷炫版本，就是代码绿底黑格，蛇身用最土的游戏纯色方块。改什么呢？代码改它的移动逻辑。原版代码里，游戏蛇每走一步，代码身体每个关节都得跟着头挪一次。游戏我把它改成只记头部轨迹，代码身体顺着轨迹滑。游戏结果帧率从30飙到60，代码游戏流畅得像抹了油。游戏 这事让我琢磨出一件事：web小游戏代码的代码精髓，不在于堆特效，游戏而在于找到那个最省力的计算方式。你写一堆花哨的粒子系统，不如把核心循环写干净。 先说说最基础的——游戏循环。几乎所有web游戏都靠`requestAnimationFrame`撑起来。它比`setInterval`聪明，浏览器刷新才跑，不刷新就歇着，省电又顺滑。我见过新手用`setInterval(fn, 1000/60)`，结果切个标签页回来，游戏时间全错乱了。换成`requestAnimationFrame`，再记录上次时间戳，用差值算位移，问题直接消失。 然后是碰撞检测。多数人第一反应是遍历所有物体，两两比较坐标。十个物体还好，一百个就开始卡。我写过一个弹球游戏，球和砖块碰撞，砖块有几十块，每帧全量遍历，肉眼可见的掉帧。后来改成只检测球附近九宫格内的砖，逻辑没变，速度翻了三倍。代码量没多多少，就是加个索引数组，按行存砖块，拿球的坐标去查行号，只比那一行和相邻两行。 别小看这种“笨办法”。web游戏跑在浏览器里，性能天花板比原生应用低得多。你写的是给人玩的游戏，不是给跑分软件看的demo。玩家感知到的流畅度，往往取决于你砍掉了多少无效计算。 还有个常被忽略的点——DOM操作。很多人写web小游戏，直接用`div`当游戏元素，每个精灵一个节点。移动时改`style.left`和`style.top`。这在元素少时没问题，一旦超过三十个，重排和重绘就能把帧率拉垮。我做过一个塔防demo，敌人一波二十个，加上塔和子弹，总共五十多个DOM节点，在低端手机上直接变幻灯片。 解决方案也简单：用`canvas`。把所有游戏元素画在一张画布上，只操作一个节点。代价是你得自己管理绘制顺序和坐标变换，但这本来就是游戏代码该干的事。canvas的`getContext('2d')`，配合`ctx.clearRect`清屏，再`ctx.fillRect`画方块，性能比操作几十个DOM高一个量级。 说到绘制，有个细节值得提：不要每帧都重建样式。比如`ctx.fillStyle = '#0f0'`，如果颜色没变，就别重复赋值。赋值本身不重，但内部可能会触发状态检查，累积起来就是开销。把不变的东西提到循环外面，只更新变的部分——坐标、角度、尺寸。这个习惯，写久了自然就养成了。 音频也常被糊弄过去。很多人图省事，直接用`new Audio()`播放音效，每次新建实例。游戏里子弹命中、敌人死亡，一秒内可能触发十几次，每个实例都加载解码，内存直接爆炸。正确做法是预加载少量`Audio`对象，循环复用，或者用`AudioContext`生成短音效——那又是另一个深坑，但至少别踩“每次新建”这个最浅的坑。 说到底，web小游戏代码写得好不好，看的是你愿不愿意花时间想“这一步到底在算什么”。我见过有人为了省事，每帧把整个游戏状态序列化成JSON存起来，说是为了调试方便。结果游戏卡成PPT。调试方便是方便了，玩家可不会为你的debug体验买单。 写游戏代码跟写业务代码不一样。业务代码可以容忍一点冗余，游戏代码每一帧都在跟时间赛跑。16毫秒一帧，你得在这点时间里完成输入处理、逻辑更新、碰撞检测、渲染输出。哪一步慢了，玩家立刻感觉到——那种“手感发粘”的体验，就是帧率不稳造成的。 我的建议是：先跑起来，再优化。别一开始就想着完美架构。写个能玩的版本，用性能分析工具（Chrome自带的Performance面板就够）看瓶颈在哪。通常你会发现，问题不在算法，而在那些不起眼的小地方——比如某处不小心用了`Array.prototype.find`替代简单循环，或者某个事件监听器忘了移除，每帧都在重复触发。 就说到这。代码这东西，看着是逻辑，写着是细节。下次你写个贪吃蛇，不妨试试把蛇身移动改成轨迹记录法，再感受一下那种“丝滑”的差别。那就是web小游戏代码最迷人的地方——几行小改动，体验天翻地覆。