用 AI 开发者空间完成 2048 部署：从沙箱验证到 ECS 资源清理

这次实践使用华为云 AI 开发者空间，将一个单文件 2048 小游戏从免费容器验证推进到 ECS 部署，再提交作品并回收资源。本文记录的是实际执行中遇到的问题：页面能访问并不等于部署完成，创建接口成功也不等于实例已经就绪，清理接口返回成功后同样需要验证资源确实不存在。

文章由 AI 协助整理，涉及的部署、HTTP 检查和资源删除均有实际执行结果。文中省略账号、凭据、项目 ID 和资源 ID；活动规则和价格请以当时官方页面为准。

一、先把作品缩小到一个可验证的单元

2048 适合作为第一份部署练习，因为 HTML、CSS 与 JavaScript 可以放进一个 index.html，不需要数据库，也不需要额外后端。这个版本包含 4×4 棋盘、方向键与 WASD 操作、触屏滑动、分数显示和重新开始。

验收时不能只看首页是否显示。应检查：

• 左右、上下移动的方向是否一致；
• 同一次移动中，新合并的方块是否被错误地再次合并；
• 无效移动是否错误地产生新方块；
• 重新开始后棋盘与当前分数是否重置；
• 棋盘填满但仍有相邻同值方块时，是否被误判为结束。

先确认游戏本身可用，再部署，可以减少在云端排查前端逻辑的时间。

二、先在免费开发容器中验证

在 AI 开发者空间选择体验版，准备游戏文件后启动静态服务：

python3 -m http.server 8080 --directory /root/workspace

随后检查本地返回：

curl -I http://127.0.0.1:8080/index.html

如果需要远程预览，可按官方 DevBridge 文档创建开发隧道。实际操作时还要在浏览器中打开页面，并测试主要交互。HTTP 200 只能证明请求成功，不能代替功能验收。

需要注意：临时容器到期会释放，隧道也不应被当作永久托管地址。代码与说明应另行保存，公开展示时注明体验地址的时效。

三、ECS 阶段使用独立的临时资源

本次 ECS 部署使用独立命名的 VPC、子网和安全组，通过 cloud-init 安装 nginx 并写入游戏文件。公网仅开放静态游戏所需的 TCP 80，没有为演示增加 SSH 入站规则。

cloud-init 的核心结构可以简化为：

#cloud-config
packages:
  - nginx
write_files:
  - path: /usr/share/nginx/html/hc-activity/index.html
    permissions: '0644'
    content: |
      <!doctype html>
      <html><head><title>2048</title></head>
      <body>这里替换为完整的游戏页面</body></html>
runcmd:
  - systemctl enable nginx
  - systemctl restart nginx

这只是结构示例，实际使用时必须放入完整游戏代码，并确认镜像的 nginx 配置确实使用对应目录。本次实际部署的页面内容大小为 8198 字节，验收同时检查了状态码、标题和页面内容。

四、异步接口是最容易忽略的环节

官方 CreatePostPaidServers 是异步接口。收到 job_id 后，还需要通过 ShowJob 查询，任务状态为 SUCCESS 才表示创建完成。不能把“请求已受理”当作“服务器已经可以访问”。

我的处理顺序是：记录返回的实例 ID 与 job ID，等待创建任务成功，再查询实例状态和公网 IP，最后等待 nginx 初始化完成。对于重试创建，还应使用官方支持的幂等请求机制，避免网络异常后重复购买。

公网检查也分两层：先检查 HTTP 状态，再检查返回的是预期游戏页面，避免把 nginx 默认欢迎页当作部署成功。

官方接口说明：

• https://support.huaweicloud.com/api-ecs/zh-cn_topic_0020212668.html
• https://support.huaweicloud.com/api-ecs/ecs_02_0901.html

五、提交成功后，清理也要有验收

本次活动接口返回了“作品提交成功”。之后立即删除临时 ECS，并同时请求删除关联公网 IP 和系统盘，再按依赖关系清理安全组、子网和 VPC。

这里实际遇到两个问题：

第一，CLI 的进程退出状态不能单独作为业务成功依据。还应检查 JSON 中的错误结构、错误码和任务状态。查询已删除实例时，服务可能返回 404 和 could not be found；如果只判断有没有抛出异常，就可能进入无意义的重复查询。

第二，回收过程中遇到了 API 限流。此时继续高频请求不会加快清理，应停止无效轮询、等待后重试。最终核对结果为：临时 ECS 不存在，公网 IP 和系统盘列表为空，本次安全组、子网和 VPC 也已删除。

自动删除时间可以作为兜底，但不能替代主动清理和结果检查。对于按需资源，结束实践后应核对计算、存储与公网资源，后续还要查看正式账单。

六、这次实践留下的可复用方法

这次流程中最有价值的并非某条一键命令，而是三个检查点：

1. 作品验收：页面打开后，确实测试核心交互。
2. 部署验收：异步任务成功、实例就绪、HTTP 与实际内容均正确。
3. 清理验收：删除请求完成后，再证明本次资源已不存在。

把资源 ID 保存在独立状态记录中，只处理本次创建的资源，可以降低误删已有环境的风险。后续换成其他静态网站或轻量应用，也可以沿用同样的执行与验收思路。