必须做合并后回归测试，因merge仅解决文本冲突，不保障逻辑兼容性；需验证受影响路径、主干链路、依赖变更及环境配置，否则上线易现功能异常、接口报错等问题。
合并分支后不做回归测试，等于没合并。 很多团队在 git merge 完就直接 git push，结果上线才发现功能异常、接口报错、UI错位——问题不是出在合并本身，而是跳过了验证环节。
为什么必须做合并后回归？
merge 操作只解决代码文本层面的冲突，不保证逻辑兼容性。常见风险包括：
- 两个分支各自修改了同一函数但语义不同，自动合并成功，运行时才暴露逻辑错误
- feature 分支依赖某个未提交到 develop 的 mock 工具，合并后本地能跑，CI 环境失败
- 样式文件被覆盖或重复引入，CSS 优先级错乱，视觉回归失效
- 数据库迁移脚本未同步，
flyway或liquibase执行时报错
本地回归要测什么？
不是全量跑一遍自动化测试（那太慢），而是聚焦「受影响路径 + 主干链路」：
MergeIQ: Automatically Score & Prioritise PR Complexity for GitLab and GitHub
下载
使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...
- 手动验证本次合并涉及的所有页面、API 接口、核心交互流程（比如登录 → 下单 → 支付）
- 检查
git status和git diff origin/develop（假设目标是 develop），确认没有意外带入的调试代码、console、临时注释 - 运行与改动强相关的单元测试：比如改了订单计算逻辑，就只跑
npm test -- --testPathPattern=order - 用
git log --oneline -n 10确认最新 commit 是你预期的 merge commit，而不是某人误操作的孤立提交
CI/CD 环境里容易漏掉的关键点
很多团队把「CI 通过」当成回归完成，但 CI 常有盲区：
- CI 默认跑的是
origin/develop，不是你本地 merge 后的状态 —— 必须确保 pipeline 触发的是 merge commit 对应的 SHA，而非 feature 分支最后那个 commit - 前端项目常忽略构建产物比对：用
diff -r dist/ dist-old/查看是否多打包了冗余模块或丢失了 polyfill - 后端集成测试若只跑单服务，可能掩盖跨服务调用失败（比如 A 服务升级了 DTO，B 服务没更新 client jar）
- 数据库变更未在 CI 中执行 migration：需在 pipeline 中显式加一步
./gradlew flywayMigrate -Penv=test
回归失败时怎么快速定位？
别急着 revert，先缩小范围：
- 用
git bisect从 merge commit 往回二分，快速锁定引入问题的具体 commit（注意：需有可运行的测试用例作为判断依据） - 对比 merge 前后的
package-lock.json或yarn.lock，看是否有意料外的依赖版本升级 - 检查 CI 日志里是否有 warning 被忽略，比如 TypeScript 的
noImplicitAny报错降级为 warning，实际已破坏类型安全 - 如果问题只出现在特定环境（如 staging），优先查
.env.staging里是否覆盖了关键配置项，而不是代码本身
回归测试不是流程上的“最后一道工序”，它是 merge 操作不可分割的一部分。最常被跳过的，恰恰是最不该省的那一步 —— 尤其当 merge 提交信息写着“fix ci”或“merge develop”这种模糊描述时，更要盯紧实际变更内容。
