用CodeArts做一个2048小游戏：从沙箱验证到ECS部署与资源清理

这次用华为云码道（CodeArts）做了一个单文件版2048小游戏，并走了一遍沙箱验证、ECS部署和资源清理。开发和本文整理使用了AI辅助。这里记录实际做过的步骤，以及发布前发现的一处方向转换问题，方便以后复查。

1. 先把项目做小

这个项目只包含一个HTML文件，样式和脚本都写在页面中，没有后端、数据库和第三方运行时依赖。打开文件即可开始游戏，也可以交给Nginx提供静态访问。

页面包含4×4棋盘、当前分数、最高分和“新游戏”按钮。桌面端使用方向键或WASD操作；代码中也实现了触摸滑动入口。最高分保存在当前浏览器的localStorage中，不会自动跨设备同步。

选择这种结构，是为了先把游戏逻辑和部署流程验证清楚，减少依赖安装带来的干扰。

2. AI生成后，先验收规则

页面能打开，只能说明HTML加载成功。2048还需要检查移动方向、合并顺序和计分。

例如一行数字向左移动：

• [2, 2, 4, 4] 应得到 [4, 8, 0, 0]，本次增加12分；
• [2, 2, 2, 2] 应得到 [4, 4, 0, 0]，同一次移动不能继续合并成8；
• 棋盘没有发生变化时，不应额外生成新数字。

这里的结果只描述移动与合并，随后游戏会在空格中随机生成一个2或4。

发布前检查源码时，发现原来的矩阵转换只是颠倒行顺序，没有完成旋转，导致多个方向实际上仍然按向左的逻辑处理。修正为逆时针旋转后，向上、向右、向下可以先统一转换为向左合并，再转回原方向。核心映射为：

next[row][col] = board[col][SIZE - 1 - row];

同时把最高分更新放到了界面渲染之前，避免本次得分已经刷新、最高分却晚一步显示。

修正版用固定棋盘验证了四个方向、单次合并、无效移动、计分、胜利判断和重新开始，并在浏览器中进行了方向键和WASD试玩。触摸入口仍需要补充真实移动设备上的体验验证。

3. 从沙箱验证到ECS部署

第一阶段在临时沙箱中运行页面，确认服务能够提供访问。临时环境适合调试，但环境到期、进程退出后，访问地址可能失效，不适合作为长期服务承诺。

第二阶段使用华北-北京四的按需ECS，配置为1核2GB、40GB通用型SSD和按流量计费的公网IP。通过启动脚本安装Nginx并写入静态页面，安全组仅增加HTTP 80端口访问规则，没有为这个实验额外开放SSH。

部署验证分两步：先检查HTTP状态，再核对响应正文是否确实包含2048页面内容。当时服务返回HTTP 200，响应头显示Nginx，正文也匹配了游戏内容。这样可以排除“访问成功但打开的是默认欢迎页”的情况。

需要区分两个版本：ECS阶段验证的是当时的初版；方向转换修正是在后续发布验收时完成，修正版已在本地验证，没有再次创建ECS进行重复部署。不能把一次HTTP 200当作所有游戏规则都已正确的证明。

4. 实验结束后，逐项释放资源

这个实例只用于短时验证，完成后已释放。清理时同时处理服务器、系统盘、公网IP和带宽，再处理专用安全组、子网和VPC，并通过资源查询确认状态。

仅关闭服务器进程不代表资源已释放；删除ECS后，也要检查磁盘和公网IP是否残留。记录资源ID便于清理，但公开文章中无需展示账号信息、临时凭证或具体资源标识。

费用也应以实际账单为准，计算器估算、代金券余额和最终结算金额是不同的状态。账单尚未入账时，不应直接写成“实验没有费用”。

5. 当前保留了什么

现在保留的是修正后的单文件游戏、源码备份和验证记录。此前ECS访问地址已随资源释放而失效，本文不把它作为在线体验入口。

这次最有价值的检查，是把“服务能访问”和“游戏逻辑正确”分开验证。后续如果继续扩展，可以补充撤销一步、完整局面保存，以及移动设备上的操作体验测试。