上线前发现回归测试失败，先别急着改
项目做到最后一步，眼瞅着能上线了，回归测试却卡住了。这时候最容易犯的错误就是一群人围在会议室里拍脑袋：赶紧修、马上改、今晚必须搞定！结果往往是改出更多问题，上线日期反而拖得更久。
正确的做法是先冷静下来，把问题分类。回归测试不通过无非几种情况：核心功能出错、边缘功能异常、环境配置问题、数据兼容性故障。不同问题处理方式完全不同。
核心功能出问题，必须停步排查
比如支付流程走不通、用户登录直接报错这种影响主链路的问题，别犹豫，暂停上线流程。这时候要拉上开发、测试、产品一起看日志、对齐预期行为，确认是代码逻辑缺陷还是部署包有问题。
常见的情况是某个看似无关的优化动了底层方法，导致其他模块调用时崩掉。这时候不能只修表面现象，得顺藤摸瓜找到改动源头。
非关键路径异常，评估影响再决定
像帮助中心打不开、头像上传慢一点这类问题，可以和产品经理快速评估影响范围。如果涉及用户量小、有替代方案，完全可以记录为已知问题，上线后热修复。
举个例子，之前做过一个电商项目，回归测试发现优惠券列表偶尔加载失败。排查发现是第三方接口超时，但主购物流程完全正常。团队评估后决定先上线，同时后台加监控，第二天就推了补丁。
环境或数据问题，别当成代码锅
有时候测试环境数据库没同步，或者缓存没清，看起来像是功能坏了。遇到这种情况，先确认测试前提是否满足。比如有没有清浏览器缓存，测试账号是否有权限，mock数据是不是最新的。
有个典型的例子：测试说订单状态不更新，查了一圈代码没问题，最后发现是定时任务的cron表达式在测试环境写错了，根本没触发。这种跟代码无关的问题，修起来很快，但前提是别一开始就往代码上想。
紧急应对后的必要动作
不管最后怎么处理，当天必须开个短会，把这次失败的原因记下来。是自动化测试覆盖不够？是合并代码时没做充分自测？还是发布流程缺少检查项？
把这些写进文档，下次发布 checklist 里加上一条，同样的坑就不会踩第二遍。技术这行，不怕出问题，怕的是同一个问题反复出。