修复回归验证的关键证据链

修复回归不能只看异常响应是否消失。有效的证据链需要同时回答：修复针对什么问题、变更是否实际生效、修复前后比较是否可复现，以及正常功能是否仍然可用。缺少其中一环，即使某次测试结果符合预期，也不足以证明修复已经落实。

从修复依据到运行实例

证据链的起点是可核验的漏洞记录或厂商公告，包括受影响组件、版本范围、必要配置和对应分支的修复依据。再用配置清单、软件包信息、镜像摘要或管理界面记录目标状态，确认实际处理流量的实例已经更新。仅凭响应中的 Server 头，或磁盘上已安装的软件包，不能判断运行实例的补丁状态。

如果尚未取得权威资料，就应将漏洞对应关系和修复版本标记为“待核实”。此时观察到的响应差异只能作为一般输入处理差异，不能直接归因于特定漏洞。

让前后比较具有可比性

回归前应保存正常基线和经批准的边界输入，以及脱敏后的原始请求、响应和日志关联标识。以 Host 值差异测试为例，比较时保持连接入口、TLS SNI、协议、方法、路径及其他请求头一致，只改变被测的 Host 值，并确认代理没有改写它。修复后沿用相同样例和观察字段，才能将结果与变更前对应起来。

状态码或响应头变化本身不等于安全影响，也不等于修复成功。代理、负载均衡器和应用都可能参与处理；缓存命中状态变化也可能影响响应。应结合各层日志判断响应来自哪里，并记录重复结果及无法排除的中间层影响。

按证据强度给出结论

公告所述异常不再出现，且正常请求仍可用时，可记录为“当前环境和样例下回归通过”，而不是宣称所有入口均已安全。异常仍可复现时，应检查未更新实例、补丁识别和代理层差异；结果不稳定或版本无法确认，则保持“待复核”。

若修复引入业务故障并按预案回滚，目标不能继续视为已修复。最终交接应保留授权范围、变更前后状态、请求与响应、日志关联信息及结论限制，使其他人员能够沿同一证据链复核。