做一个只在本机运行的 HTTP 缓存实验

下载配套文件并解压，在包含server.cjs和verify.cjs的文件夹打开PowerShell。先运行node --version确认版本，再运行node .\verify.cjs。验证脚本会自己选择可用端口、启动独立服务并检查响应，结束时只关闭它创建的进程。此时不必手动启动服务器。

末行显示passed，才表示这一轮检查完成。下载包中的verification-result.json只是制作时的记录，不能代替你电脑上的结果。如果出现FAIL，应先读失败项；不要为了避开端口问题结束其他程序，也不要把还没启动成功当成已经验证了缓存。

接着在第一个窗口运行node .\server.cjs。服务默认使用本机地址和3087端口，窗口中的ready行给出实际端口。再打开第二个PowerShell窗口，按README中的完整步骤创建客户端。那段说明保留标签里的双引号，并关闭旧版PowerShell客户端自动添加的上传预告。

先不带任何旧标签读取/message，记录状态、正文和ETag。ETag可以理解为这份内容的版本标签。本项目按实际发送的字节计算标签，所以改一个空格也算改动。它不是账号凭据；这里只用它比较教学文字，不把它当成身份验证。

现在先写下预测：内容未改时，带刚才的标签请求，会不会再次收到整段文字？再执行README中的条件请求。请求头If-None-Match携带已有标签，服务器按支持的规则比较，匹配时发送304，响应中没有正文。客户端若需要显示原文，应使用先前保存的内容。

再比较HEAD请求。它只询问响应头信息，成功返回200时同样没有正文，因此不能只凭正文为空判断缓存命中。还要一起看状态和标签。这里的no-cache要求复用前向服务器验证，不是禁止保存；命令行客户端用于观察响应，没有替你实现完整浏览器缓存。

通过README给出的PUT步骤，把教学文字改成第二版。然后保留最早的标签，再读同一个地址。比较新旧状态、标签和正文，接着用刚收到的新标签再请求一次。整个过程中只改变文字或请求标签，地址和运行中的服务器保持不变，才能说明结果差别来自哪里。

更新只存放在内存里，重启就恢复第一版。正文必须是合法的UTF-8纯文本，最多两千零四十八个字节，不能全是空白。服务器收完并检查后才替换内容；无效字节、过长或超时的上传会失败，不能把失败响应误认为新文字已经生效。

条件头只支持README列出的有限形式：单个带引号标签、弱标签、有限数量的标签列表或单独星号。完整协议允许的形式更多。其他条件请求与带条件的更新会明确被拒绝；这个短项目的作用是看懂流程，不能直接充当通用缓存服务器。

实验后在服务器窗口按Ctrl+C退出，并关闭客户端。这里没有数据库、登录或多人同时编辑保护，也没有测量网络加速倍数。你得到的是一组能重新执行的观察记录：请求带了什么、响应是什么、正文有没有传输，以及停止服务后哪些数据不会保留。