企业官网建设流程全解析

1. 为什么我要徒手写一个"Apollo-11"

先说清楚，这个项目的全称叫"Apollo-11"，乍一听像登月，但其实它是我花了将近两个月时间从零写出来的一个月球登陆模拟器，运行在浏览器里，不需要安装任何额外软件，打开页面就能玩。核心玩法就一句话：你驾驶一个登月舱，在燃料有限、引力恒定的情况下，通过调整推力方向和大小，尽量平稳地降落到指定着陆区。听起来很简单，但真正实现起来，涉及物理模拟、输入控制、状态管理、碰撞检测、HUD渲染这些环节，一环扣一环，任何一个地方处理不好，体验都会直接崩掉。

我当时做这个项目的动机特别朴素：市面上能搜到的开源月球登陆游戏很多，但要么是纯JavaScript写的老古董，代码基本没法维护，要么是商业项目，闭源不说，玩法逻辑还套了一层又一层营销系统。我想要的是一个结构干净、物理真实度可控、方便别人拿去改着玩的版本。于是干脆自己写了一个，顺便把整个开发过程踩过的坑都记录下来。

这个项目适合谁来参考？我觉得有三类人特别对口：

• 刚学完前端基础、想接触游戏循环和物理模拟的开发者；
• 正在做小型仿真类项目、需要处理"实时计算 + 状态机 + 渲染"这套组合的人；
• 单纯想给自己找一个有趣玩具、不想花一分钱还想玩到顺手的复古风格游戏的玩家。

如果你是第一次接触这类项目，别担心，我会把物理公式、渲染逻辑和代码结构全部拆开讲清楚。你不需要有游戏开发经验，只需要懂一点JavaScript基础，就能跟着思路走一遍。如果你已经写过一些Canvas动画，那这篇文章里的几个优化思路和调试技巧，应该能帮你省下不少时间。

2. 项目整体设计与思路拆解

2.1 这个项目到底解决什么问题

先给这个项目定个位。很多人在浏览器里做动画，习惯的做法是"每帧直接改坐标"，比如 x += speed，然后画上去。这在简单场景下没问题，但一旦涉及加速度、减速度、燃料耗尽后的惯性滑行、碰撞判定，这种粗暴方案就不够用了。因为它缺少一个关键概念：力和速度之间不是简单叠加，而是要通过加速度这个中间量来转换。

Apollo-11的核心需求就是把这件事做对。玩过这类游戏的人都知道，月球登陆最恐怖的一点是：重力一直在把你往下拉，但你手里的燃料是有限的。如果你一直开着引擎，燃料很快烧光，然后你就只能眼睁睁看着登月舱加速砸向地表。所以整个项目的物理核心是三维状态变量（高度、速度、加速度、燃料余量）的实时迭代，界面只是把这些数字可视化。

我选择用浏览器加Canvas来实现，原因很直接：跨平台、零安装、方便分享。我用Canvas而不是DOM元素做渲染，是因为要在同一帧里同时画背景星群、月球表面轮廓、登月舱的火焰尾迹、爆炸粒子、HUD数值层，DOM操作在这种高频重绘场景下性能很差，Canvas的像素级绘制反而更合适。

2.2 为什么物理模型要简化成"一维垂直"模型

真正的月球登陆其实是一个二维甚至三维问题，登月舱不仅有垂直速度，还有水平速度，需要同时控制姿态。但在Apollo-11这个项目里，我做了一个刻意的取舍：只保留垂直维度，登月舱只能上下移动，地面是一排像素纹理，登月舱的x坐标固定。

为什么这么干？因为核心玩法是"控制下降速度"，水平方向的漂移会引入姿态控制、角度计算、侧向碰撞检测，复杂度翻倍。对于一份以教学为目标、让大家能看懂的代码，垂直模型已经足以表达物理模拟的核心思想，同时把渲染和控制的注意力聚焦在最有价值的部分。

也别觉得一维模型简单就掉以轻心。哪怕只需要算垂直方向，也至少要处理：

• 重力加速度的恒定施加；
• 引擎推力打开时的反向加速度；
• 燃料消耗对推力的直接影响；
• 落地瞬间的速度判断（什么样的速度算安全着陆，什么样的速度算坠毁）。

