HTTP 200之后还要验什么：一次2048临时预览的四层验收

一个开发预览地址返回了200，是否就能宣布“部署完成”？我在一次2048单文件网页实践中，把这句话拆成了四个不同的结论：源文件正确、服务返回正确文件、浏览器能够使用、业务平台接收成果。前三项通过，最后一项仍然可能失败。把它们合并成一个“成功”，会让排查方向和进度记录都失真。

本文使用我公开的2048单文件项目作为实例，只讨论开发测试环境的验收方法。临时预览已经结束，文中不提供过期隧道地址，也不涉及云账号凭证或其他业务资源。

第一层：确定到底部署了哪个文件

这个项目把样式与脚本都放进index.html，不需要构建工具。省掉构建步骤，不等于可以省掉版本核对。同一个文件名可能对应修复前后的不同内容，远端工作目录也可能保留旧版本。因此，我先固定公开仓库修订，再核对文件长度和SHA256。

这次实际用于预览的index.html为13474字节，SHA256是：

f1c6ae968888f5f8cac6d55dbd49bd954146a131514a41ff82af5ea6a876e018

随后直接运行仓库中的independent.test.cjs，8组独立测试通过。这里的结论有明确边界：这些测试覆盖游戏合并、方向变换、无效移动、撤销等逻辑，不证明公网隧道已经连通，也不证明手机实机体验已经验收。

文件哈希还不是功能证明。一个包含错误的文件同样能产生稳定的哈希。功能测试回答“逻辑是否符合预期”，哈希回答“部署的是否就是这份已测试内容”，两者需要配合。

第二层：把服务存活和正文一致分开

私有HTTP服务只提供两个路径：根路径和/index.html。两者都返回固定游戏文件，其他路径返回404，不提供目录浏览。这样可以缩小临时公开预览的范围，也避免顺手把源码目录、测试文件或工具配置一起暴露出去。

服务启动后，我先从私有地址读取页面，再通过官方DevBridge临时隧道读回公开地址。两处读取的正文都应当与已测试文件一致。实际公网核对记录是：HEAD返回200，GET返回200，GET正文13474字节，响应SHA256与源文件相同。

在Windows PowerShell中，可以把核对步骤写成下面这样。这里必须先将变量换成自己拥有、仍然有效的预览地址；不要把带有身份凭证的链接填入命令或公开文章。

$previewUrl = 'https://YOUR-PREVIEW-HOST/index.html'
curl.exe -sS -I --max-time 20 $previewUrl
curl.exe -sS --max-time 20 -o preview-response.html $previewUrl
Get-FileHash -LiteralPath ./index.html -Algorithm SHA256
Get-FileHash -LiteralPath ./preview-response.html -Algorithm SHA256

HEAD适合先观察响应头，它不会下载页面正文。即使HEAD是200，也可能只说明默认欢迎页、网关说明页或者其他页面可达。GET取得正文后，才能核对内容；哈希不一致时，先检查返回的是否为预期页面，再判断是否有旧文件或中间层。

状态码和内容都应分别记录。500与200但正文错误是两种故障，处理动作不一样。为验证这一点，我另外建立一次只监听127.0.0.1的临时HTTP对照，测试了三种情况：正确正文200、错误正文但仍200、服务返回503。三组对照均通过，测试结束自动关闭监听。它们验证的是“状态码相同也可能内容不同”这个判断，不替代真实公网访问。

如果正常浏览器出现服务提供方的访问提示，应先阅读并按正常流程处理；若遇证书或浏览器安全拦截，应处理真实配置问题，不能靠关闭校验把故障写成通过。

第三层：让浏览器真的走一遍交互

GET读回正确文件，只证明HTML及内联资源抵达了浏览器，并没有执行一次游戏操作。接下来需要从公开入口打开页面，观察棋盘、分数和按钮，再用方向键移动。我的实际观察是：棋盘成功显示，方向键操作后新增方块；这与单纯看到标题“2048”相比，是更完整的交互证据。

验收动作应针对风险，而不是堆次数。例如游戏有撤销功能，就验证移动后撤销是否恢复棋盘与分数；游戏宣称支持手机，就应分别说明响应式布局检查与手机实机操作有没有完成。没有执行的项目写“未验证”，不要把桌面浏览器窄窗口自动等同于手机实机。

这层还可以发现一些HTTP工具看不到的问题：脚本执行错误、按钮遮挡、键盘焦点冲突，以及页面看起来加载完但关键操作无法完成。遇到问题时，保留可复现步骤，比反复刷新并猜测网络原因更有效。

第四层：业务接收有自己的验收条件

技术预览可用之后，我按官方页面的正常表单提交了真实作品链接，并在说明中写清实际使用的是免费体验容器。提交接口返回“活动不存在或已结束”，页面进度没有变化。之后官方活动页又展示了资源紧张提示。

因此，这次可以记录“公网预览验证通过”，同时记录“活动成果提交未通过”，而不能把前者直接替代后者。究竟是资源、活动配置还是其他原因，应以平台的实际回执和后续处理结果为准；没有证据时，不自行认定后台根因。

遇到这种状态，继续修改游戏合并算法通常不能解决问题；反复生成新地址、重复提交或切换接口，也会使记录更难对应。更有效的做法是保留一次完整回执，注明提交时间、作品版本和使用环境，通过同一个正常支持渠道询问恢复与接续方式。临时环境到期或关闭后，旧链接失效也应如实更新，不能继续把旧的200结果描述为当前在线。

用一张表保存结论边界

开发预览完成后，我只停止本次创建的托管，并释放这次临时体验容器，没有执行全局进程清理或删除其他隧道。源码、测试和回执保留下来，后续可以在正常条件恢复后继续，而不需要把环境一直空挂。

这套记录方式的价值，是让“成功”始终对应一个可检查的事实：文件正确、HTTP正确、交互正确和业务接收各自成立，缺哪层就补哪层。这样既能减少误报，也能避免在错误的层面反复修改。