发布流程里最薄弱的一环，是「发布后验证」。

大部分团队的做法是：发完，刷新一下首页，能开，收工。

人工验证的三个漏洞

只测了一个页面，可能坏的是登录或者支付。

只在自己网络测，可能坏的是某个省。

只测了一次，可能赶上缓存刚好命中，真实情况被掩盖。

门禁怎么设

发布完成后，流水线调一次拨测，跑三到五个关键 URL，覆盖首页、列表页、接口、登录后页面。

判定条件写死：状态码必须 200，TTFB 不超过基线的 1.5 倍，至少三个地区通过。

不达标就 fail，流水线停在那里，人工决定回滚还是修。

关键 URL 怎么选

选那种「挂了就等于业务挂了」的页面。首页、商品详情、下单接口、支付回调页面。

别选一堆边缘页面，跑得慢还说明不了问题。

等多久再测

发布完成后等 30 秒到 1 分钟，让服务启动、缓存预热。立刻测会误判。

带 Cookie 的页面要单独处理，token 有有效期，得从测试账号动态取。

数据要存下来

每次发布的检测结果存进发布记录。三个月后回头看，能发现「每次发版 TTFB 都涨一点」这种慢性问题。

别做成阻塞式

门禁失败不等于自动回滚。有些问题（比如某个边缘地区慢）可以带着发布继续观察。

让流水线停下并通知人，比自动回滚更安全。

起步可以很轻

不用一上来就接 API。发布脚本最后加一步，跑一次 网站测速，把结果打印出来，先养成习惯。跑顺了再接到 监控控制台 做定时任务。