从能打开到可交付：一次 2048 静态站点的部署验收复盘

作者：lgbisha。本文基于本人于 2026 年 10 月 21 日复用已有华为云 Flexus L 实例部署单文件 2048 的实际记录整理，AI 辅助撰写与校对。文中的结论限定于这次实践，不保证其他活动的资源支持范围或长期规则相同，也不展示真实公网地址、实例标识或登录凭据。

静态游戏只有一个 HTML 文件，看起来上传到服务器就结束了。但这次实践中，真正花时间的不是复制文件，而是确认三件事：上线的是不是验收过的版本，公网用户能不能正常操作，交付状态能不能被独立证据支持。下面记录具体做法与遇到的误判。

一、复用已有实例之前，先划清操作范围

本次使用的是本人已有的新加坡 Flexus L 实例，实际系统为 Ubuntu 24.04，未为这个游戏另购实例、EIP 或带宽。部署前先检查目标主机、已有进程、80 端口、Web 服务安装情况和目标目录，确认没有覆盖已有网站。

一个容易忽略的细节是：“没有业务”不能替代实际预检。服务器上仍可能运行浏览器、远程桌面或其他辅助进程。这些进程与游戏无关，应保留。本次也没有重装系统、重置密码、重启整台实例，或扩大账号权限。

如果安全组本来已经允许网站所需访问，应先核实并复用已有配置，而不是习惯性添加全端口规则。不能将“公网能访问游戏”当成“服务器已经完成全面安全加固”。

二、建立内容指纹，避免部署错版本

这次游戏有过历史首版和修正版。仅根据文件名判断，很容易把旧的 index.html 再次部署。我的做法是把经过独立逻辑检查的版本作为验收源，并记录文件长度和 SHA-256。

部署时分三处核对内容：本地验收文件、服务器目标文件、从公网实际下载的响应。三者的摘要一致，才能说明公网访问命中了预期产物。

下面是表达这一思路的只读命令示例，路径与域名均为占位值，不能直接当作本次真实部署命令使用：

sha256sum ./reviewed/index.html
curl --fail --silent --show-error --max-time 15 \
  https://your-site.example/game/index.html \
  -o /tmp/game-public-check.html
sha256sum /tmp/game-public-check.html

HTTP 200 只证明请求得到了成功响应，返回内容仍可能是默认站点或占位页。因此除了状态码，还要核对正文、文件指纹以及必要的页面行为。

三、独立配置和不覆盖保护，让恢复更可控

本次为游戏新增独立的 Nginx 配置与站点目录，没有删除默认站点。部署脚本会在目标文件或配置已经存在时中止，而不是反复覆盖。

这个保护会让第二次执行看起来“不够方便”，但它能避免把已经上线的文件、人工修正或另一个任务的配置覆盖掉。需要修改已存在站点时，应先确认当前版本和差异，再走明确的更新流程。

配置检查与服务状态也应分开验证：配置语法通过，不代表 reload 已生效；服务 active，也不代表当前请求命中了正确站点。本次同时检查了配置、服务状态、回环访问及公网响应。

四、reload 后短暂失败，不等于需要重新部署

第一次 reload 后立即访问回环地址，确实遇到了 404，检查脚本也以非零退出码结束。我没有把这一步记成成功，也没有马上覆盖文件或重新安装服务。

后续复查相同配置和文件时，回环及公网访问均返回 200，下载内容与验收版本一致。交付脚本因此补上了有限次数的就绪重试，以及明确的主机头和回环无代理检查。

这里有两条经验：一是保留首次失败，不把后来的成功倒填为第一次就成功；二是重试要有次数和超时边界。连续失败时应检查配置、路由和日志，而不是无限等待或反复执行有副作用的部署。

五、测试输入节奏也可能制造假失败

本次修正版游戏在动画期间有约 130ms 的输入锁。首轮自动化连续输入太快，得分没有增长。如果直接据此认定游戏逻辑坏了，可能把正常的输入保护当成缺陷。

调整为至少 150ms 的输入间隔后，在没有修改游戏逻辑或分数的情况下，桌面方向键及移动端合成触摸操作均能正常合并计分。

实际浏览器检查还包括：

• 使用没有登录 Cookie 的新上下文，避免把登录态或缓存当作公开访问成功。
• 检查桌面和 390px 宽的移动布局，确认没有横向溢出。
• 监听页面脚本异常，不能只看截图是否漂亮。
• 点击“新游戏”后，确认分数恢复为 0，初始方块数量为 2。
• 区分合成触摸与真实手机测试。本次做的是浏览器合成触摸，不冒称覆盖了真实手机和所有系统。

六、提交回执、持久化状态和奖励需要分别核验

网站正常与外部平台认可成果是不同目标。本次先有部署与公网验收，再取得正式提交成功响应，随后重新读取持久化进度并刷新活动页面。

奖励也不是随成功响应立即到账：首次检查没有新流水，稍后才核实到对应奖励记录。因此报告中应分别写“提交成功”“进度已持久化”“奖励已核实”，不把三者合成一句模糊的“全部完成”。

如果请求后客户端解析代码报错，应先查结果列表或进度，再决定是否重试。客户端异常并不能证明服务器没有受理请求，盲目重发可能造成重复提交。

七、交付必须带上退出计划

用户不再需要临时站点时，应停止本次服务并考虑取消其开机自启，但这不等于关闭实例、删除文件或停止原套餐计费。若同一 Nginx 后来承载了其他站点，则不能为了停一个游戏直接停掉整个 Web 服务。

截至本文整理时，停服操作仍因 CloudShell 空闲会话超时而等待本人重新连接，尚未完成。因此本文不写成“已清理”。后续应核实目标主机及服务范围，再验证服务状态、自启状态和公网访问结果，同时保留其他进程。

小结

这次实践让我把一个“上传 HTML”的任务，拆成了可核验的交付链：资源预检、产物指纹、独立配置、有限就绪检查、匿名行为验收、结果持久化，以及最终停服与恢复记录。

这些步骤不是为了让简单任务变复杂，而是为了在出错、换人或隔天继续时，能准确回答：做了什么、哪一步真正成功、哪一步仍在等待，以及下一次应该从哪里接着做。