零依赖H5逃脱游戏开发：Canvas物理与部署全流程

1. 项目概述与核心目标

1.1 游戏是什么，“Escape Fox Game"概况

Escape Fox Game是一个基于HTML5开发的2D横向卷轴逃脱类网页游戏，玩家控制一只被围困的小狐狸，在限定的关卡场景中寻找出口、破解机关、越过障碍，最终逃出险境。项目本身采用纯前端技术路线，核心代码为HTML5 + Canvas + 原生JavaScript，无需安装任何插件，浏览器打开即玩，同时适配桌面端和移动端触屏操作。

这个项目是我个人在业余时间完成的一个技术验证型作品。当时的目标很明确：不依赖任何游戏引擎（如Phaser、Cocos Creator），用最朴素的前端技术实现一个完整可玩的、有剧情氛围的2D解密逃脱游戏，并且在完成后把它部署到真实服务器上，实打实跑一遍“开发 - 联调 - 部署 - 数据观察”的完整链路。

从技术角度看，这个项目覆盖了游戏开发中几个最核心的模块：主循环与帧率控制、物理碰撞、精灵动画、事件系统、关卡数据驱动设计、音效调度、本地存档。从工程角度看，它又涉及静态部署、浏览器兼容、移动端适配、性能优化等常规前端项目同样要面对的问题。所以这篇博文不仅适合想做H5小游戏的开发者参考，也适合想了解“一个纯前端游戏项目从代码到上线全流程”的朋友阅读。

1.2 开发背景与解决的核心痛点

独立做H5小游戏，最大的痛点不是写代码，而是在没有引擎加持的情况下，如何保证游戏在不同设备上都有稳定流畅的表现。Escape Fox Game的整个技术选型都围绕这个痛点展开：

• 不用框架，是因为游戏逻辑本身不算复杂，框架引入的学习成本和包体开销不划算；
• 用Canvas而不用DOM，是因为游戏主循环每帧需要更新大量画面元素，DOM频繁重绘的性能瓶颈在移动端非常明显；
• 数据驱动关卡设计，是为了让后续关卡迭代不需要改动游戏逻辑代码，只需要编辑配置JSON，这个思维对齐了后端开发里“配置与逻辑分离”的最佳实践。

整个开发过程中，我在碰撞检测、触屏事件处理和音效兼容上踩了不少坑。这篇文章会把这几块最“脏”的细节摊开来写清楚，包括我后来用的解决思路和修正后的代码结构，方便你在自己项目里直接参考。

2. 内容整体设计与思路拆解

2.1 核心玩法与关卡框架设计

游戏的核心循环很简单：观察场景 → 找到线索 → 解开关卡机制 → 到达出口。为了避免“逃脱”题材做成一堆谜题的生硬拼接，我给每一关设定了明确的主题关键词：秘密洞穴、废弃猎场、冰封小溪、最后出口。关卡难度在机制组合数量上递进，而不是单纯调高数值：

这个设计的好处是：玩家每进入新关卡，只需要学习一个新增规则，认知负担小，也不会觉得重复枯燥。从开发视角看，每一个新机制实际上就是一个独立的JavaScript类（比如PressurePlate、MovingPlatform），后续想加玩法，只需要继承统一的Entity基类再注册事件，扩展性很好。

2.2 为什么坚持零依赖纯JavaScript方案

很多开发者拿到“做一个H5游戏”的需求，第一反应是上Phaser或者PixiJS。我不反对引擎，引擎确实提供了精灵、动画、物理、粒子等开箱即用的能力，但回到这个项目的实际情况，我坚持零依赖的原因有三个：

第一，包体控制。 Escape Fox Game整个项目的静态资源（JS + CSS + 图片 + 音频）加在一起不到1.5MB，对比一个最小化的Phaser项目至少几百KB的引擎本身，首屏加载速度完全不是一个量级。在弱网环境下，这点差距直接决定玩家愿不愿意等下去。

第二，逻辑透明。 用原生Canvas绘制画面，所有渲染、更新、碰撞的逻辑都在自己手里。出了问题可以一行行断点排查，不用去翻引擎文档猜“为什么这个组件没生效”。对于学习游戏开发原理来说，这比调引擎API有价值得多。

第三，部署自由。 纯静态项目意味着你不需要Node服务端、不需要构建流程（虽然我也写了构建脚本，但那只是简单的文件合并），任意一个能托管静态文件的服务器都够用，Nginx、OSS、GitHub Pages都可以直接跑。

2.3 项目整体模块划分

