从零把一个纯前端 2048 部署到公网：我踩过的 5 个坑

很多小作品在本地看起来已经完成，但真正交给别人使用时，问题往往出现在最后一步：页面能打开吗？手机能玩吗？刷新后还能恢复吗？公网地址会不会明天就失效？

这次我用一个纯前端 2048 小游戏做实验。它的结构很简单，只有 index.html，CSS 和 JavaScript 都内联在文件里。选择这种结构不是为了炫技，而是为了让部署边界尽可能清晰：没有 npm 依赖，没有构建产物，也没有额外的静态资源路径。上传一个文件，服务端返回它，浏览器就能运行。

第一个坑是本地能开不等于公网可用。本地文件可以直接从 file:// 打开，但部署到 HTTP 服务后，缓存、MIME 类型和路径规则都会参与进来。最稳妥的验收方式不是只看页面截图，而是用命令行检查状态码和响应内容，例如 curl -sI 确认响应头，curl -s 加 head 查看正文开头。状态码为 200 只说明服务器找到了资源，仍然需要确认返回的是 HTML，而不是错误页或登录页。对于公开作品，我还会检查页面标题和一段关键文本，避免返回 200 但内容错误。

第二个坑是移动端输入。桌面端用方向键测试很顺，手机上却没有键盘。触屏滑动要处理 touchstart、touchmove 和 touchend，同时避免页面跟着滚动。一个简单做法是在游戏区域内阻止默认滚动，并根据起点和终点的位移判断方向。还要考虑快速连续滑动，不能让动画状态和逻辑状态互相覆盖。

第三个坑是刷新后的状态。最小版本可以不保存进度，但如果页面刷新就完全丢失棋盘，体验会很差。浏览器本地存储足够解决这个问题：每次有效移动后保存棋盘和分数，启动时校验数据格式再恢复。这里不要直接信任旧数据，版本升级或字段缺失时应当回退到新游戏，而不是让页面在初始化阶段抛异常。

第四个坑是公网地址的生命周期。开发隧道适合演示和验收，不等于长期托管。临时隧道可能因为会话结束、平台回收或网络策略变化而失效，因此提交作品前要区分现在可以访问和长期稳定可用。如果作品需要长期展示，应该使用有明确生命周期的托管服务，并把部署方式和资源清理步骤写进 README。

第五个坑是资源清理。做云上实验时，创建资源很容易，忘记释放却可能持续产生费用。我的做法是给每次实验记录三件事：资源名称、所在地域、预计删除时间。验证完成后先删除临时计算资源，再检查公网地址是否失效，最后确认没有遗留的磁盘或网络资源。这个步骤看起来和代码无关，却是完整交付的一部分。

最后，我会把验收结果写成一个短清单：页面返回 200，标题和关键内容正确；桌面方向键和手机滑动都能完成一次有效移动；刷新后状态符合预期；公网地址来源和有效期明确；临时资源已经清理或记录了保留原因。

一个小游戏的价值不只在算法，更在于它能否被别人稳定打开、理解和继续使用。把部署、验证和清理当成开发流程的一部分，作品才算真正完成。