系统是否更稳取决于三类错误的分布变化：高危alert归零、中危error日均降超80%、低危warning不再新增；需结合access.log中5xx率
直接对比重构前后的错误日志分布和趋势，比任何报告都更能说明系统是否真的更稳了。重点不是错误总数少了多少，而是高危错误是否归零、中危错误是否断崖下降、低危警告是否不再反复出现。
锁定三类关键错误做基线对比
先从重构前 7 天的 error.log 中提取三类错误的每日频次，作为基线：
- 高危 alert：如 “Permission denied”、“Connection refused”、“segmentation fault”，这类错误只要存在，就说明存在随时中断服务的风险；
- 中危 error：如 “Connection reset by peer”、“upstream timed out”、“no live upstreams”，反映后端链路或网络层不稳定；
- 低危 warning：如 “could not build optimal server_names_hash”、“deprecated directive 'if'”，不致命但暴露配置陈旧或资源设计缺陷。
重构后连续 7 天做同维度跟踪
用相同命令提取新日志中的三类错误频次，推荐脚本化执行以避免人工误差：
- 统计 alert 数量：
grep '\[alert\]' /var/log/nginx/error.log | wc -l - 统计 error 数量：
grep '\[error\]' /var/log/nginx/error.log | wc -l - 统计 warning 数量：
grep '\[warn\]' /var/log/nginx/error.log | wc -l
每天定时运行并存入 CSV，生成折线图——若 alert 归零、error 日均下降超 80%、warning 不再新增，基本可判定核心稳定性提升成立。
结合访问日志交叉验证隐性收益
错误日志变“干净”不等于体验变好，还要看 access.log 是否同步改善：
- 5xx 错误率是否从重构前的 1.8% 降至 0.2% 以下；
- 95 分位响应时间（$request_time）是否从 1200ms 压至 300ms 内；
- 499（客户端断连）数量是否明显减少，说明请求不再因卡顿被频繁放弃。
关注错误类型迁移而非单纯减量
如果重构后 error 总数没变，但原来集中在 upstream 的 error 消失了，转而出现更多 ssl_handshake_timeout 或 http_v2_* 相关 error，说明问题从后端转移到了协议层——这不是退步，而是把隐藏更深的问题暴露了出来，恰恰是重构的价值所在。
