用码道迭代离线验收页：输入一变，旧证据就该失效

本文基于实际的“静态站点验收清单v2”开发和浏览器验证记录，使用AI协助开发与整理。码道负责核心功能生成与问题修复，另做了小范围CSS调整及独立验证。所有演示输入均为固定示例，不代表某个真实公网服务的状态。

一页工具，为什么需要证据状态

最初的验收清单可以生成检查命令、记录结果并输出报告。继续迭代时，我们增加了离线HTTP响应解析和SHA-256文本比对：用户在自己环境执行请求，再把结果粘贴到页面。页面本身不访问目标网址。

这种设计避免了直接在浏览器内请求任意站点，也让用户可以先检查并去掉敏感响应头。但它带来一个容易遗漏的问题：结果究竟属于哪次输入？

例如，用户先输入地址A，记录HTTP结果和哈希一致，再把地址改为B。如果界面仍显示之前的成功结果，报告就会把A的证据错误地关联到B。功能按钮都能点击，业务结论却已经失真。

将目标和证据分开保存

我们给码道的迭代要求包括：HTTP离线解析、哈希比对、报告预览同步，以及输入变化后让旧结论失效。这里最重要的不是按钮数量，而是证据之间的依赖关系。

可以把页面理解为三层：目标URL、原始粘贴输入、由当前输入推导出的结论。URL发生变化，旧站点的记录需要失效；响应头发生变化，之前解析出的状态需要失效；哈希文本变化，则应重新计算比对结果。

实现时不应仅在“生成报告”按钮被点击时才处理失效。用户编辑的那一刻，界面上已经显示的旧结论就应及时清除或标明待验证，报告预览和导出入口也应一起更新。

我们实际发现的三个同步问题

第一轮浏览器验证发现，哈希区域显示了新的比对结果，但报告预览没有同步。第二个问题是修改URL后，旧数据没有立即失效。第三个问题发生在响应头编辑之后，先前解析状态仍然残留。

这三处问题都通过具体操作路径反馈给码道修复，而不是只给一句“请完善状态管理”。复现步骤写成“输入什么、点击哪里、修改哪个字段、预期哪个区域变化”，可以直接转成下一轮的回归检查。

例如一条关键路径是：填写合法URL，粘贴包含最终200响应的固定样例，完成解析，然后将URL替换为另一个地址。预期结果是相关旧证据不再被当作新目标的验证结论，预览和导出状态也与之保持一致。

离线HTTP解析的边界

粘贴文本可能含多个HTTP响应块，比如先重定向再返回最终结果。当前工具围绕固定样例检查最后一个响应块，并覆盖HTTP/1.1、HTTP/2、HTTP/3形式，以及Content-Type名称大小写等情况。

这里得到的是“粘贴文本中写了什么”，而不是工具亲自完成的公网请求。输入可能被截断、复制错，也可能来自旧请求。因此报告应保留这种来源说明，不能把离线解析包装成实时连通性检测。

同样，两个SHA-256文本相同只能说明这两段输入一致。只有哈希确实来自对应版本的本地文件和远端响应体时，它才支持内容一致性判断；哈希比对本身不证明来源可信，也不替代页面交互验收。

报告要尽量少带原始数据

演示报告只保留验收所需的结果摘要，不附带整段响应头、Cookie或完整哈希。真实响应里可能出现会话、内部标识等信息，复制到页面之前仍要先检查。

当前最终源码的静态检查未发现网络请求、浏览器存储、遥测，以及外部脚本或样式依赖。这是对本次最终文件的检查结论，不能泛化为所有未来版本都具备相同性质。后续每次改版仍需重新检查。

验收记录与限制

最终版本完成了12项独立浏览器交互和布局检查，内置固定自测显示14/14通过。还在390px宽度检查了布局，并修正了下拉框挤压文字的问题。

这里有一个需要如实保留的限制：浏览器按钮显示导出成功，且可见的Markdown预览内容已保存，但本次没有独立确认操作系统下载目录中实际生成了对应文件。所以记录为“导出交互提示通过，下载落盘待独立确认”，不把两者合并成一句全部通过。

后续如果扩展自动化测试，我会优先覆盖跨字段联动：改URL、改响应头、改哈希时分别检查结果区域、报告预览和导出入口。因为这些共享状态之间的不一致，比单个输入框是否接受文本更容易影响最终验收结论。

这次迭代让我更明确地把页面输出看作附有来源和有效条件的证据。界面显示成功只是一个状态；成功属于哪个目标、哪份输入，以及输入变更后是否仍然有效，才决定报告能否被可靠使用。