在云端体验环境部署单文件 2048：从本地服务到公网验证

这次实践选择了一个不依赖后端数据库的 2048 小游戏。界面、样式和游戏逻辑放在一个 index.html 文件中，目标是验证静态应用在临时开发环境中的启动、外部访问以及功能验收流程。

先让应用保持简单

棋盘使用长度为 16 的数组保存，每次移动把对应行或列压缩、合并，再放回棋盘。一个格子在一次移动中只参与一次合并。例如四个连续的 2 向左移动，应当得到两个 4，新增得分为 8，而不是直接得到一个 8。

为了让小游戏适合实际体验，界面增加了方向键、WASD、手机滑动和屏幕方向按钮；同时支持计分、最佳成绩、撤销一步和自动保存。结束判断同时检查空格以及相邻数字：棋盘填满并不代表游戏结束，只有不存在任何相邻相同数字时才真正无法继续。

用普通终端启动静态服务

在开发环境中把作品单独放到项目目录，再启动仅监听回环地址的 HTTP 服务：

python3 -m http.server 3080 --bind 127.0.0.1 --directory /workspace/grow2048

这里刻意指定 directory，避免把整个工作区作为网站根目录公开。静态服务目录只应放需要展示的作品文件；包含凭证的配置、终端输出和认证日志应放到网站目录之外。

Python 自带 HTTP 服务适用于这类短期演示，正式网站应选择具备访问控制、日志管理和完整运维能力的部署方案。

公网隧道和应用是两层验证

临时环境无需为了演示单独购买公网 IP，可以在官方支持的环境中使用 DevBridge 将本地端口映射到临时访问地址。隧道负责网络连通，应用进程负责返回页面，两者需要分别确认。

本次实际遇到过隧道认证过期，重新完成官方认证后才成功建立访问入口。认证材料不能放进网页、源码或公开日志。外部访问还可能先出现平台的安全提示页，因此 HTTP 200 只能说明请求成功返回，不能单独证明游戏已经呈现。必须打开真实页面并确认标题、棋盘和交互。

做几项有意义的验收

本次在浏览器中检查了四个相邻 2 的合并与计分、撤销后的恢复、无可用移动时的结束提示，以及 390 像素宽度下是否出现横向溢出。测试后重新开始游戏，避免把人为构造的测试棋盘当成正常用户存档。

功能验证、部署成功和活动审核通过是不同状态。实际部署可以正常访问，并不代表提交平台一定接受账号或自动发放奖励，活动应以提交结果和积分明细为准。

临时资源的收尾

临时开发环境有到期回收机制，不能用临时隧道承诺长期在线服务。完成演示后应停止本次服务和隧道，释放本次环境，并把可复用源码保存到本地或合适的代码仓库。对于持久化环境，也应先核对计算、磁盘、带宽等各项计费规则，不能因为有计算额度就推断所有关联资源免费。

这套流程最有价值的地方在于把可运行、可访问、可交互和可回收分别验收。即使应用只有一个 HTML 文件，也能形成清楚的部署证据和资源边界。