整个项目按职责拆成下面几个模块，这也是我后来复盘时觉得比较满意的地方——模块之间的依赖是单向的，非常适合个人项目维护：

code复制src/
├── main.js          // 入口：初始化引擎、加载首关卡
├── engine/
│   ├── loop.js      // 主循环：requestAnimationFrame 封装，固定时间步长
│   ├── input.js     // 输入管理：键盘 + 触屏事件统一封装
│   ├── audio.js     // 音频调度：基于 AudioContext，兼容自动播放策略
│   └── storage.js   // 存档：localStorage 封装
├── entities/
│   ├── player.js    // 小狐狸角色：移动、跳跃、受击、状态机
│   ├── platform.js  // 静态/动态平台
│   ├── hazard.js    // 尖刺等伤害物
│   ├── gate.js      // 机关门、压力板
│   └── exit.js      // 出口点
├── levels/
│   └── level1.js    // 关卡数据，按统一格式导出 JSON 对象
├── render/
│   ├── camera.js    // 相机跟随与平滑
│   └── sprite.js    // 精灵表裁剪与绘制
└── utils/
    └── helper.js    // 碰撞检测、向量计算等基础函数

这套模块划分对齐的是“引擎-实体-数据”三层结构。引擎不关心具体游戏内容，只管跑循环、管输入、管渲染；实体层承载游戏内所有对象的逻辑；关卡数据层是纯数据，逻辑层读数据生成实体。这样拆完后，我个人最大的感受是：调试某一关的时候，不需要在几百行里找到底哪个函数在控制开关门，直接改JSON属性就行。

3. 核心细节解析与玩法设计要点

3.1 关卡谜题的逻辑驱动方式

这个游戏里的所有机关交互，内部都建立在**“信号”**这个抽象概念上。开关、压力板是信号源，门、平台是信号接收器，信号源通过状态变更来触发接收器的行为。这个设计思路其实借鉴了电路逻辑里的“事件驱动”，在游戏代码里实现起来特别干净：

javascript复制// 信号源：压力板
class PressurePlate extends Entity {
  constructor(scene, config) {
    super(scene, config);
    this.activated = false;
    this.listeners = [];      // 接收器列表
  }

  // 当玩家/物体踩上时触发
  activate() {
    if (this.activated) return;
    this.activated = true;
    this.listeners.forEach(entity => entity.onSignal(true));
  }

  // 注册接收器
  addListener(entity) {
    this.listeners.push(entity);
  }
}

关卡配置里只需要声明“哪块板子连接哪扇门”：

json复制{
  "type": "pressure_plate",
  "id": "plate_1",
  "x": 120,
  "y": 300,
  "triggers": ["gate_1"]
}

这个做法的价值在于——后期加新关卡几乎不需要写新的交互代码。 只需要在关卡JSON里调整实体位置、类型和触发关系，游戏逻辑就会自动按配置运行。这和我们做业务系统时“用配置替代硬编码”的思路是一致的，也让我能在很短时间内做完10个关卡而不会把代码写乱。

3.2 碰撞检测与运动物理的关键取舍

2D平台跳跃游戏里，碰撞检测是最容易出“玄学Bug”的地方。Escape Fox Game最终采用的是经典的**“先移动水平轴，再移动垂直轴，逐轴检测、逐轴修正”**的方案，而不是一次性移动后再做整体碰撞解析。

javascript复制// 水平移动 + 碰撞
this.x += this.vx * dt;
this.resolveCollisions(this.x, this.y, 'horizontal');

// 垂直移动 + 碰撞
this.y += this.vy * dt;
this.resolveCollisions(this.x, this.y, 'vertical');

为什么不能合并一次性检测？因为如果两个轴同时移动后再判断碰撞，玩家撞到墙壁时会被“夹”在缝隙里，不知道该修正X还是修正Y，很难判断该往哪个方向反弹。逐轴检测则能保证：撞墙时只修正X，落地时只修正Y，判定结果非常稳定。

在具体的重叠判断上，我用的是AABB（轴对齐包围盒）判断，也就是两个矩形的相交测试：

javascript复制function checkCollision(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;
}

对于固定的静态平台，只需要做“玩家下落时是否踩到平台顶部”这一个方向的检测，就能避免“从侧面撞上平台却被当成站在平台上”的错误。做法是：只有玩家的垂直速度大于0（下落中），且上一帧的底部位置在平台顶部之上，才判定为落地。

