单文件HTML上云后的三层验收：HTTP、内容与交互

把一个 index.html 放到服务器上，再拿到公网地址，容易让人觉得部署已经结束。本次单文件2048练习让我更关注验收的边界：请求返回200、下载到预期文件、游戏能够正常操作，是三个不同的结果，需要分别检查。

本文由AI协助整理，基于本次静态站点部署记录和公开技术文档。文中命令使用示例地址，不包含账号、访问密钥、真实资源ID或仍在使用的服务器地址。这里分享验收方法，不提供长期在线的游戏服务。

第一层：HTTP检查证明了什么

本次部署记录保存了公网请求返回200的结果。这个结果有价值：它说明检查当时，请求经过公网访问链路得到了成功响应。但仅凭这一行状态码，还不能判断返回的是2048页面、默认欢迎页，还是另一个被错误配置到同一路径的页面。

常见的检查方式是：

site_url='https://example.com/hc-activity/index.html'
curl -sS -I --max-time 10 "$site_url"

这里的 -I 使用HEAD方式获取响应头。按照HTTP的语义，HEAD响应没有GET对应的正文，因此它不适合证明HTML里的游戏逻辑完整。还要注意，服务端对HEAD和GET的实际实现可能不同，最终应对两种请求分别验收。

检查时除了状态码，还可以记录Content-Type、响应时间和访问时间。如果出现重定向，应先看清Location指向哪里，再判断是否需要跟随。登录页、旧路径跳转和站点欢迎页，都可能让“看起来能打开”与预期结果产生偏差。

第二层：确认下载的是这次发布的文件

接下来使用GET保存正文：

curl --fail --silent --show-error --max-time 10   --dump-header response-headers.txt   --output downloaded-index.html "$site_url"

这个例子在HTTP错误时报告失败，并把响应头和正文分别保存，方便回查。它仍需要配合状态码、文件内容和实际页面判断，不能只看命令有没有输出报错。

对于未经过压缩改写或内容注入的单文件部署，可以比较本地发布文件与下载文件的摘要。例如在macOS上：

shasum -a 256 index.html downloaded-index.html

两个摘要相同，能支持“下载正文与本地发布文件字节一致”的结论。如果中间代理会改写HTML，摘要不同就需要进一步解释，不能直接断定上传失败。

也可以在发布时放入一个不含敏感信息的构建标记，例如注释里的版本号。标记比页面标题更适合区分新旧版本，但它只是一项内容证据，不代表整段程序已经执行成功。

本次记录中保留了HTTP状态、内容摘要和独立的部署完成标记。这些证据用于确认当时的访问和部署结果；本文没有把它们扩大为“所有游戏交互都已自动测试通过”。

第三层：浏览器里测试真实操作

2048的主要逻辑在浏览器执行，因此最后要做交互验收。建议先准备几个可重复的场景，而不是随便按几次方向键就结束。

• 合并顺序：同一行出现2、2、2、2时，左移应得到4、4、0、0；同一轮不能把刚合成的两个4再合为8。
• 无效移动：棋盘没有变化时，不应无条件增加新方块。
• 得分：每次合并增加的分数应与合并结果一致。
• 结束判断：棋盘填满后，只要仍有相邻相同数字，就还有可行移动。
• 输入方式：桌面方向键和手机触摸手势都要检查，同时观察操作时页面是否意外滚动。
• 小屏布局：数字、得分和重新开始按钮应可见、可点击。

这些是建议采用的测试用例，不是声称本文已经在所有设备和浏览器上完成兼容性测试。出现异常时，应记录浏览器版本、具体棋盘和操作顺序，便于复现。

留下一份可解释的验收记录

这类练习可以用一张小表收尾：记录验收时间、路径、HEAD状态、GET状态、内容标记或摘要、实际测试过的浏览器，以及仍未覆盖的场景。这样以后看到截图或日志，能知道当时到底证明了什么。

如果只是短期云上练习，另建一份仅属于本次任务的资源清单，区分新建资源与原有资源。结束时按清单核对并回收本次新增项目，不能把“当前账号里能看到的资源”都当成临时资源。本次部署的相关临时资源已经回收，历史公网地址不再作为可用服务提供。

参考文档

• MDN Web Docs：《HEAD》HTTP请求方法说明。
• curl官方手册《curl — How To Use》，参考 --head、–fail、–dump-header 和 --output 参数，具体支持情况以本机版本为准。