回归测试必须精准覆盖变更影响面，而非仅重跑用例；需通过git定位实际变更文件，结合依赖分析、openapi比对、引用搜索动态生成自动化测试清单，并执行跨功能集成验证。
误合并后不做回归测试就上线，等于把风险直接交给用户。回归测试不是“再跑一遍用例”，而是要精准覆盖被合并分支引入的变更影响面。
哪些提交需要被回归测试
不能只看 merge commit 本身，得顺藤摸瓜找出实际带入的代码变更：
- 用
git merge-base develop release-202607找出两个分支最近共同祖先，再用git log --oneline develop ^$(git merge-base develop release-202607)列出 release 分支独有的提交 - 如果 merge 是 squash 类型，
git show --stat <merge-commit></merge-commit>查看修改了哪些文件，再结合git blame定位关键逻辑行是否被改动过 - 跳过仅含文档、配置注释、空行调整的提交（但需确认 CI 流水线未因配置项变更隐式启用新功能）
测试范围必须绑定变更路径而非分支名
叫 release-202607 的分支不等于只测“这次发布功能”——它可能合入了某个 feature/payment-v2，而该功能调用了公共模块 utils/validator.js；一旦 validator 被改，所有调用它的支付、订单、退款流程都得重测。
- 从变更文件出发，用项目依赖图（如
depcheck或构建产物分析）反向找出所有直连/间接调用方 - 对 API 层变更，检查 OpenAPI spec diff，识别新增/删除/参数变更的 endpoint，并标记其上下游消费者服务
- 前端组件变更需查
git grep -l 'ComponentName'找到所有引用位置，不能只测该组件自身 demo
自动化回归清单要能动态生成
手写测试清单会漏、会滞后、会变成废纸。真正可用的清单必须由代码变更自动触发生成：
- 在 CI 流水线中加入一步：解析本次 merge 引入的
.ts/.java文件列表 → 匹配预设的“模块-测试套件映射表” → 输出待执行的jest --testNamePattern或mvn -Dtest=PaymentServiceTest参数 - 映射表示例：
src/payment/.*\.ts → payment-regression-suite，src/core/auth/.*\.java → auth-integration-suite - 禁止把“全量 smoke test”当回归——它掩盖真实风险，且耗时不可控；应让每次回归平均控制在 8 分钟内可完成
最容易被忽略的一点：合并后 CI 通过 ≠ 可以上线。很多团队卡在“流水线绿了就合进主干”，但没验证 develop 上其他未合入的功能是否被这次合并意外破坏——比如新引入的全局 CSS class 名冲突、日志级别被统一调高导致 debug 信息丢失、数据库 migration 脚本里加了 NOT NULL 但旧数据没清理。这些必须靠跨功能的集成回归来捕获，而不是单看当前分支的单元测试。