“上一帧位置”这个信息很关键，因为如果帧率低、单帧位移大，玩家可能直接穿过薄平台而碰撞检测来不及反应。保存上一帧位置做差值的思路叫连续碰撞检测（CCD），可以显著降低隧道效应。

3.3 狐狸角色的动作与操作手感调优

角色手感是平台跳跃游戏的灵魂。如果跳跃高度不够、水平移动有延迟，玩家会立刻觉得“这游戏很难玩”。我在调手感时重点做了三件事：

跳跃裁剪（Jump Cut）：玩家起跳后如果松开跳跃键，垂直速度会立刻乘以一个小于1的系数（我调的是0.45），让跳跃高度变矮。这样玩家可以短按实现小跳、长按实现大跳，操作粒度更细，也更符合动作游戏的操作直觉。

地面判定缓冲：如果在空中按了跳跃键，但恰好差几帧才落地，那么系统会记录这个跳跃输入，并在角色落地后的200毫秒内自动触发起跳。这个机制对玩家实际操作体验的提升极大，尤其是从平台边缘跳出去的时候，不会因为晚按了半拍而出现“明明按了跳却掉下去了”的挫败感。

可变步长插值：为了兼顾性能和手感，物理更新采用固定时间步长（每帧模拟1/60秒的物理），而渲染则用requestAnimationFrame驱动。这样即使屏幕刷新率是120Hz或者只有30Hz，游戏内物理速度始终一致，不会出现“高刷显示器上游戏跑得飞快”的问题。

碰撞检测盒的设置也需要注意。绘制狐狸的精灵本身有视觉上的耳朵和尾巴，但如果碰撞盒完全贴合视觉外形，玩家会觉得“明明没碰到尖刺却掉血了”。我最终把玩家碰撞盒设置为角色躯干部分，比视觉尺寸略小——这里是宽为精灵宽度的55%、高为精灵高度的78%。这种“宽容判定”是保证公平感的核心。

3.4 音效触发的时机与工程加载策略

音效这块，最容易踩的坑是浏览器的自动播放策略。现在主流浏览器都要求用户与页面产生至少一次交互后，才能播放带声音的媒体内容。直接调用AudioContext会被拦截，播放不报错，但就是没声音。

我的处理方式是在游戏的“开始”按钮事件里初始化并恢复AudioContext：

javascript复制document.getElementById('start-btn').addEventListener('click', () => {
  if (audioCtx.state === 'suspended') {
    audioCtx.resume();
  }
  this.startGame();
});

音频文件本身我全部采用短音效缓存策略——在游戏加载阶段用fetch拉取并解码成ArrayBuffer，存入Map按名称索引。运行时触发音效就是直接从内存中播放，没有网络延迟。

实际测试下来，初始化的时机非常重要。 如果你在游戏加载完但用户还没点击任何按钮时就尝试恢复AudioContext，那么恢复动作会被浏览器忽略；但如果在点击事件的同步调用栈里执行，就必然成功。这是浏览器为提高用户体验而设计的机制，不能绕过，只能顺着来。

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

4.1 渲染主循环与帧率控制的工程实现

游戏主循环是整个项目的“心脏”。我采用的是固定时间步长 + 渲染插值的模式，这是游戏开发领域非常成熟的方案，简单说就是：物理逻辑每次固定推进16.67ms（1/60秒），如果渲染帧率超过60fps，则在两次物理更新之间重复渲染同一帧；如果渲染帧率低于60fps，则一次渲染前追赶多帧物理更新。

javascript复制const STEP = 1000 / 60; // 固定步长16.67ms
let accumulator = 0;
let lastTime = performance.now();

function frame(time) {
  requestAnimationFrame(frame);
  let delta = time - lastTime;
  lastTime = time;

  // 防止后台切回来时delta过大
  if (delta > 250) delta = 250;

  accumulator += delta;
  while (accumulator >= STEP) {
    update(STEP / 1000); // 物理更新，参数是秒
    accumulator -= STEP;
  }
  render();
}

这里限制单帧最大delta为250ms，是为了防止浏览器标签页切到后台又切回来时，物理循环一次性追赶大量更新，导致角色瞬间穿越地图。这个情况在新手写游戏循环时特别常见，而且表现非常诡异——玩家切出去聊个天回来，发现角色已经在墙外面了。

4.2 狐狸角色运动与重力模拟代码示例

角色移动我采用的是加速度加摩擦的模型，而不是直接设置恒定速度，这样移动手感更柔顺，起跳和停止都有缓冲：