这几个点正好对应了状态变量里的velocity、acceleration、fuelMass、altitude，整个物理逻辑就围绕这四个变量转。我把它们放在一个对象里统一管理，每次物理更新统一传递，避免散落在各个函数里导致状态混乱。

const craft = { altitude: 1500, // 当前高度，单位米 velocity: 0, // 当前速度，单位米/秒，正值表示向上 acceleration: 0, // 当前加速度，单位米/秒² fuelMass: 100, // 剩余燃料，单位千克 mass: 500, // 空载质量 + 燃料质量 = 总质量 thrustPower: 2000 // 引擎推力，单位牛顿 };

这个对象是整个游戏的核心数据源，所有模块都围绕它运行。

2.3 渲染层与逻辑层的彻底分离

另一个我从头就决定的事是：物理计算和画图绝对不能混在一个函数里。很多新手写游戏喜欢这样写：

function update() { craft.velocity += gravity; craft.altitude += craft.velocity; ctx.moveTo(...); ctx.lineTo(...); ctx.fill(); }

这种写法的坑在于：一旦渲染逻辑调整（比如换了配色、加了动画），物理参数就可能被误改。而且如果你想做后台模拟（比如AI自动降落测试），没有渲染也能跑逻辑，但代码拆不开就很尴尬。我当时的做法是设了两个独立模块：

• physics.js：只导入craft对象和输入状态，计算出新的craft状态，不碰任何Canvas API；
• renderer.js：只接收craft当前状态和场景参数，负责把数字变成像素，不修改任何物理状态。

中间通过一个循环协调器串起来：每帧执行【接收输入→更新物理→渲染画面→输出HUD信息】。这样做的最大好处是，调试的时候我可以直接在浏览器控制台手动改动craft.altitude，然后触发渲染方法，立刻就能看到画面变化，不需要重新跑完整个游戏流程，排查问题效率高很多。

3. 核心细节解析与实操要点

3.1 物理模拟的公式和参数选择

物理引擎是这个项目的大脑。我不打算引入任何第三方物理库，因为垂直降落模型用几个经典公式就够了。你需要理解的核心公式只有三个。

第一个是牛顿第二定律：F = ma。在我的模拟里，物体受到的合力 = 引擎推力 - 重力。注意方向，推力向上，重力向下，所以写成：netForce = thrustPower - (mass * gravity) - dragFactor * velocity。把term rearrange一下，加速度就是netForce / mass。

第二个是速度更新公式：velocity += acceleration * deltaTime。这里deltaTime是上一帧到这一帧的真实时间差，单位秒。很多初学者会忽略deltaTime，直接velocity += acceleration。这在帧率稳定的情况下看起来没啥问题，但只要浏览器页面切到后台再切回来，帧率突变，物理状态就会飞掉。用了deltaTime之后，不管帧率是30还是60，运动速度都是稳定的。

第三个是位移更新公式：altitude -= velocity * deltaTime。注意这里用的是减号，因为高度是往下减的，登录舱越降越低。

我选择的参数是基于一个简化假设：月球重力加速度取1.6 m/s²，和真实月面相当。登月舱空重定为300千克，满载燃料100千克，引擎最大推力2000牛顿。按照这个配置，当燃料过半、总重量约350千克时，最大加速度大约是(2000 - 350*1.6) / 350 ≈ 4.1 m/s²向上，足以与重力对抗但又不至于瞬间飞到天上，操作手感正好。

如果这段话里的计算你看得有点晕，我换个方式解释：重力就像你站在跑步机上，传送带一直把你往地面拉。引擎推力是你能踩的加速踏板，踩得越狠，越能抵抗传送带的力量。燃料就是油表，油表空了，踏板就踩不动了。整个登陆过程就是你一边盯着高度和速度，一边控制油门，争取在触地那一瞬间速度归零。

3.2 输入系统：为什么只用了空格和方向键

Apollo-11的操控设计非常克制：玩家只需要按两个键——空格键开/关引擎，方向键左右调整推力大小。一开始我也想过加入鼠标拖动控制，但后来发现键盘输入在这个场景里是最直观、最不容易出错的。

按键状态我用了个简单的对象存储：

const inputState = { thrustOn: false, throttleLevel: 0 // 0 到 1 之间 };

监听键盘事件时，我不直接在事件回调里改craft状态，而是只改inputState，等下一帧物理更新时再读取。原因是我希望即使连续按很多次键，物理计算也严格按帧更新，不会因为事件触发频率不稳定而出现状态跳变。这个设计叫"缓存输入、延迟消费"，是游戏开发里非常基础但很实用的模式。

方向键控制推力大小的逻辑我做了个平滑增减：每次按键改变0.1，并在输入状态里加了一个目标值。物理更新时不会一步到位，而是用插值逼近：

currentThrottle += (targetThrottle - currentThrottle) * 0.05;

这个平滑处理是实际体验中一个很容易被忽略但直接影响手感的细节。因为月球登陆最怕的就是操控过于灵敏——你按一下方向键推力从0猛增到100%，登月舱一下蹿上去，下一秒燃料就掉了大半。加了平滑之后，操控变得更有"推进感"，玩家能感觉到推力的变化过程，而不是瞬间跳变。

3.3 着陆判定与碰撞逻辑

碰撞逻辑是这个项目里最有意思的部分，因为它直接决定了"成功还是爆炸"的边界。

着陆判定的标准是：当登月舱底部触碰到地面像素时，检查当前垂直速度。如果速度绝对值小于某个阈值（我定的是每秒2米），判定为安全着陆；否则判定为坠毁。这个阈值不是拍脑袋定的，而是参考真实登月舱的实际着陆要求——速度过大时机械结构无法吸收冲击，在游戏里我放宽了一点点，让普通玩家经过几次尝试能过关。

但这里有几个隐藏的坑，我一个个说。

第一个坑是地面Y坐标是从上往下计算的。Canvas的坐标系和数学坐标系不同，y轴方向是向下的。登月舱的屏幕位置是screenY = groundY - altitude，如果搞反了方向，登月舱会越飞越下面，重力方向也会反。

第二个坑是高度是否是负数。当登月舱着陆后，物理更新还在跑，重力还在起作用，如果高度已经为0而不做特殊处理，下一帧高度会变成负数，登月舱会陷入地面以下。我在碰撞检测里做了钳制：高度最小为0，速度为0时不再变化。

第三个坑是引擎喷口位置的判断。登月舱底部本身有一定高度，如果你直接用登月舱中心点算碰撞，视觉上就会出现"底部还没碰到地面，就已经判定撞击"的错觉。我的做法是为登月舱定义一个底部偏移量，碰撞检测用altitude - craftHeight/2这个值，确保只有真正的底部触地才算着陆。

3.4 视觉渲染与用户反馈设计

渲染部分我做了几个层次：

• 背景层：一个静态星群，由几百个小点组成，深度固定，不随登月舱移动，用来营造太空感；
• 地形层：一系列随机高度的线段，生成一次后保持不变，模拟月球崎岖表面；
• 登月舱层：一个梯形舱体 + 下方引擎火焰，火焰的尺寸根据当前推力大小动态变化；
• HUD层：显示高度、速度、燃料、推力等信息，文字直接绘制在Canvas上，不占用额外DOM节点。

这里我重点讲讲火焰效果的实现。引擎火焰看起来像一团高速抖动的光柱，其实底层是利用了每帧重新生成随机偏移量：

const flicker = Math.random() * 8; ctx.beginPath(); ctx.moveTo(cabinLeft, cabinBottom); ctx.lineTo(cabinLeft - flameBase + flicker, cabinBottom + flameLength); ctx.lineTo(cabinRight, cabinBottom); ctx.lineTo(cabinRight - flameBase - flicker, cabinBottom + flameLength); ctx.fill();

每次重绘火焰边缘的长度都会有无规律的抖动，视觉上就是火焰在喷射。颜色我做了两个颜色渐变：内焰偏白，外焰偏橙，用Canvas自带的渐变填充实现。整体风格非常复古，像素感强，和这个项目的怀旧基调一致。

HUD的排版也有讲究。高度、速度、燃料这些数字要足够大，一眼扫过去就能抓到。我用了Canvas的fillText，并且每一帧都在绘制前先clearRect清掉旧文字区域，防止文字重叠。这里有个小经验：如果清屏范围只设在文字区域，而不是整个Canvas，可以大幅减少不必要的重绘，同时保持背景星群不闪烁。

4. 实操过程与核心环节实现

4.1 开发环境与项目结构

我用纯HTML + CSS + JavaScript搭建，没有引入构建工具、没有框架、没有依赖，目的就是保持项目能被直接双击打开。你如果愿意，也可以用npm跑一个简单的本地服务器，但这并非必需。

项目最终结构如下：

apollo-11/ index.html css/ style.css src/ main.js // 入口，启动游戏循环 physics.js // 物理更新 renderer.js // 渲染绘制 input.js // 键盘监听 sound.js // 简易Web Audio音效 state.js // 游戏状态（运行中、着陆成功、坠毁）

index.html里只挂了一个canvas节点，加载顺序是先state和physics，再renderer，最后main。为了让代码更清晰，我用了原生ES Module方式加载模块，在浏览器里可以直接用import/export，无需打包器。

4.2 游戏主循环的实现

主循环是整个项目最中央的部分。我使用requestAnimationFrame作为驱动，而不是setInterval，因为requestAnimationFrame会在浏览器刷新屏幕时自动同步，避免撕裂，同时在页面不可见时自动暂停，节省CPU。

let lastTime = 0; function gameLoop(currentTime) { const deltaTime = (currentTime - lastTime) / 1000; lastTime = currentTime; if (gameState === 'playing') { updatePhysics(deltaTime); } render(deltaTime); requestAnimationFrame(gameLoop); } requestAnimationFrame(gameLoop);

我把deltaTime限制在最大0.05秒。原因是如果页面切到后台几秒再切回来，浏览器会补一次极大的deltaTime，物理系统在一个超长帧里跑，登月舱可能直接穿透地面。限制到一个合理值后，即使切回来也只是"剧情跳跃"，不会出现物理爆炸。

updatePhysics内部的完整流程是这样的：

function updatePhysics(dt) { // Step 1: 根据输入更新推力状态 const thrust = inputState.thrustOn ? craft.thrustPower * currentThrottle : 0; // Step 2: 计算合力 const gravityForce = craft.mass * GRAVITY; const netForce = thrust - gravityForce; // Step 3: 更新加速度和速度 craft.acceleration = netForce / craft.mass; craft.velocity += craft.acceleration * dt; // Step 4: 更新高度，注意direction craft.altitude -= craft.velocity * dt; // Step 5: 消耗燃料 if (inputState.thrustOn) { craft.fuelMass -= FUEL_CONSUMPTION_RATE * dt * currentThrottle; if (craft.fuelMass <= 0) { craft.fuelMass = 0; inputState.thrustOn = false; // 燃料耗尽自动关引擎 } } // Step 6: 着陆判定 if (craft.altitude <= 0) { craft.altitude = 0; if (Math.abs(craft.velocity) <= SAFE_LANDING_SPEED) { setGameState('landed'); } else { setGameState('crashed'); } } }

代码顺序有讲究。先更新力、再更新速度、再更新位置，这是标准半隐式欧拉积分，比纯显式欧拉更稳定。燃料消耗我放在位置更新之后，这样如果玩家在这一帧触底，即使还剩一点点燃料，也不会先扣燃料再判定。实际体验中这种微小的顺序差异能避免一个很尴尬的情况：燃料刚好烧完的同时刚好着陆，结果被判定为坠毁。

4.3 我如何做参数平衡

参数平衡是这个项目里比较耗时间的部分。一开始我把重力设为9.8（地球重力），结果发现登月舱下降得太快，玩家几乎没有反应时间；后来直接把月面重力1.6带入，操作手感立刻舒服很多。

接着是燃料消耗速度。如果消耗太快，玩家还没搞懂怎么控制推力，燃料就空了，挫败感很强；如果消耗太慢，玩家可以一直开着引擎飘在空中，游戏没有压力。我最后选了每秒消耗8千克燃料，满载100千克，意味着理论上全力喷射可持续12.5秒。这个时长刚好营造出"有点紧张但还能思考"的节奏。

推力上限也做过调整。如果推力调得太高，登月舱可以轻易克服重力并升空，玩家只需要把自己拉回空中再来一次，等于没有惩罚。我最后把最大加速度设成重力的2.5倍左右，配合惯性，着陆成功需要玩家主动控制推力的时机，而不是无脑按住空格。

这里我强烈建议你用"开场参数重置 + 具体场景测试"的方式来做平衡，而不是每次手动在控制台改完再重开页面。我写了一个简单的参数面板，用HTML的range控件实时调整重力、推力、燃料消耗率，每次调完立刻在游戏里跑一遍，感受几秒，然后记录手感。这比改代码刷新页面高效太多了。

4.4 音效设计与Web Audio API

一个没有声音的登陆模拟器就像看默片，紧张感和成就感都会大打折扣。我给项目加了三类音效：引擎轰鸣声、警告提示声、着陆成功/坠毁音效。

引擎轰鸣音我用Web Audio API生成白噪声，并加了一个低通滤波器来柔化：

function createEngineNoise() { const context = new AudioContext(); const bufferSize = context.sampleRate * 2; const buffer = context.createBuffer(1, bufferSize, context.sampleRate); const data = buffer.getChannelData(0); for (let i = 0; i < bufferSize; i++) { data[i] = Math.random() * 2 - 1; } const source = context.createBufferSource(); source.buffer = buffer; source.loop = true; const filter = context.createBiquadFilter(); filter.type = 'lowpass'; filter.frequency.value = 200; const gain = context.createGain(); gain.gain.value = 0; source.connect(filter); filter.connect(gain); gain.connect(context.destination); return { source, gain }; }

引擎开启时，我会把gain.value平滑提升到0.4；关闭时，平滑降到0。这种渐变让声音听起来像自然渐入渐出，而不是瞬间爆音。需要注意的是，浏览器对自动播放音频有严格限制，必须等用户第一次点击canvas之后才能创建AudioContext，否则会被警告。我就在输入监听函数里做了一次懒初始化，用户第一次按空格时才创建音频上下文，之后就正常使用。

警告提示音则是在高度低于100米时激活一个周期性蜂鸣，频率大约每秒一次。因为高度越低，蜂鸣越急促，玩家会本能地感到压力增大，再配合HUD上高度数字变红，整个紧张感就出来了。这个设计简单有效，强烈推荐你加一个类似的渐进式警告机制。

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

5.1 登月舱直接穿过地面

这是新手最容易遇到、也是最诡异的问题。现象是登月舱一路向下，高度变成负数，越过了地面基准线，画面上完全消失。

排查思路是分两步。第一步，检查坐标系方向。如果altitude初始值是1000米，但屏幕渲染位置是groundY - altitude，那么登月舱应该出现在地面线上方。如果你在代码里写成groundY + altitude，那它就会从地面开始往下走，肯定穿地。第二步，检查物理更新顺序。如果先更新位置再更新速度，存在一种情况：上一帧速度很小，高度还有0.5米；这一帧速度突然因为重力加大而变成-10米/秒，位置更新后高度变成-9.5米。此时如果只在高度小于等于0时做碰撞检测，可能因为跳过了0直接变负数而漏判。

我建议在碰撞检测中做一个"穿透恢复"处理：

if (craft.altitude <= 0) { craft.altitude = 0; if (craft.velocity < 0) { craft.velocity = 0; } // 然后进入着陆判定 }

让速度也对0做钳制，防止负速度继续拉着登月舱向下。

5.2 燃料消耗和推力数值对不上

症状是HUD显示燃料明明还有一半，但推力输出已经明显不足，感觉升力不够。问题通常出在"燃料消耗率只是按时间消耗，而推力计算用的是另一个变量"这种状态不同步上。

比如你在input里设置throttleLevel = 0.5，在显示推力时用的是thrustPower * throttleLevel，但燃料在扣减时用的是FUEL_CONSUMPTION_RATE * dt，没有乘throttleLevel。结果就是开一半油门跟满油门烧的油一样多，那当然不合理。

我在项目里统一用了一个变量currentThrottle，所有推力计算、燃料消耗、音效音量、火焰长度全部依赖它。修改推力时只修改一个入口，杜绝了多处不一致的问题。排查这类问题最好的办法是在HUD上同时显示三个数：油门百分比、当前推力、当前燃料消耗率，只要这三者关系不对，一眼就能看出哪个环节脱节。

5.3 高帧率下物理异常快

如果主循环没有正确使用deltaTime，而是直接假设每帧是固定的16.7毫秒，那么在有120Hz刷新率的设备上，一切运动都会加速到2倍速。

解决办法就是我前面提到的，使用真实时间差deltaTime并传递到物理计算中。另外一个相关细节是：如果你的deltaTime是秒为单位，加速度公式里所有参数都按国际单位制计算；如果你不小心用了毫秒，那所有数值都会放大1000倍。我的习惯是写清楚注释：// deltaTime is in seconds。

5.4 着陆成功判定过于严格

一开始我把安全着陆速度阈值设得非常苛刻，只有小于0.5米/秒才算成功，结果我自己玩了十几次，没有一次成功降落，每次都因为"差一点点"而爆炸，挫败感极强。后来想起真实登月任务的着陆系统有缓冲支架吸收冲击，于是把阈值逐步放宽，最终定在2米/秒，再搭配一个"着陆成功"的粒子效果和音效来奖励玩家，整体反馈就好很多。

这个经验想说明的是：游戏参数的设定不仅要考虑物理真实，还要考虑玩家的心理预期和操作能力。物理模拟的目标应该是"让玩家在体验压力的同时，拥有成功的机会"，而不是无限逼近真实物理导致玩不了。

5.5 浏览器切后台后回来，登月舱不见了

切后台时requestAnimationFrame会暂停，所以画面不更新是正常的。但问题是物理更新也跟着暂停了，切回来时会有一个巨大的deltaTime。我前面已经提到加了一个deltaTime上限，但还有一个bug要注意：lastTime在切后台时的赋值问题。

如果lastTime是暂停前的最后一帧时间，切回来时currentTime会变成当前时间，两者差值就是后台停留的总时长。这个值你直接除以1000作为deltaTime，即使限制到0.05，也还是会让物理状态往前走一小段，可能刚好把登月舱推到地面上。我的解法是：在visibilitychange事件里重置lastTime，让回归后的第一帧deltaTime为0，从而避免任何跳跃。

document.addEventListener('visibilitychange', () => { if (!document.hidden) lastTime = performance.now(); });

加上这个之后，再切换回来，游戏会从当前帧的状态无缝继续，玩家完全感觉不到异常。

5.6 常见问题速查表

6. 从Apollo-11到更大的仿真项目

写到这里，Apollo-11的核心内容其实已经讲完了。但我觉得还有必要聊一下这个项目的可扩展方向，因为在开发过程中我自己就设想过好几个升级路径，而如果你也想拿这个项目练手，下面的方向都可以作为下一步的目标。

第一步扩展是增加水平漂移。把一维模型升级为二维，意味着需要处理登月舱的水平速度、水平位置、倾斜角度，以及更复杂的着陆判定——不仅要看垂直速度，还要看水平方向和姿态角。这个升级带来的代码量增加大概是50%左右，但物理模型会更接近真实，玩法也会从"纯垂直控制"变成"接近现代飞行游戏的操作体验"。

第二步扩展是自动降落AI。我的初步设想是写一个简单PID控制器，根据当前高度和速度实时计算油门输出。这个功能价值极大，因为当你调完物理参数后，你可以让AI自动降落几百次来统计成功率，快速验证参数是不是合理，而不是每次都靠人手去试。

第三步扩展是关卡机制。比如不同的月面地形、不同的初始高度和燃料限制、不同的着陆目标区域，每次开局随机生成一关。这个扩展侧面需要重点改造的是地形生成算法，从简单的随机线段变成平滑的分形曲线或斜坡，同时支持多个降落平台。

第四步扩展是画质升级。当前是纯Canvas绘制的矢量风格，可以换成加载贴图资源，加入粒子系统模拟更真实的着陆尘埃和引擎尾焰，再叠加一层局部阴影和辉光。毕竟有了稳定的物理系统和游戏逻辑，美术替换只是时间问题。

最后，如果你也想自己写一个类似的模拟器，我的建议是不要一开始就追求复杂功能，先把这个最简版跑通，然后再逐个加模块。我从"只有引擎和重力"的第一版，到最终集成音效和AI提示，总共花了两周多时间，大部分时间都花在调手感上，而不是写代码上。物理参数的设计，永远比代码本身更考验对游戏的理解。

我一个人在这里说再多，也不如你打开编辑器自己写一帧来得直接。挑一个周末，把Canvas画起来，把重力设成1.6，先感受一下月球上那种"慢而不可逆"的下坠感，然后你就会知道为什么这个看似简单的小游戏，能让人一玩就停不下来了。