孙亚健前阵子我沉迷一个类似球球大作战的网页小游戏，玩着玩着就萌生了一个想法：与其一直玩别人的，不如自己拿代码造一个同样的。于是我用 Kimi 2.5 Agent 做辅助，从零开始写了一个叫做「宇宙吞噬」的对抗小游戏，核心玩法就是控制一个球在宇宙场景里吞噬粒子、躲避强敌，地图里还塞了几个 AI Bot 跟你抢资源，最后用一个排行榜记录你的最高成绩。
这篇文章就把整个从 0 到 1 的过程拆开讲清楚，包括 Canvas 粒子特效的实现、AI Bot 的对抗策略、排行榜的数据设计，还有我在开发过程中踩过的坑和 Kimi 2.5 Agent 在哪些环节真正帮上了忙。如果你最近也想拿 Canvas 写点什么，或者好奇“AI 辅助编程到底能不能落地”，这篇应该能给你不少参考。
1. 项目构思与技术选型
1.1 游戏玩法与核心机制设计
「宇宙吞噬」的基础玩法跟球球大作战一样：你在一个相对封闭的太空场景里控制一颗球，地图上散布着各种发光粒子，吞噬它们可以让自己的球变大；地图里同时存在多个 AI Bot，它们也在到处觅食和吞噬，如果遇到比自己小的球，你可以撞上去把它吞掉，反之就要赶紧跑。游戏的最终目标是在有限时间内尽可能变大，并且活到最后。
这个玩法看起来简单，但拆解下来需要处理的模块比我预想的多得多：
- 玩家控制模块：鼠标或键盘驱动球体平滑移动
- 粒子生成模块：随机位置、随机大小、随机颜色，同时保持整体场景密度
- 吞噬判定模块：核心难点，要区分“吞掉粒子”和“吞掉其他球体”两种不同判定
- AI Bot 模块：每个 Bot 要有独立的目标选择和移动决策
- 碰撞反馈模块：吞掉东西之后球的半径要平滑变大，不能瞬移式跳变
- 排行榜模块：记录玩家单局最高分，并按分数排序展示
我的第一版直接用原生 Canvas 2D 渲染，整个游戏逻辑全部跑在浏览器里，不依赖任何网络资源。这样最大的好处是开发调试链路短，写完 HTML 文件拖进浏览器就能跑，适合做原型验证。如果你以后想升级成多人在线版，再把这套逻辑迁到 WebSocket 服务端也不难。
1.2 为什么选 Kimi 2.5 Agent 来辅助开发
说实话，最开始我并没有打算用 AI 写整个游戏。我一开始想自己手写，结果写到粒子系统的时候，代码变得越来越散，Canvas 的状态管理、requestAnimationFrame 的帧循环、碰撞检测的性能优化，这些东西混在一起之后维护起来很头疼。后来我试着把需求描述给 Kimi 2.5 Agent，让它先搭一版代码骨架，我再基于它输出做迭代，效率确实明显不一样。
用 Kimi 2.5 Agent 辅助这种偏“图形 + 逻辑”的项目，有一个很大的优势：它能把一些我脑子里已经有了但还没来得及写成代码的结构直接输出成可读性不错的实现。比如我描述“有一个玩家球，多个 Bot 球，每个球有坐标、半径、颜色，每帧都要移动然后重绘”，它能直接给我生成一套合理的类和渲染循环，减少了从想法到代码的转换成本。
不过这里要提醒一下：AI 生成的代码不能直接无脑用。它生成的版本往往是最小可用实现，性能优化、边界情况、手感调优这些都得自己来。我的工作方式是把 Kimi 2.5 Agent 当成一个“很懂代码但没玩过游戏”的同事——它负责把结构搭出来，我负责确认玩法和手感。
1.3 技术栈与工具清单
整个项目用到的技术栈非常轻量：
- HTML5 Canvas 2D：负责所有渲染，粒子、球体、背景星空、UI 都在同一个画布上绘制
- 原生 JavaScript（ES6+）：游戏逻辑全部用原生 JS 实现，没有引入框架
- localStorage：排行榜数据存储，简单可靠
- Kimi 2.5 Agent：代码生成、架构建议、调试辅助
选 Canvas 2D 而不是 WebGL，是因为这个项目的粒子数量最多也就几百个，球体也就十几个，2D 渲染完全够用，而且代码直观性好。以后如果粒子数量动不动上万，再迁移到 WebGL 也不迟。选 localStorage 存排行榜，是因为原型阶段没必要上后端数据库，localStorage 天然支持 JSON 存储，刷新页面数据不丢，完全满足需求。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Canvas 粒子特效与核心渲染机制
2.1 粒子系统的设计与实现
粒子是「宇宙吞噬」里最核心的视觉元素。地图上的发光小点既是玩家的“食物”，也是整个太空场景的氛围来源。我的设计思路是这样的：粒子不是单纯的圆点，而是带有发光效果的小球，每个粒子有独立的生命周期、闪烁频率和运动漂移。
Kimi 2.5 Agent 帮我生成了第一个粒子版本，结构大致如下：
javascript复制class Particle {
constructor(x, y, size, color) {
this.x = x
this.y = y
this.size = size
this.color = color
this.life = 1
this.decay = 0.0005 + Math.random() * 0.001
this.driftX = (Math.random() - 0.5) * 0.2
this.driftY = (Math.random() - 0.5) * 0.2
}
update() {
this.x += this.driftX
this.y += this.driftY
this.life -= this.decay
}
draw(ctx) {
const alpha = Math.max(this.life, 0)
ctx.globalAlpha = alpha
ctx.fillStyle = this.color
ctx.beginPath()
ctx.arc(this.x, this.y, this.size, 0, Math.PI * 2)
ctx.fill()
}
}
但说实话，这个版本直接跑起来效果很普通，就是一堆圆点在飘。我后来做了两个关键改造：一个是给粒子加了光晕效果，用 createRadialGradient 绘制从亮到透明的渐变圆；另一个是让粒子有脉动效果，即半径随时间做正弦波动。这两个改造让画面立刻有了“太空粒子”的感觉。
javascript复制draw(ctx) {
const alpha = Math.max(this.life, 0)
const pulse = 1 + Math.sin(Date.now() / 300 + this.x) * 0.15
const radius = this.size * pulse
const gradient = ctx.createRadialGradient(
this.x, this.y, 0,
this.x, this.y, radius * 2
)
gradient.addColorStop(0, this.color)
gradient.addColorStop(1, 'rgba(0,0,0,0)')
ctx.globalAlpha = alpha
ctx.fillStyle = gradient
ctx.beginPath()
ctx.arc(this.x, this.y, radius * 2, 0, Math.PI * 2)
ctx.fill()
}
这里有个性能细节要特别注意：createRadialGradient 每次 draw 都创建，如果粒子数量多，会带来不小的 GC 压力。我的方案是给粒子加一个 cacheKey 属性，当粒子的颜色和大小没变化时，直接复用离屏 Canvas 绘制好的渐变纹理，用 drawImage 代替 createRadialGradient。实测 300 个粒子场景下，FPS 从 50 提升到了 60，效果很明显。
2.2 球的吞噬反馈与平滑缩放
玩家球和 Bot 球吞噬粒子之后，半径变化不能是瞬时的，否则视觉上会非常突兀。我的做法是设置一个 targetRadius，每帧让 currentRadius 向 targetRadius 做线性插值：
javascript复制this.radius += (this.targetRadius - this.radius) * 0.05
这个缓动系数 0.05 是调出来的。如果太大，球体会抖动；如果太小，吞噬后的变大反馈就太迟钝，手感不好。这属于“手感调优”，AI 很难给出通用值，必须自己在浏览器里反复试。
球体本身的绘制也做了分层处理：
- 内部填充：半透明的渐变圆，模拟球体内部的光感
- 边缘高光：在主球周围画一个较亮的描边，让球在深色背景上更容易被看到
- 纹理细节：在球内部随机生成一些小圆点，模拟星云质感
这里用到了一个 Canvas 合成技巧。整个场景是深色太空背景，但球体的光晕如果直接覆盖会显得很脏。我把它拆成两个 canvas 图层：底层画背景和粒子，上层画球体。上层 canvas 使用 globalCompositeOperation = 'lighter'，这样球体的光晕叠加到底层时会自然变亮，营造出真正发光的感觉。
2.3 背景星空与视觉层次
背景不能是一片纯黑，那样太空氛围就没了。我实现了一个三层视差星空：第一层是大量小星星，移动速度最慢；第二层是中等星点，移动速度稍快；第三层是少量大星云纹理，移动最快。视差效果配合玩家移动时，会给人很强的“球在太空中穿梭”的沉浸感。
星空层不需要每帧重新生成星星，只需要根据玩家位置偏移绘制即可：
javascript复制ctx.save()
ctx.translate(-camera.x * 0.3, -camera.y * 0.3)
// 绘制第一层星星
for (const star of starsLayer1) {
ctx.fillStyle = star.color
ctx.fillRect(star.x, star.y, star.size, star.size)
}
ctx.restore()
这里 0.3 就是视差系数，表示背景层跟随摄像机的缩放比例。数值越大，背景移动越快，越像“近景”。我自己的经验是：三层分别用 0.1、0.3、0.7 比较自然，拉得太开反而让人感觉背景和前景脱节。
2.4 摄像机跟随与地图边界
游戏地图比浏览器屏幕大得多，所以需要实现摄像机跟随。核心逻辑是：每一帧计算玩家的屏幕中心偏离量，然后更新相机偏移量，使玩家球始终处于画面中心附近。
javascript复制const targetX = player.x - canvas.width / 2
const targetY = player.y - canvas.height / 2
camera.x += (targetX - camera.x) * 0.08
camera.y += (targetY - camera.y) * 0.08
这里同样用了缓动系数 0.08，目的不是让摄像机死板地锁定在玩家中心，而是给玩家一定的“视野提前量”，让玩家能看到自己前方更多的地图内容。如果你玩过球球大作战，你会发现它的摄像头其实也是略微偏向移动方向的，原理一样。
地图边界方面，我用了一个简单的矩形边界。玩家和 Bot 的位置被限制在 [0, mapWidth] 和 [0, mapHeight] 范围内。边界处我加了一个淡红色的警示效果，当球靠近边界时，屏幕边缘会泛起红光，这样玩家会有意识地控制方向，不会一直顶在边界上。
3. AI Bot 的对抗策略设计
3.1 AI Bot 的行为状态机
刚开始做 AI Bot 的时候，我走了弯路——想直接写一套复杂的决策树。后来发现，对于这种玩法，用状态机就够了。每个 Bot 只有四个状态：游荡、觅食、追击、逃跑。
状态切换逻辑用文字描述是这样的：
- 游荡状态：Bot 没有明确目标，随机选一个方向缓慢移动，偶尔转向。如果视野内出现粒子，则切换到觅食状态。
- 觅食状态：Bot 锁定距离自己最近且比自己小的粒子，向它移动。如果附近出现比自己大很多的目标，则切换到逃跑状态；如果附近出现比自己小的球体，则切换到追击状态。
- 追击状态：Bot 锁定比自己小的球体，加速冲过去。如果目标逃出视野范围，则回到游荡状态；如果接近过程中发现自己判断失误（其实对方更大），则切换到逃跑状态。
- 逃跑状态：Bot 检测到比自己大的威胁，朝反方向移动。如果威胁消失，则切换到游荡状态。
这个状态机的实现核心就是一个 update 方法里的一串条件判断。Kimi 2.5 Agent 帮我快速搭出了最初版本，但它的版本里 Bot 决策太“机械”，每帧都会重算目标，导致 Bot 在几个目标之间反复横跳。我后来给每个状态加了一个最小停留时间和目标锁定机制，Bot 才表现得像“有脑子”的样子。
javascript复制class Bot {
constructor(x, y, radius, color) {
super(x, y, radius, color)
this.state = 'wander'
this.target = null
this.stateTimer = 0
this.minStateTime = 1000
}
update(deltaTime) {
this.stateTimer -= deltaTime
switch (this.state) {
case 'wander':
this.updateWander()
break
case 'seek':
this.updateSeek()
break
case 'chase':
this.updateChase()
break
case 'flee':
this.updateFlee()
break
}
}
}
3.2 Bot 的目标选择与视野范围
Bot 的视野范围不是全图，而是基于自身半径的一个圆形区域。这很符合玩法设定：球越大，看得越远，但同时也更容易成为别的球的目标。视野半径随球体半径动态变化：
javascript复制get viewRadius() {
return this.radius * 10 + 100
}
在这个视野范围内，Bot 选择目标的优先级是：威胁（比自己大） > 食物（粒子） > 猎物（比自己小）。这个优先级顺序非常重要，如果先把优先级给到“猎物”，Bot 就会过于激进，经常一头撞进比自己大的球的嘴里，游戏体验很差。
我还给 Bot 加了一些随机扰动值。比如在觅食状态下，Bot 不会直接朝粒子方向直线移动，而是会有一个 20 度左右的随机偏航角。这个设计模仿真实玩家的操作——真实玩家很难精准走直线，总会有点手抖，Bot 如果走直线反而显得特别假。
3.3 Bot 的免疫机制与难易度平衡
为了让 Bot 更有对抗性，我加了一个简单的“免疫”机制：当 Bot 吞噬一个球之后，会在短时间内获得一个护盾，类似格斗游戏里的“击败后短暂无敌”。这个机制的引入是为了避免“滚雪球效应”——一旦某个 Bot 或玩家连续吞噬几个球，体型优势会滚雪球般越滚越大，一局游戏很快变成一边倒。
免疫机制的实现非常简单，就是在吞并之后设置一个 invincibleTimer = 1000 毫秒。在免疫时间内，其他球撞上来不会触发吞噬判定，只是普通碰撞弹开。这个机制带来的战术价值很明显：你可以利用免疫时间主动贴近比自己大的球，在对方身边游走，等免疫快结束时再迅速脱离，有种“刀尖上跳舞”的刺激感。
3.4 AI 难度分级
我做了三种 Bot 难度，分别是：
- 普通 Bot：视野范围小，移动速度慢，目标切换频率低
- 敏捷 Bot：视野中等，移动速度快，追击欲望强，容易主动攻击玩家
- 谨慎 Bot：视野范围大，逃跑优先级最高，非常难被抓到
为了让排行榜更有意义，击杀不同难度的 Bot 获得的积分不同。敏捷 Bot 分值最高，谨慎 Bot 次之，普通 Bot 最低。这个设定鼓励玩家去冒险追击敏捷 Bot，而不是只躲在角落里吃粒子。
4. 排行榜设计与数据持久化
4.1 数据模型与存储方案
排行榜数据用 localStorage 存储，结构是一个 JSON 数组，每个元素包含玩家名、分数、时间戳、球体大小等信息。我设计的数据结构如下：
javascript复制{
name: '星际浪客',
score: 12800,
radius: 56,
killedBots: 3,
duration: 245,
timestamp: 1712028800000
}
存储用的键名是 universeEater_leaderboard。之所以加一个项目名前缀，是为了避免以后同一个域名下其他项目的 localStorage 数据互相污染。这个细节看似不起眼，但当你一个域名上挂了好几个小项目时，就知道有多重要了。
存入排行版的时机是游戏结束时。玩家死亡或点击“结束游戏”按钮后，系统会自动把本局数据写入排行榜。如果本局分数排不进前 20，我会弹窗提示“未上榜”，让玩家决定是否重开一局。如果上榜了，会有一个上榜动画效果，用 Canvas 画一些彩色粒子爆炸来增加成就感。
4.2 分数计算逻辑
分数不是简单地按吞噬微粒数量累加，而是用“最终球体半径”作为主要计分依据。具体公式是：
javascript复制const baseScore = Math.floor(player.targetRadius * 10)
const botKillBonus = killedBots.reduce((sum, bot) => sum + bot.scoreValue, 0)
const timeBonus = Math.max(0, Math.floor((gameDuration / 1000) * 2))
totalScore = baseScore + botKillBonus + timeBonus
用最终半径作为主分数，能同时反映玩家的吞噬数量和存活能力，避免“躲全图然后憋大招”这种消极玩法。Bot 击杀奖励和存活时间奖励则是附加项，鼓励玩家主动对抗而不是纯粹苟活。
分数计算写在服务端还是客户端，这个项目里没有争议——原型阶段直接写客户端就行。但我依然做了一个简单的数据校验：分数不会超过 mapWidth * mapHeight / 100 这样一个理论最大值，超过则认为异常数据，拒绝写入排行榜。这是防“作弊”的一个粗粒度方案，如果你以后要接后端，这个校验逻辑可以原样搬过去。
4.3 排行榜 UI 与交互细节
排行榜 UI 我直接在 Canvas 里绘制，没有用 DOM 元素。这样做的理由是：游戏全屏运行，如果中间插一个 DOM 排行榜，不仅样式割裂，层级处理也麻烦。Canvas 绘制排行榜虽然代码多一些，但能实现很多好看的动效。
排行榜面板支持滚动。用 Canvas 里的滚轮事件监听，滚动区域限制在排行榜面板内，滚动条用半透明矩形绘制。排名前三名的条目会有不同的高亮颜色：第一名金色，第二名银色，第三名铜色。当前玩家自己的记录会用白色高亮，并显示“这是你”的小标签，这样玩家很快就能在排行榜里找到自己。
数据从 localStorage 读出来之后，按照 score 降序排列，只取前 20 条。如果两条记录分数相同，则时间戳更早的排前面。排序逻辑就一行：
javascript复制const sorted = records.sort((a, b) => b.score - a.score || a.timestamp - b.timestamp)
插入新记录时，我用了“插入后排序再截断”的策略，而不是遍历找到正确位置再插入。因为最多就 20 条数据，排序性能差异可以忽略不计，但代码简洁度会高很多。
4.4 玩家名称输入
游戏开始前，会有一个简洁的 Canvas 输入界面，让玩家输入昵称。因为我用的是纯 Canvas，没有 HTML 输入框，所以输入逻辑是监听键盘事件然后拼接字符串。这个方案的缺点是不能显示系统输入法候选词，对中文输入不友好。我做了个折中：开始前让玩家选一个预设昵称，或者随机生成一个太空风昵称（比如“星际浪客”“黑洞吞噬者”“星舰守望者”），这样彻底避开中文输入问题。
如果你想让玩家自定义中文昵称，我建议还是用 DOM 输入框，只是在视觉上把它摆在 Canvas 游戏界面上方，通过 CSS 把它做得跟游戏浑然一体。这个我在后续项目里试过，体验比纯 Canvas 输入好很多，尤其是手机端。
5. 实操过程：从 0 到可玩版本
5.1 第一版：让画面先动起来
我的开发策略是“先让画面动起来，再逐步加玩法”。第一版只实现了三件事：深色星空背景、一个玩家球、几个随机飘动的粒子。玩家球用键盘 WASD 控制，粒子没有任何交互，只是不停漂移重绘。
这个阶段最重要的目的是打通 Canvas 的基本渲染链路：创建画布、写 rAF 循环、处理窗口缩放。窗口缩放这里有个坑：如果直接设置 canvas.width = window.innerWidth，会导致画布内容被清空。正确做法是先用一个 resize 事件标记需要重新设置尺寸，然后在下一帧渲染前应用，并且按 window.devicePixelRatio 缩放画布，否则高分屏上画面会发虚：
javascript复制function resizeCanvas() {
const dpr = window.devicePixelRatio || 1
canvas.width = window.innerWidth * dpr
canvas.height = window.innerHeight * dpr
ctx.scale(dpr, dpr)
}
5.2 第二版：加入吞噬判定和摄像头
第二版加入了最核心的吞噬判定逻辑。玩家球碰到比自己小的粒子时，粒子被消除，玩家球变大；碰到比自己大的粒子则无事发生。球的移动从键盘改成了鼠标跟手移动，这是球球类游戏最舒服的操作方式。
吞噬判定有个细节：不是判定“圆心距离小于半径之和”就吞噬。因为球在快速移动时，某个帧里可能刚好从粒子旁边擦过去，圆心距离略大于半径之和，但实际视觉上已经碰到了。我的方案是用一个更大的判定范围，同时检测位置差值：
javascript复制const dx = player.x - particle.x
const dy = player.y - particle.y
const dist = Math.sqrt(dx * dx + dy * dy)
const threshold = player.radius * 0.8 + particle.size * 0.5
if (dist < threshold) {
// 吞噬
}
这个 0.8 和 0.5 也是调出来的。0.8 的意思是玩家球不需要完全“盖住”粒子，只要核心边缘接触到粒子的中心附近就能吞噬，手感更宽松。如果两个系数都是 1，玩家会觉得自己已经碰到了但没吃到，体验很沮丧。
5.3 第三版：AI Bot 进场
AI Bot 进场是这个项目里最让我兴奋的一步。当第一个 Bot 出现在地图上，并且它会追着粒子跑、会躲着玩家、偶尔还会主动冲过来试图吞掉你的时候，整个游戏从“一个演示 Demo”变成了“一个能玩的游戏”。
这个阶段我重点调试了 Bot 的速度。如果 Bot 最大速度跟玩家一样，那玩家靠操作很难甩掉 Bot；如果 Bot 速度太快，玩家又会觉得不公平。我最终的方案是：Bot 的最大速度跟它的半径成反比——大 Bot 移动慢，小 Bot 移动快。这个设定跟主流大球吃小球游戏是一致的，因为球越大质量越大，惯性越大，加速越慢。
Bot 的加速也不是瞬间到最大值，而是有一个插值过程：
javascript复制const targetSpeed = baseSpeed * (1 - radius / 200)
this.vx += (targetSpeed * dirX - this.vx) * 0.05
this.vy += (targetSpeed * dirY - this.vy) * 0.05
这个 0.05 的插值让 Bot 的运动变得平滑，更像真人操作。如果直接设置 this.vx = targetSpeed * dirX，Bot 的运动会出现严重的“瞬移感”，因为每帧速度方向都在变，视觉上会非常僵硬。
5.4 第四版：排行榜和最终包装
最后一步是把排行榜接入。我在菜单界面画了一个“排行榜”按钮，点击进入排行榜面板，再点击返回回到主菜单。游戏结束后，自动弹出排行榜写入确认框，写入成功后直接展示排行榜列表。
界面布局我用了一个简单的 Canvas UI 框架：所有界面组件都是矩形区域加文字，通过坐标和回调函数处理点击。整个 UI 代码不算多，但逻辑上要区分“菜单界面”“游戏界面”“排行榜界面”“暂停界面”四种状态，每个状态对应不同的 draw 和 update 逻辑。这个状态管理用 if/else 也能做，但用状态对象更清晰：
javascript复制const gameState = {
current: 'menu',
switchTo(nextState) {
this.current = nextState
// 额外初始化逻辑
}
}
5.5 Kimi 2.5 Agent 在开发中的具体用法
聊到实际操作，我具体是怎么用 Kimi 2.5 Agent 的，可以分享几个真实的提示词片段。
第一个是让它搭代码骨架。我会说：“请帮我生成一个 HTML5 Canvas 游戏的基础结构，用原生 JS，包含 requestAnimationFrame 游戏循环、玩家的鼠标控制、多个 AI 球体的移动逻辑，代码用 ES6 class 组织。”它会输出一个可以跑起来的版本，我基于它继续改。
第二个是让它帮忙重构。如果发现某个函数太臃肿，我会把代码贴给它，说：“请帮我把这个函数拆成多个职责单一的辅助函数，并保持行为不变。”这个在后期优化里很实用，因为 AI 拆分的函数结构通常比我自己拍的更规范。
第三个是让它解释不熟悉的概念。比如当我一开始没搞明白 Canvas 的 globalCompositeOperation 各个属性的区别时，我直接问它：“‘lighter’、‘screen’、‘overlay’ 在 Canvas 里有什么区别？”它给出的解释和示例代码能让我快速上手。
但要注意，AI 的输出不代表权威正确，尤其是涉及性能优化和浏览器兼容性时，一定要自己验证。有一次它给我推荐了 ctx.roundRect 来画圆角矩形，我觉得挺好用，结果一查兼容性，发现某些浏览器不支持，最后还是换回了 ctx.arc 加 ctx.lineTo 的方式。
6. 常见问题与排查技巧实录
6.1 画面卡顿与掉帧问题
「宇宙吞噬」里最容易出现卡顿的场景是：大量粒子同时在屏幕内，且粒子绘制使用了 createRadialGradient。这个问题在粒子数量达到 400 以上时变得非常明显。我的排查方式是用浏览器 DevTools 的 Performance 面板录制一段游戏回放，定位到耗时的具体函数。如果看到 draw 函数占用率超过总帧耗时的 70%，那基本可以断定是绘制函数性能问题。
解决方案有两个层面。一是减少逐帧创建的临时对象，比如把 createRadialGradient 的结果缓存到粒子对象上。二是引入粒子对象池——粒子消失时不是从数组中删除，而是把它的 active 标记设为 false，新粒子产生时优先复用 inactive 的粒子。这样能显著减少 GC 触发频率。
6.2 Canvas 的 devicePixelRatio 适配问题
这个坑十个人有九个会踩。刚开始开发时，我没有做 DPR 适配，在自己的笔记本上看着还行，结果朋友在 4K 屏幕上打开，整个画面都是模糊的。原因就是 Canvas 的 CSS 尺寸和物理像素尺寸不一致。
正确做法是：
javascript复制const dpr = window.devicePixelRatio || 1
canvas.width = cssWidth * dpr
canvas.height = cssHeight * dpr
canvas.style.width = cssWidth + 'px'
canvas.style.height = cssHeight + 'px'
但这里还有一个坑：ctx.scale(dpr, dpr) 需要在 resize 之后重新设置，而且是在所有绘制之前。如果忘记了，画面内容会被裁剪或者出现错位。我自己的经验是把 DPR 设置封装成一个 setupCanvas(canvas) 函数，每次 resize 都重新调用，避免漏掉任何一步。
6.3 AI Bot 聚成一团的问题
我记得第一次把 8 个 Bot 放进地图时，它们很快就互相聚集到了地图中心，形成一个“球团”，谁也不理谁，整个游戏失去了对抗性。这个问题的根因是 Bot 目标选择的随机性不足——所有 Bot 都在找距离自己最近的粒子，而粒子在地图中心附近生成较多，所以全都朝同一个方向聚集。
解决方案有两个。一是让 Bot 的目标选择加入随机性，即以 80% 概率选择最近目标，以 20% 概率随机选一个视野内的其他目标。二是加入 Bot 之间的排斥力：当两个 Bot 距离过近时，各自获得一个方向相反的推力，模拟“灵活走位”，避免重叠。
我最终采用了“概率换目标 + 排斥力”的组合方案，Bot 的分布明显均匀了很多，地图上的战斗也分散开了。
6.4 localStorage 数据损坏的异常处理
localStorage 存数据很简单，但读数据时一定要做异常处理。有一次我手滑改了数据结构，旧版本的 JSON 无法解析，导致排行榜整个白屏。排查后发现是 JSON.parse 抛出了异常——localStorage 里存的是一个被截断的 JSON 字符串。
从那以后，我每次读取 localStorage 都会包一层 try/catch，解析失败直接返回空数组：
javascript复制function loadLeaderboard() {
try {
const raw = localStorage.getItem(KEY)
if (!raw) return []
const data = JSON.parse(raw)
if (!Array.isArray(data)) return []
return data.filter(item => item && typeof item.score === 'number')
} catch (e) {
return []
}
}
6.5 鼠标跟手移动的“加速度”手感问题
如果直接让玩家球的速度等于鼠标位置与球位置的差值，球会显得很“贼”，稍微动一下鼠标球就飞出去，难以精准控制。我给鼠标控制加了一层低通滤波：
javascript复制const targetVx = (mouse.x - player.x) * 0.08
const targetVy = (mouse.y - player.y) * 0.08
player.vx += (targetVx - player.vx) * 0.1
player.vy += (targetVy - player.vy) * 0.1
这个“速度的过滤器”让球的运动有了惯性感，更接近真实物理。系数越大，反应越灵敏；系数越小，延迟越高。我最终选了 0.08 作为位置差值系数、0.1 作为速度平滑系数，这两个参数配合下来手感比较自然。
7. 进一步优化与后续扩展
7.1 性能优化方向
如果你想把粒子数量提升到几千甚至上万，Canvas 2D 的 drawImage 方案可能就不够用了。我的建议是研究 WebGL，用 GPU 粒子系统，这样粒子数量可以轻松上万。另一个方向是使用离屏 Canvas 做静态背景混合：把星空背景渲染到一张离屏画布上，每帧只把玩家移动产生的偏移应用上去，避免每帧重绘星空。
代码层面的进一步优化还包括：减少 ctx.save() 和 ctx.restore() 的调用次数，因为这两个操作有性能开销；将 fillStyle 设置为相同颜色时避免重复赋值；将不透明物体的绘制集中在一起，避免频繁切换合成模式。
7.2 从单机到在线的演进路径
目前的「宇宙吞噬」是纯单机版，AI Bot 代替了真人玩家。如果你想让它在朋友之间可玩，需要引入服务端。我设想的演进路径是：
- 第一步：用一个简单的 Node.js WebSocket 服务端替代 Bot 的一部分逻辑
- 第二步：玩家状态同步到服务端，由服务端做权威判定，防止客户端作弊
- 第三步：引入房间系统，支持多个玩家同一房间游玩
这样演进的好处是前期的 Canvas 渲染和游戏逻辑都能复用，只要把移动指令改成发送到服务端、接收服务端广播的数据即可。排行榜也可以从 localStorage 迁移到服务端数据库，所有玩家共享同一个排行榜。
最后分享一点小技巧
在做「宇宙吞噬」的过程中，我发现一个特别适合 Canvas 项目的调试方法：在开发时给游戏加一个全局调试面板，显示当前 FPS、粒子数量、玩家坐标、Bot 状态等关键数据。这个小面板在发布前隐藏，但开发时能帮你省掉大量的 console.log 时间。
另外，如果你也打算用 Kimi 2.5 Agent 帮你写代码，我强烈建议你把需求描述得更“情绪化”一点。比如不要只说“实现一个 Bot 的逃跑逻辑”，而是说“这个 Bot 非常胆小，看到比自己大的球会立即朝反方向跑，而且逃跑时还会有轻微的抖动，像真的被吓到了一样”。AI 生成的代码会更有“人味”，你后面要调的手感参数也会少很多。