一份复盘在它的说法能被重新检查时才赢得信任。这意味着每个阶段都要点名产生该事实的命令,而不是某人记忆的转述。下面的四个阶段让任何写下来的复盘在日后都可复核。
检测:症状,而且要带证据
从最小的可验证症状与展示它的命令开始。“截图"好过一段散文描述:
$ check-http-headers.sh https://www.xbcatm.com/
HTTP/2 200
content-security-policy: ... script-src 'none' ...
last-modified: Mon, 24 Aug 2026 11:20:54 GMT
如果症状是某个响应头变了,那么展示旧策略与新策略的输出应并排放在一起。如果是失败,请包含退出状态与错误行。
界定范围:影响多广,以及你如何知道
用证据而不是形容词陈述爆炸半径。修复一个你能检视的边界:
- 哪些主机或路径返回同样的症状?每个候选主机跑一次
check-http-headers.sh就能回答。 - 缓存与源站是否不同?比较
Vary与验证器。 - 适用哪个回滚窗口?使用变更前仍生效的 TTL。
修复:变更及其预期效果
写出可重放的正确动作。优先选择恢复契约的最小变更,并说明修复后运行应显示什么:
# 期望出现在响应里的新策略行:
script-src 'none'
验证:事后运行
变更后重复检测命令,并演示观察到的输出现在与预期契约一致。没有最后这一节的复盘只是一个故事;有了它,它就是一份允许自己未来被再检查的记录。
来源
- RFC 9110 — HTTP Semantics,响应元数据与条件请求,已核验 2026-08-24。
- 制品 HTTP 响应头检查,贯穿本记录使用的只读检查。