javascript复制// 水平移动：加速度 + 摩擦
const ACCEL = 2400;   // 地面加速度，单位：像素/秒²
const MAX_SPEED = 320; // 最大水平速度
const FRICTION = 1800; // 地面摩擦系数

if (input.left) this.ax -= ACCEL;
if (input.right) this.ax += ACCEL;

this.vx += this.ax * dt;

// 应用摩擦
if (!input.left && !input.right) {
  const frictionForce = FRICTION * dt;
  if (Math.abs(this.vx) <= frictionForce) {
    this.vx = 0;
  } else {
    this.vx -= Math.sign(this.vx) * frictionForce;
  }
}

// 限制最大速度
this.vx = clamp(this.vx, -MAX_SPEED, MAX_SPEED);

跳跃物理：

javascript复制const JUMP_VELOCITY = -720; // 初速度向上
const GRAVITY = 2000;       // 重力加速度

if (input.jumpPressed && this.isGrounded) {
  this.vy = JUMP_VELOCITY;
  this.isGrounded = false;
}

this.vy += GRAVITY * dt;

// 跳跃裁剪：松开跳跃键时削减上升速度
if (input.jumpReleased && this.vy < 0) {
  this.vy *= 0.45;
}

这些参数的数值不是拍脑袋定的。初始值我参考了Celeste和Super Mario Bros的物理参数比例，然后反复试玩调整：速度太快会让玩家很难精准落位，太慢又显得拖沓。最终这一组值在手感和可控性之间取得了平衡，实测通关玩家的失败次数也印证了这点，后面会具体讲。

4.3 关卡加载与实体生成的自动化流程

关卡文件是纯JSON数据，而实体是JS类，他们之间靠一个工厂函数来对接。加载一个关卡时，游戏会遍历JSON里的实体列表，根据type字段匹配对应的构造函数：

javascript复制const ENTITY_REGISTRY = {
  player: Player,
  platform: Platform,
  hazard: Hazard,
  gate: Gate,
  pressure_plate: PressurePlate,
  exit: Exit,
  moving_platform: MovingPlatform,
  one_way_platform: OneWayPlatform,
  teleporter: Teleporter
};

function createEntityFromConfig(config, scene) {
  const EntityClass = ENTITY_REGISTRY[config.type];
  if (!EntityClass) {
    console.warn(`Unknown entity type: ${config.type}`);
    return null;
  }
  const entity = new EntityClass(scene, config);
  if (config.id) scene.entities.set(config.id, entity);
  return entity;
}

注册表模式的好处是新增实体类型不用改循环代码，只增加一个注册项。关卡配置里还可以声明triggers字段，让机关在工厂阶段自动建立“信号源-接收器”的连接：

javascript复制// 关卡加载后统一处理信号连接
Object.values(scene.entities).forEach(entity => {
  if (entity.config.triggers) {
    entity.config.triggers.forEach(targetId => {
      const target = scene.entities.get(targetId);
      if (target && typeof entity.addListener === 'function') {
        entity.addListener(target);
      }
    });
  }
});

这一套“数据驱动”的加载流程，让我在后续加关卡时不再碰游戏逻辑代码，编辑JSON就能生成完整的新关卡。有个周末我坐在电脑前一口气做了3个新关卡，没打开过entities/目录下的任何文件。

4.4 存档与关卡解锁机制

存档用localStorage，非常简单直接，但有两个细节值得注意：

第一，版本号。 我定义了saveVersion = 2，每次读取存档时会检查版本号，不匹配就丢弃存档而不是尝试解析。这样做是因为后续迭代过程中存档结构很可能会变，旧版本数据混在一起解析容易出各种隐藏Bug，不如直接重置来得干净。

第二，只在关键节点写入。 我没有每帧调用写localStorage，而是设计为“通关后”和“进入新关卡时”两个时间点写入。localStorage是同步API，频繁调用可能阻塞主线程导致游戏卡顿，低频写入更稳妥。

javascript复制function saveGame() {
  const data = {
    version: saveVersion,
    unlockedLevel: currentUnlockedLevel,
    bestTimes: levelBestTimes,
    lastPlayedAt: Date.now()
  };
  try {
    localStorage.setItem(SAVE_KEY, JSON.stringify(data));
  } catch (e) {
    console.warn('存档写入失败（大概率是隐私模式）', e);
  }
}

try-catch的包覆是必须的——Safari的隐私模式对localStorage的配额限制极其严格，写入量稍微超一点就会抛QuotaExceededError，不捕获的话游戏会直接崩溃。

