为什么要做#

浏览器里跑小游戏是最轻量的娱乐分发方式：不用安装、即点即玩、关了就走。我想用这个项目完整练一遍前端工程——从产品规划到部署上线，而不是只写几个 demo 页面。

另外有个私心：平时写 Java 后端多，前端主要做管理后台，做点游戏这种”有反馈感”的东西，能找回写代码的乐趣。

技术选型#

刻意选了最朴素的组合：HTML + CSS + 原生 JavaScript + Canvas 2D。不引框架，不引游戏引擎。理由有两个：

1. 想靠这个项目把浏览器渲染和原生 API 吃透，而不是把复杂度外包给引擎
2. 零依赖意味着构建部署最简单——直接推 GitHub Pages，连 CI 都不用配

遇到的几个实际问题#

渲染循环的帧率问题。 第一版游戏用 setInterval 驱动渲染，低端手机上明显掉帧。后来统一改成 requestAnimationFrame，并且用时间差（delta time）控制逻辑更新，让游戏速度跟帧率解耦：

1
let last = 0;
2
function loop(timestamp) {
3
  const delta = (timestamp - last) / 1000;
4
  last = timestamp;
5
  update(delta); // 逻辑更新，速度与帧率无关
6
  render();      // 绘制
7
  requestAnimationFrame(loop);
8
}
9
requestAnimationFrame(loop);

移动端触摸适配。 桌面端用键盘（方向键 + 空格），移动端要支持触摸。最开始只加了 touchstart 监听，结果发现多点触控会互相干扰。后来给每个按键区域独立绑定事件，并加了 touch-action: none 防止浏览器默认的滚动/缩放行为，体验才正常。

像素风 UI 的一致性。 定了 8-bit 像素风格之后，所有按钮、面板、弹窗都基于同一套间距和配色画，费了不少功夫。当时没做设计 token 的概念，现在回头看，一个简单的 CSS 变量表就能解决 90% 的重复劳动——这个经验后来用在了作品集主页上。

部署#

GitHub Pages 部署简单到有点无聊：推送代码 → Settings → Pages → 选分支，完事。域名用的是默认的 xxx.github.io/Game-Hub，没绑自定义域名。静态站点的好处就在这，没有服务器、没有后端、没有运维。

收获#

• 纯原生 JS 做完一个项目，对事件循环、Canvas API、兼容性这些的理解比看一百篇博客都深
• “把项目做上线”这个闭环本身很有价值：产品规划、开发、部署、迭代，每个环节都有真实的决策要做
• 踩过的渲染性能、触摸适配的坑，都是文档里不写、只有自己做一遍才知道的东西

代码在 GitHub，欢迎 star，也欢迎提游戏创意。