1. 项目概述与需求理解1.1 “8x8x飞机大战”到底是个什么项目严格来说javascript打飞机程序8x8x飞机大战并不是一个官方术语也不是某个开源库里约定俗成的叫法。我理解它就是典型的“打飞机”竖版射击游戏练手项目核心玩法是你控制一架战机在屏幕底部左右移动、向上开火敌机从屏幕上方不断出现你需要在被撞到或者被子弹打中之前把所有敌机消灭。标题里的“8x8x”我倾向于理解为一种阵型描述8列敌机、8行编队加上后面的“x”代表关卡难度倍率或者说第N波刷新。当然你也可以把它理解成8行8列的网格型敌机阵列——这类编队玩法在街机时代特别常见比如《小蜜蜂》《太空侵略者》《1945》都是这种思路。用JavaScript实现这样一个游戏既不需要安装复杂的游戏引擎也不需要后端服务一个HTML文件、一个canvas画布、一段原生JS逻辑就能跑起来非常适合前端初学者作为“第一个完整的游戏项目”来做。聊到这类项目绕不开一个问题为什么大家都爱拿“飞机大战”练手因为它的游戏机制足够标准但又不完全简单。你要处理玩家的输入键盘或者触摸、要维护游戏主循环帧更新、要做碰撞检测子弹打中敌机、敌机撞上玩家、要管理游戏状态开局、进行中、结算、复活无敌帧还要考虑画面渲染Canvas绘制自机、敌机、子弹、计分板。一套流程走下来“定时器、事件循环、对象管理、数组遍历”这些JS基础知识点全练到了而且游戏本身有正反馈跑起来之后成就感很强。1.2 用纯JavaScript做不打框架图的是什么你可能会问现在做游戏为什么不直接用Phaser或者PixiJS甚至Unity、Cocos为什么偏要用纯JavaScript手写我的答案很简单练的就是“内功”。飞机大战这种判定逻辑相对简单的2D游戏正好处在一个“用原生代码能轻松驾驭、又不至于简单到无话可说”的甜点区间。选纯JavaScript的好处有三点。第一零依赖零构建。你不需要npm install不需要装Node环境随手新建一个HTML文件在文本编辑器里写完代码浏览器双击就能玩。第二代码所见即所得。整个游戏的逻辑全在你的控制之下哪一帧出了问题、哪个变量没更新打开DevTools一行行断点就能查不容易出现“框架帮你做了什么、你怎么也找不到原因”的黑盒情况。第三对JavaScript核心基本功的锻炼是实打实的。游戏里的每一帧都在考验你对requestAnimationFrame的理解每一次碰撞检测都在锻炼你对数组增删、对象属性访问的熟练度。把这个项目吃透了以后上React、Vue做可视化大屏、做复杂交互很多底层思维是通用的。另外8x8的敌机编队规模设计得很有分寸感。8行8列一共64架敌机既可以铺满屏幕形成气势又不会像100架那样把屏幕渲染拖垮。加上我前面说的“x”倍率关卡增长后可以通过调整垂直下压速度、射击间隔、敌机横向摆动的频率来提升难度而不是盲目堆数量。这种“用规则增加难度”的思路是游戏设计的核心也是这个项目值得写一篇长文来拆解的原因。2. 整体设计与方案选型2.1 渲染方案Canvas 2D还是DOM操作实现一个简单的飞机大战表面上至少有两种技术路线用DOM节点比如div加上背景图、改坐标来实现或者用Canvas画布来绘制。我个人的建议是直接上Canvas除非你是想刻意练习DOM操作性能优化。原因很简单飞机大战的动态元素太多了。自机1架、敌机最多64架、子弹每帧可能有几十颗在飞如果你用DOM方案每一帧都要去改元素的style.transform或者style.left/top。改一次DOM浏览器就要走一次样式计算和布局流程几十个元素同时高频修改很容易触发性能瓶颈掉帧是常有的事。而Canvas本质上是一块位图画布你把每一帧的画面画上去只更新改变区域对应的像素位置性能开销要小得多。我做这个项目时用的是Canvas 2D API不是WebGL。原因也和标题里的“javascript”关键词密切相关WebGL的学习曲线太陡着色器、缓冲区、矩阵变换这些概念对刚接触游戏开发的JS新手来说负担过重而Canvas 2D的ctx.fillRect()、ctx.drawImage()、ctx.beginPath()几乎是直觉式的画一个矩形、画一个圆圈、贴一张图很快就上手了。8x8飞机大战这个规模完全在Canvas 2D的能力范围之内不需要为了炫技引入WebGL。你只要把一些绘制操作合并起来避免每一帧无谓的clearRect全屏清除帧率轻轻松松就能稳定在60帧。2.2 物理模型与坐标系统设计游戏里所有的运动都要有坐标系支撑我的做法是把Canvas的左上角定为原点(0, 0)x轴向右为正y轴向下为正。自机的初始位置放在(canvas.width / 2, canvas.height - 100)屏幕底部留出一点空间给计分信息。敌机的编队坐标则用二维数组来维护数组索引对应行和列值存布尔或敌机对象。每一帧更新时整个编队作为整体向右移动一个偏移量移动到边界就反弹并向下降一行这是“太空侵略者”式编队的标准做法。这里有一个值得强调的设计细节坐标值的更新要让“移动”和“绘制”完全分离。也就是在每帧开始时先根据速度和时间积累更新所有对象的逻辑坐标然后在同一个帧内统一绘制不要在绘制的过程中再去修改坐标。否则可能出现顺序不一致导致画面闪烁或逻辑错乱的情况。为了计算匀速运动我建议记录上一帧到当前帧的时间间隔dt用x speed * dt的方式而不是简单地在每一帧里加一个固定值。固定值的问题在于requestAnimationFrame的触发频率在不同显示器上不一样60Hz显示器和120Hz显示器上游戏速度会差一倍。用时间差来控制无论显示器刷新率多少物体的移动速度都是恒定的。2.3 自机控制键盘、鼠标还是触摸对飞机大战这类游戏手感是灵魂。我在这个项目中优先支持键盘控制方向键或者WASD控制移动空格键发射子弹。如果后期兼容移动端就需要再绑一套触摸或鼠标控制通过监听mousemove或touchmove事件把手势位置直接映射为战机位置。键盘控制的实现有一个新手非常容易踩的坑如果只监听keydown事件来移动飞机你会遇到按键黏滞和方向切换不跟手的问题。比如按住左键再按右键松开右键后理论上应该继续左移但很多初版代码会后直接停在原地。正确的做法是维护一个“按键状态表”用keydown记录某个键是否被按下用keyup把它释放然后每一次主循环轮询这张表来决定移动方向。这样连续按、同时按多键、长按都变得非常自然。另外我要特别提醒一个细节不要用event.preventDefault()去阻止浏览器默认行为。方向键和空格键在页面里会触发滚动如果你不阻止玩游戏的时候页面会上下乱跳。但反过来有些浏览器会拦截空格键的默认行为所以写法上要兼容。我通常会把监听对象分组移动方向交给方向键/WASD射击交给空格键这些事件统一用e.preventDefault()禁止默认动作但如果你的页面里还有别的表单或输入框要适当加一些过滤。2.4 数据结构和对象管理策略8x8编队意味着每一帧都要遍历判断64个敌机的状态而且子弹、爆炸特效、分数飘字这些对象的生命周期是动态的。用数组管理它们时推荐“每帧用过滤器替换旧数组”的方式而不是在循环里直接splice删除对象。原因是splice删除元素会改变数组索引导致循环跳项而用array array.filter(isAlive)的思路所有存活对象保留到新数组把删除动作延后到一整个遍历周期结束之后逻辑清爽、bug也少。如果你玩过复杂一点的动作游戏你可能会听说过“对象池”这个名词。在这个项目里子弹的发射频率高、存活时间短频繁创建和销毁对象确实会带来一定的垃圾回收压力。但8x8飞机大战这个量级还远远到不了必须用对象池的地步。就算每秒发射20颗子弹一次游戏两三分钟也就两三千个对象现代JavaScript引擎处理这个量级的对象毫无压力。所以我的建议是第一版先把代码写对写清楚用最直白的方式管理对象等真正遇到性能瓶颈了再用对象池来优化。不要一开始就优化那是过早优化。3. 核心细节解析与实操要点3.1 敌机编队的8行8列排列算法先说自己程序员怎么理解“8x8x”我的实现里8x8指的是敌机以8行8列排成一个矩形阵列最后一行的x代表“扩展难度”也就是每过一关阵列的下压速度和子弹发射周期会按比例增加。初始时每一架敌机的中心坐标可以这样算假设编队左上角的起始坐标为(offsetX, offsetY)行间距为rowGap列间距为colGap那么第i行第j列的敌机坐标就是x offsetX j * colGapy offsetY i * rowGap。用代码表示大致是这样const COLS 8; const ROWS 8; const COL_GAP 60; const ROW_GAP 48; const enemies []; for (let row 0; row ROWS; row) { for (let col 0; col COLS; col) { enemies.push({ x: 80 col * COL_GAP, y: 60 row * ROW_GAP, width: 40, height: 30, alive: true, row, col }); } }这种矩阵排列的好处是你可以在每一帧里用一个统一的“编队速度”变量来控制整组敌机的运动方向预定。到了边界之后整体反向并下移这样只要改一个变量所有敌机的运动行为就都变了非常省心。另外保留row和col字段方便你在特殊关卡里让某一行敌机拥有不同行为比如最下面一行是红色且速度更快这种扩展性是这个结构的一个额外福利。3.2 子弹系统单发到双发的演变子弹的逻辑是整个游戏循环里最“高频”的部分。我通常把子弹维护成一个数组里面存每个子弹的x、y和speed速度为负数因为y轴向下为正向上发射要让y减少。每帧遍历数组更新坐标如果y 0就把它标记为“不存活”等过滤器统一清除。玩家可以发射子弹敌机也应该能发射子弹。但敌机发射的子弹要控制频率不然64架敌机同时射击满屏弹幕完全没法玩。我的策略是让每次到达一个发射节点时只从当前存活的敌机里随机挑两架开火每隔1.2秒触发一次。这样屏幕上的敌方子弹始终被控制在一个“有压力但不绝望”的范围。如果你希望游戏更硬核可以把间隔下调到0.6秒再把选取数量提高到4架。以下是子弹发射的核心逻辑片段let playerBullets []; function shoot() { playerBullets.push({ x: player.x player.width / 2 - 2, y: player.y - 8, speed: -600, width: 4, height: 12, alive: true }); }子弹的碰撞箱不要做得和贴图一样大通常要比视觉稍小一圈这样玩家在极限操作时手感更宽容。我第一次做的时候碰撞箱和子弹像素一样大结果玩家躲子弹总感觉“明明错开了还是被打中”体验非常糟糕。后来把子弹碰撞箱缩小到视觉大小的一半游戏手感立刻提升了一个档次。3.3 碰撞检测为什么“看起来很准”还是会被说作弊基本的碰撞检测方式有两种矩形碰撞AABB和圆形碰撞。飞机大战这种块状物体居多的游戏用AABB就够了——两个矩形相交就认为碰撞发生判断条件是function rectHit(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; }这个公式一旦写对基本是零调试的。但要注意的是子弹速度高的时候可能出现“隧道效应”上一帧子弹还在敌机左边下一帧已经跑到敌机右边去了中间跨越的距离超过了敌机的宽度矩形检测就会漏判。解决方案有三种降低子弹单帧移动距离限制速度、用上一帧和当前帧之间连线段做检测、或者把子弹碰撞盒在运动方向上拉长。飞机大战里子弹速度通常在每帧10像素以内用第一种方案最省事控制速度上限让子弹的移动量不超过敌机宽度的一半基本就不会出现隧道问题。关于碰撞后的表现我还想强调一下“反馈”设计。玩家看到子弹打中敌机必须立刻得到视觉和声音反馈否则会觉得自己打击无效。我做了两层反馈第一层是打中后敌机闪烁一下、分数飘出来第二层是爆炸粒子特效用20个小色块向外飞散经过0.3秒后透明消失。这些细节虽然增加了一点代码量但它们决定了游戏是“像个能玩的Demo”还是“像个正经作品”。3.4 计分与生命系统数值平衡的第一课分数系统的第一版完全可以做成“每架敌机固定10分”但玩一会儿你会觉得无聊。我后来增加了分层最上面两行的敌机是10分中间四行20分最下面两行30分。因为最下面两行离玩家最近、威胁最大理应给更高分值。分数飘字动画用一个小数组维护包含文字内容、坐标和存活时间每帧把y往上移一点、透明度降低一点0.8秒后消失。生命系统方面我设计了3条命和1秒无敌帧玩家被敌机或敌弹击中后生命减1自机原地闪烁1秒通过每0.1秒交替设置可见性实现期间不参与任何碰撞。这一步非常关键——如果没有无敌帧玩家会因为“连续碰撞”瞬间失去所有生命挫败感极强。无敌帧结束后如果还有命游戏继续命为0游戏状态切换到“Game Over”显示本局得分并提示按键重新开始。4. 实操过程与核心环节实现4.1 创建HTML骨架和Canvas画布动手第一步新建一个index.html不需要任何外部库。核心就是把Canvas作为游戏舞台并配合keydown/keyup事件捕获用户的键盘输入。为了让游戏区域在不同屏幕上表现稳定我固定了画布尺寸为800x600然后通过CSS把它水平居中。如果要在手机上玩可以给Canvas加一个max-width: 100%但内部逻辑坐标不变只需要额外监听touchmove事件。!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 title8x8 飞机大战/title style body { margin: 0; display: flex; justify-content: center; align-items: center; height: 100vh; background: #1a1a2e; overflow: hidden; } canvas { border: 2px solid #e94560; background: radial-gradient(circle at center, #16213e, #0f0f1f); } /style /head body canvas idgameCanvas width800 height600/canvas script srcgame.js/script /body /html这里特别建议把game.js单独拆出来写而不是全塞在HTML的script标签里。原因有二一是方便用浏览器开发者工具打断点调试二是逻辑文件独立后后续想把Canvas改成WebGL、把键盘改成手柄输入都不需要大改页面结构。项目场景虽然是零依赖但“代码组织习惯”是为将来更复杂的工程做准备的。4.2 主循环requestAnimationFrame与时间步长主循环是任何游戏的心脏。网上很多教程会直接写setInterval(update, 16);我劝你不要这么干。setInterval连隔多久执行都无法精确控制还可能因为浏览器标签页切换到后台而被强制节流甚至完全暂停。requestAnimationFrame才是浏览器专门为动画和游戏提供的机制它会在每一帧屏幕刷新前自动调用你传入的回调函数并且当页面不可见时长自动暂停不消耗多余资源。正确的主循环写法是把“逻辑更新”和“画面绘制”放在同一帧里并计算间隔时间let lastTime 0; function gameLoop(timestamp) { const dt Math.min((timestamp - lastTime) / 1000, 0.05); lastTime timestamp; update(dt); // 逻辑更新 render(); // 画面绘制 requestAnimationFrame(gameLoop); } requestAnimationFrame(gameLoop);注意Math.min(dt, 0.05)这行当浏览器标签页被切到后台再切回来时timestamp会出现一个很大的跳变如果不加限制dt会变得非常大所有对象会瞬间移动一大段距离——也就是“物体穿越”现象。把dt限制在0.05秒约一帧的3倍就算从后台回来也不会出现明显的爆炸性位移。4.3 按键监听与状态管理我在第2.3节提到要维护按键状态表代码实现大概是这样的const keys {}; document.addEventListener(keydown, e { e.preventDefault(); keys[e.code] true; if (e.code Space) { shoot(); } }); document.addEventListener(keyup, e { keys[e.code] false; });然后在update函数里读取按键状态处理自机移动const MOVE_SPEED 400; function updatePlayer(dt) { let dx 0; if (keys[ArrowLeft] || keys[KeyA]) dx - 1; if (keys[ArrowRight] || keys[KeyD]) dx 1; if (keys[ArrowUp] || keys[KeyW]) dy - 1; if (keys[ArrowDown] || keys[KeyS]) dy 1; player.x dx * MOVE_SPEED * dt; player.y dy * MOVE_SPEED * dt; player.x Math.max(0, Math.min(canvas.width - player.width, player.x)); player.y Math.max(0, Math.min(canvas.height - player.height, player.y)); }这里每一次都做Math.max和Math.min的边界钳制是为了防止战机飞出画面。我见过一些半成品代码战机飞到画面外还能继续开火感觉特别出戏。钳制的写法从上到下都有很机械化但少了它游戏就不完整。关于连发我又加了额外限制按住空格键会让子弹连续射但要控制射速否则按着不动就会把子弹铺满整个屏幕。我用一个shootCooldown变量每次发射后把它设为0.15秒每帧用dt递减归零后才能继续发射。这个设计的好处是玩家可以按住空格不放也能通过节奏控制打出不同密度的火力。4.4 敌机编队的移动与碰撞检查完整流程敌机编队整体是“一个大队移动而不是每一架各自随机乱飞”这样游戏才有阵型和规律感。我的实现方式是维护一个全局的编队对象const fleet { dir: 1, // 1为向右-1为向左 speed: 80, // 横向移动速度像素/秒 dropStep: 24, // 碰到边界时下降的像素 x: 70, // 整体左上角x y: 60 // 整体左上角y };每帧更新时计算整体x的偏移量然后判断是否超出左右边界。一旦超出就反向并把y增加dropStep。然后遍历整个阵列用这架敌机的行列坐标算出绝对位置逐个检查是否和子弹碰撞、是否和玩家碰撞。这样做的复杂度是O(rows x cols)在当前规模下完全没问题。移动判定示例function updateFleet(dt) { fleet.x fleet.dir * fleet.speed * dt; if (fleet.x COLS * COL_GAP canvas.width - 40 || fleet.x 40) { fleet.dir * -1; fleet.y fleet.dropStep; } }这里我留了40像素的安全边距避免敌机阵列整体贴边导致最外侧敌机离边框太近看起来像是“被墙挡住的撞墙判定太突然”。这个边距数值越小玩家会觉得敌机贴边反弹越“硬”越大则越“软”。40是我试过之后觉得最自然的数值。碰到敌机和子弹碰撞后把敌机的alive标记为false播放爆炸反馈当编队中所有敌机都死亡时触发下一关重置编队到初始位置把speed乘以1.15、dropStep加几像素然后再把shootCooldown缩短一点。就这样难度通过数值迭代螺旋上升。4.5 渲染细节绘制自机、敌机、子弹与界面Canvas绘制本身不复杂但一些细节能让画面质感提升不少。自机我用一个三角形加两侧机翼来画核心是用ctx.moveTo和ctx.lineTo画出多边形填充渐变蓝色。敌机则简单一点每行用不同颜色这样玩家能直观区分哪些是高分行敌机。子弹我直接用fillRect画一个长条玩家子弹是黄色的敌方子弹是红色的。关键绘制逻辑大致如下function drawPlayer() { ctx.save(); ctx.translate(player.x player.width / 2, player.y player.height / 2); ctx.beginPath(); ctx.moveTo(0, -14); ctx.lineTo(10, 10); ctx.lineTo(0, 4); ctx.lineTo(-10, 10); ctx.closePath(); ctx.fillStyle #4fc3f7; ctx.fill(); ctx.restore(); }这里用了ctx.save()和ctx.restore()把坐标系平移到了自机中心这样绘制时不需要每次手动计算三角形的绝对顶点也不影响后续其他内容的绘制。边框、命数、分数这些HUD信息每次渲染时用一个单独的drawHUD()函数处理保持在最顶层。还有一个容易忽略的点背景。纯黑背景玩久了眼睛容易累而且视觉上没有层次。我可以在画布底部画一条淡淡的动态星空背景用一个数组保存几十颗星星的位置和速度每帧让它们缓慢向下移动超出底界就重置到顶部。虽然不影响玩法但它能强烈地提升“游戏感”过来人经验新手做游戏经常忽略这种“视听反馈”导致代码跑通了却没有游戏的感觉。5. 常见问题排查与避坑实录5.1 方向键控制页面滚动自机不移动这是最典型的“第一次做网页游戏”的踩坑点。默认情况下方向键和空格键会让页面元素滚动如果你的页面高度超过一屏按方向键时页面会滚来滚去而自机却不动。解决办法是给keydown事件加e.preventDefault()把默认行为屏蔽掉。但要注意如果你在页面上还有输入框要接收方向键不要无条件阻止可以用e.target判断事件源是否来自输入框。我的标准写法document.addEventListener(keydown, e { if ([ArrowUp, ArrowDown, ArrowLeft, ArrowRight, Space].includes(e.code)) { e.preventDefault(); } keys[e.code] true; });还有一点容易被忽略keydown的e.repeat属性。如果你按住方向键不放浏览器会持续触发keydown事件而且重复触发的间隔由系统按键重复率决定不是由游戏帧率决定。如果你在keydown里直接做坐标加减会因为重复率不稳定导致移动速度忽快忽慢。这就是我们必须维护“按键状态表”、每帧统一读取状态再算位移的原因。这是新手最容易出错的地方。5.2 碰撞检测“有延迟”或者“完全不触发”“完全不触发”通常有两个原因。第一子弹或敌机的坐标不是每帧更新比如你只在按空格时创建了子弹但忘了在主循环里对子弹数组做遍历更新导致子弹刚发射出来就静止在原地自然打不到后来移动的敌机。第二碰撞条件写反了。rectHit(a, b)函数判断的顺序不影响结果但如果你混用了对象字段比如用了bullet.size来表示宽高而碰撞函数里用的却是bullet.width那这个值永远是undefined判断永远不成立。“有延迟”则多半是碰撞的检测频率不够。requestAnimationFrame下每一帧检测一次60Hz下每帧约16.7毫秒前一次和后一次检测之间子弹可能移动了好几像素。如果你觉得打中判定“晚了一丁点”把子弹速度适当降低或者把敌机碰撞箱扩大几像素即可。推荐做法是在敌机对象里留一个hitBox膨胀系数统一调整而不是把宽度写死。5.3 游戏越玩越卡帧率从60掉到40很多人第一次写这个项目前期帧率很稳越往后期越卡。到时候先检查数组里是不是堆积了大量“已死亡但还没清理”的对象。尤其是爆炸粒子、分数飘字、敌方子弹这些动态数组如果只负责“添加”不负责“清理”到最后每一帧都要遍历几千个无意义对象自然卡顿。解决方案是组件化清理每帧update结束后对所有动态数组执行filter剔除非存活对象。注意一定要用“生成新数组”的方式而不是在循环里splice原因我在2.4节已经详细说过。写成代码是这样playerBullets playerBullets.filter(b b.alive); enemyBullets enemyBullets.filter(b b.alive); particles particles.filter(p p.life 0 p.alpha 0);我用一个开关enableMemoryCheck true在每100帧时打印一下数组长度用来观察峰值。如果某类数组长度突破了几千就说明清理逻辑有漏网之鱼。这算是一个比较实用的调优手段。5.4 敌机反弹时“穿墙”或整体越界敌机编队整体在左右边界自动反弹但如果你在计算时没有把每架敌机的宽度也算进去就会看到最外侧的敌机一半已经超出画布边界了才反弹回来。我的做法在前面展示过边界判断时预留了40像素边距比最外侧敌机的一半宽度还要大一点。如果追求更精确可以实时计算编队的总宽度const fleetWidth COLS * COL_GAP - (COL_GAP - 40); if (fleet.x fleetWidth canvas.width - 10 || fleet.x 10) { fleet.dir * -1; fleet.y fleet.dropStep; }这里把“飞机本身宽度的余量”纳入计算边界判断会更精准。有些实现还会在反弹时播放一个清脆的提示音在视觉上也在反弹瞬间把整个编队整体闪烁一下让玩家的注意力被引导到“编队改变方向”上。5.5 “按住空格键”射击体验与系统卡顿问题在5.1里我提过e.repeat这里再展开一点。直接监听keydown并发子弹同时按住方向键和空格键某些键盘会触发重复的keydown事件导致子弹一次性连发两发或三发体验很怪。正确做法是把“是否在播放射击动作”交给主循环的shootCooldown去管keydown里只维护一个isFiring状态这样按住与点按不会混乱。另外如果你发现按住空格射击时页面明显卡顿多半是子弹对象的创建数量没有节制。特别是配合5.5中的filter清理如果每帧都允许发射且不设冷却子弹数量会以指数级增长。我的建议是给发射动作加一个最低冷却间隔0.12~0.18秒同时一次发射只产生1~2颗子弹这样屏幕上的活跃子弹始终控制在50颗以内对渲染没有压力。6. 项目延展与个人经验总结8x8飞机大战写完之后我给它加了好几个“进阶功能”每一个其实都是新知识点。最推荐的第一个扩展是“关卡波次系统”不是简单地把敌机重新排列而是每过一关换一种阵型比如第三关改成V字阵第四关改成菱形阵。阵型变换本质上是“给定参数重新计算每个敌机的初始位置”但游戏可玩性立刻翻倍。第二个推荐是“道具掉落系统”Boss或敌机有概率掉出两种道具加快射速的R和加一条命的H。道具掉落会引入“移动矩形与玩家矩形碰撞”的判定场景难度不大但很锻炼面向对象的编码习惯。第三个推荐是音频用Web Audio API合成射击声和爆炸声不需要引入任何音频文件十几行代码就能搞出合格的音效能让作品完整度再上一个台阶。如果你打算把这个项目做成简历里可展示的作品我建议再做一项“工程化改造”把逻辑拆分成Player、EnemyFleet、BulletManager、ParticleSystem等几个模块配合requestAnimationFrame的清晰主循环结构这样即使实际游戏逻辑不算复杂从代码组织层面上也体现了作为一个开发者的基本工程素养。最后说一点我个人在这个项目上最有感触的地方别小看“看起来很简单”的小游戏。飞机大战的代码总量写出来可能也就是六七百行但它逼着你把“事件驱动”“状态管理”“碰撞检测”“帧循环”这些前端核心概念全部用到实处。很多人在简历里写“熟悉JavaScript”但如果让他现场把这个小游戏从零写一遍大概率是写不利索的。反过来说你要是能不看参考、独立把这个项目从零写到能玩、能调难度、能处理边界情况和性能问题你对JavaScript“基本功”的掌握程度是经得起问的。这个项目我前后共写了三遍每一次重写都能发现以前设计的不足——第一版全是全局变量第二版开始用对象组织逻辑第三版才真正理解“状态机”和“数据驱动”的含义。如果有朋友正在学前端我特别推荐他把它当作一个“自我检验”的里程碑项目写一遍你的JS基础会明显上一个台阶。