4.5 部署上线全过程与静态文件准备

H5游戏部署没什么特别神秘的，本质就一句话：把静态文件放到Web服务器上，配置好访问路径和缓存策略。我的服务器环境是Nginx，部署步骤如下。

目录结构先理清楚：

code复制/var/www/escape-fox/
├── index.html
├── css/
│   └── style.css
├── js/
│   ├── engine.min.js   // 合并压缩后的引擎代码
│   ├── game.min.js     // 合并压缩后的游戏逻辑
│   └── vendor.min.js   // 第三方库（几乎没有，保留占位）
├── assets/
│   ├── images/
│   │   ├── fox.png
│   │   ├── tileset.png
│   │   └── ...
│   └── audio/
│       ├── jump.wav
│       └── ...
└── levels/
    ├── level1.json
    └── ...

Nginx配置里最核心的是缓存策略。因为游戏项目迭代比较快，HTML文件不缓存，所有带文件指纹的静态资源（比如game.min.js?v=20250321）缓存1年。如果没做版本指纹，那么缓存30天比较均衡：

nginx复制server {
    listen 80;
    server_name game.example.com;
    root /var/www/escape-fox;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }

    location ~* \.(js|css|png|jpg|wav|mp3)$ {
        expires 30d;
        add_header Cache-Control "public, no-transform";
    }

    gzip on;
    gzip_types text/css application/javascript application/json image/svg+xml;
    gzip_min_length 1024;
}

gzip压缩对于文本类资源（JS、CSS、JSON）的效果非常明显。我的主JS文件压缩前约100KB，开启gzip后传输体积只有30KB左右。首屏加载速度直接下降一大截。

部署完成后，我用浏览器开发者工具的Network面板验证了静态资源的加载状态，确认所有文件返回200且Content-Encoding为gzip；还用Lighthouse跑了一遍性能评分，移动端Performance得分从优化前的68分提升到93分，主要的性能消耗集中在图片解码，考虑到这是体素风格的游戏图，这个分数已经可接受。

5. 部署后的数据反馈与体验分析

5.1 真实设备访问的数据表现

部署上线大约一周后，我通过服务端访问日志统计到一些有意思的数据。这里说清楚，我的统计方式就是简单解析Nginx access log，统计访客IP数、页面访问次数和静态资源的请求情况，没有上重型数据分析工具：

• 日均独立访客IP数大约150个；
• 每次会话平均停留时间约4分30秒；
• 42%的流量来自手机浏览器，以Chrome移动端为主；
• 移动端用户的首关完成率约78%，但PC端完成率达到了91%；
• 第2关（废弃猎场）的平均耗时最长，单关平均需要2分20秒才过关，远超其他关卡。

第2关作为“引擎核心机制”的难度验证非常典型。它的核心机制是压力板+定时门，玩家必须站在压力板上让门保持开启，然后找机会冲刺过去。很多移动端玩家会按住屏幕上的跳跃按钮不放，导致角色一直跳跃错过开门时机。后续我调整了第2关引导文字，明确提示“按住压力板观察门的开启节奏”，完成率立刻提升了约6个百分点。

5.2 玩家体验中的重点反馈与三轮迭代

部署后收到的反馈，集中在三类问题上：操作手感争议、难度曲线不合理、音效在某些设备上没有声音。

针对操作手感，我把移动端的虚拟摇杆从“全屏任意位置拖拽控制”改成了“屏幕左侧触控区域模拟摇杆，右侧为跳跃键”。这样做的原因是全屏拖拽虽然看起来很自由，但玩家手指放在屏幕上时会遮挡画面，而且误触率特别高——常常手指刚放上去想挪个位置，角色就不受控制地跑动。区域化的输入方案解决了误触，但需要玩家适应一段时间。

针对难度曲线，我重新平衡了第3关的冰面物理。原本冰面摩擦系数是0.5，玩家在冰面上几乎刹不住车，打滑严重导致频繁掉进深渊。在收到“手感太滑”的大量反馈后，我把摩擦系数调到0.82，保留冰面的差异感，但不至于让角色失控。

音效问题复盘下来，大部分出在用户点击“开始游戏”按钮后立刻跳过了过场动画，而过场动画是音效初始化的最晚节点。我后来把音效初始化移到了页面加载完成后的首次触摸事件中，从根本上确保用户第一次点击“开始游戏”之前音频系统就已经可用。

5.3 数据埋点与后续扩展方向

