单文件2048实战：把合并规则、手机操作和部署验证分开检查

一个2048小游戏很适合练习从代码生成到部署验证的完整流程：页面不大，但合并顺序、无效移动、手机手势和部署状态都有值得检查的边界。本文结合一次实际生成与本地验证过程，说明如何组织一个不依赖构建工具的版本。示例由AI辅助编写，测试与下面列出的验证范围分开记录。

1. 先把交付物缩小到一个HTML

将CSS、JavaScript全部放进index.html，不引用外部字体、统计脚本和CDN。这样保存文件后即可离线打开，也能直接交给静态服务器托管。这个选择不代表所有项目都应当单文件化；它适用于这种界面和逻辑都较小的练习。

界面只保留标题、当前分数、最高分、重新开始按钮、4×4棋盘及结束遮罩。棋盘用CSS Grid排列，宽度使用100%并设置最大宽度，避免在手机上固定为桌面尺寸。我分别检查了1280×900和390×844两个视口，确认棋盘、分数和按钮在这两个尺寸下可以完整显示。两种尺寸的预览不能代替真实手机上的触摸验收。

2. 一行合并的关键：本次生成的数字不能再次合并

可以先独立处理朝左的一行，再通过读取和写回行、列来处理其他方向。下面的函数不修改传入数组，返回新的一行及增加的分数：

function mergeLine(line) {
  const values = line.filter(value => value !== 0);
  const result = [];
  let gained = 0;
  for (let i = 0; i < values.length; i++) {
    if (values[i] === values[i + 1]) {
      const merged = values[i] * 2;
      result.push(merged);
      gained += merged;
      i++;
    } else {
      result.push(values[i]);
    }
  }
  while (result.length < line.length) result.push(0);
  return { row: result, gained };
}

例如，[2,2,4,0]应得到[4,4,0,0]，而不是[8,0,0,0]。因为第一个4是本次移动刚生成的，不能再与原有的4连锁合并。[2,2,2,2]则应该得到[4,4,0,0]，本次增加8分。

不要只凭肉眼玩几次就认为这一层正确。至少把全空、无法合并、多个连续相同数字、不同方向以及不修改输入数组的情况列入断言。

3. 无效移动不能生成新方块

一次操作可以按下面的顺序组织：复制棋盘，读取各行或各列，执行合并，写回新棋盘，再比较新旧棋盘是否变化。只有真的发生移动或合并时，才增加分数并随机生成一个新方块。

如果玩家按了一个没有作用的方向键，还继续生成新方块，棋盘会被无故填满。这个问题可能被“页面能运行”的检查漏掉，却会直接影响游戏规则。

判断游戏结束时，也不能只看棋盘是否填满。棋盘有空格时仍可移动；没有空格时，还要检查横向和纵向是否存在相邻相同数字。达到2048的提示与“没有合法移动”的结束状态也应分开处理。

4. 手机手势和最高分存储都要有边界

手机操作可在棋盘上记录touchstart与touchend的坐标差，根据绝对位移较大的轴判断方向，并设置最小位移，避免轻触被误判成滑动。真实设备还需要测试页面滚动、误触和快速连续滑动。本次只验证了手势处理逻辑，尚未把它算作真实手机触摸通过。

最高分可以保存在浏览器本地。读取和写入应放在try/catch中：即使存储不可用，游戏也应当还能开始、移动和重新开始。最高分只是本地记录，不应为此添加账号、收集身份资料或引入服务端接口。

5. 把“本地可运行”与“云端已上线”分开

这次独立检查覆盖了初始16格棋盘、键盘合并和方向、重新开始、触摸合并，以及导出文件没有外部请求或平台预览包装代码。代码生成工具另外报告了规则断言，但工具报告与独立检查应分别保留，不能混成一次验收。

随后尝试免费沙箱部署时，连接接口先后返回HD.99008001（Invalid EVS create request）和HD.99003001（No available node pool）；官方体验版入口也提示后台资源不足。因此，此时准确的记录是“草稿与本地检查完成，云端部署未完成”，而不是“上线成功”。这里没有转去创建收费资源。

等沙箱恢复后，还需要检查公开地址可以访问、返回的是本次游戏内容、键盘操作有效，再提交活动成果。最后查看活动状态和积分明细，确认是否真正通过及到账。一个可访问链接，也不能自动证明活动已经验收。

这个练习最有价值的部分，是为每一步建立清楚的完成证据：代码生成、规则检查、界面预览、云端可达、活动验收，各自对应不同结果。把这些边界记清楚，下一次遇到失败时就更容易从正确的位置继续。

2026-10-22 更新：两个部署环境已完成，活动验收仍未通过

后续复用了账号已有的免费容器，沙箱静态服务部署完成；同一份游戏也已在原有广州Flexus L实例上做持久化部署。本轮没有新建收费服务器，新增现金支出为0元。代码与部署脚本由AI辅助准备，工具连接和独立验收分别记录。

公开源码与部署说明 已补充维护中的长期体验入口，见仓库README。这是轻量静态演示服务，游戏不要求登录或填写个人资料。沙箱链接有有效期，因此持续访问采用原有服务器。

验收没有停在“工具报告成功”：分别从公网下载文件，确认9667字节及SHA256 0f92a47530dc893dd5e219ef602641af78807f739e35a1fb96af87a4353b9ece，与已检查的HTML一致；另外在浏览器打开沙箱页面，实际用方向键合并，分数从0变为4。服务器使用独立systemd服务保持运行，静态目录只读，并设置资源上限。

提交官方沙箱关卡时，后台弹窗返回“活动不存在或已结束”。因此目前能确认的是两处部署成功，不能确认活动已经结束的具体原因，也不能声称官方闯关通过。独立刷新积分明细后，未见沙箱/ECS关卡奖励。其他赛事积分单独核验，不视为本次闯关完成。这里保留了失败结果，没有继续重复提交或为奖励另购资源。

这个后续结果再次说明：页面可达、内容一致、交互有效、服务持久化和官方验收是不同的检查项，应该分别给出证据。