经过这一轮迭代，我认为项目的核心机制已经稳定，剩下的是打磨和扩展空间。如果你也打算做类似的小游戏项目，我建议你在开发初期就规划好埋点——刚开始做这个游戏时我没埋点，后面补埋点的成本远高于一开始设计好的数据采集。

埋点方案不需要复杂，我最终用的是：

javascript复制function track(eventName, eventData = {}) {
  if (!window.gtag) return;
  gtag('event', eventName, eventData);
}

用事件的方式上报“关卡开始/通关/死亡次数/重试次数”等关键节点，在Google Analytics里就能看到完整的漏斗数据。不依赖于GA的话，也可以自己写一个每次请求向服务端上报事件的接口，逻辑是一样的。

扩展方向上，我目前有意识地让“数据驱动”的能力积累起来：关卡设计已经完全是JSON配置了，后续可以做一个简单的地图编辑器导出台面数据。移动端我已经把Web App Manifest和Service Worker接了进去，实现了基本的离线可玩。如果你对这类H5小游戏感兴趣，我强烈推荐你也从“零依赖”开始做一版，体会到的东西比直接用引擎多得多。

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

6.1 跨浏览器兼容问题速查表

6.2 一个容易忽略的Canvas性能问题

我一度在低端Android手机上观察到严重的卡顿，排查了很久才发现问题不在渲染本身，而是在每次drawImage时都动态创建Canvas渐变。游戏中背景的渐变效果是逐帧创建的，大量createLinearGradient调用消耗了不必要的内存和CPU。

修复方式很简单：把渐变对象在初始化阶段创建好并缓存，每帧直接复用。这个优化把帧渲染时间从平均11ms降到了4ms左右，卡顿现象基本消失。

从这里得到的经验：Canvas游戏性能优化的第一优先级永远不是减少draw次数，而是减少纯JavaScript层的对象创建和垃圾回收。V8引擎的垃圾回收在大量临时对象产生时会暂停所有任务，这个停顿恰好就在你切换场景或连招的时候出现，表现为突然卡一下然后恢复。

6.3 开发者需要养成的三件“引擎习惯”

个人项目做久了，我养成了一些习惯，也算是对“独立游戏开发”这件事的系统性思考：

第一，始终保留一套可直接运行的Demo分支。 游戏开发非常依赖手感反馈，如果每次动调数值都要重新部署才能看到效果，整个迭代节奏会被拖死。我在本地启动了一个简单的静态服务器（python3 -m http.server），所有改动实时预览，确认手感OK后再合并到主分支。

第二，打印日志要分等级分层级。 逻辑开发阶段我用console.log堆了大量输出，上线前全部清理，只保留console.warn和console.error。开发者工具和代码里可以加一个DEBUG开关，线上环境自动关闭多余日志，为排查线上问题保留最少的运行痕迹，同时避免不必要的性能损耗。

第三，养成“录制回放”的习惯。 游戏里有一类Bug极难定位——比如玩家连续跳三次后在特定位置卡进墙里，问题可能只出现在特定的输入序列和时间间隔下。我后来在调试版本里加入了输入录制功能：把每帧的输入状态记录为一个数组，碰到Bug就把数组存下来，之后可以让游戏自动播放这段输入序列，复现问题。这个工具花了我半天时间写，但每一次定位物理相关Bug时它都在救命。

7. 最后再分享一个开发提效的技巧

如果你正在做类似的小型H5游戏，我强烈建议你在项目初期就把“调试面板”作为一个正式功能来设计，而不是临时打console.log。我在Escape Fox Game里加了一个简单的Debug面板，按下键盘上的D键时显示：当前帧率、玩家坐标、速度、当前所处关卡、最近一次碰撞的实体类型。这个面板在后续调碰撞体参数、手感参数时帮了大忙，因为你不需要“盲调”——每次改一下摩擦系数，立刻在面板里看到速度变化曲线和帧率是否波动。

另外一个小技巧是：关卡改动后，在浏览器里按R键自动重新加载当前关卡，而不是整页刷新回到标题画面。这个极短的反馈循环大大提高了单关迭代的效率——毕竟做游戏90%的时间都在反复试玩同一关，减少无谓的等待时间就是节省生命。

上面从头到尾聊了Escape Fox Game从设计、开发、部署到迭代的完整过程，里面提到的代码片段都是项目里实际跑过的实现，数据和结论也来自我个人线上运行时观察所得。希望这些经验能让你在自己的H5游戏项目中少走弯路。如果你也在做小游戏，欢迎分享你的踩坑经历，咱们在评论区交流。