合并前必须核对5类代码变更：敏感配置项、数据库变更、第三方服务调用、权限与日志、依赖变更；须结合commit message和author排查上下文风险；必须运行本地测试、lint、构建及启动验证；警惕时区处理、浮点数比较等隐性风险。
合并前必须核对的 5 类代码变更
Git 分支合并申请单不是走形式，是防止 main 被污染的最后一道人工检查。重点不是“有没有改”，而是“改得对不对、安不安全”。自查表要能快速定位风险点，不是罗列所有 diff 行。
-
敏感配置项：检查
.env、config/*.yml、application.properties是否混入测试值（如DB_URL=127.0.0.1）、硬编码密钥（SECRET_KEY="dev-key"）或未加注释的调试开关（DEBUG=true） -
数据库变更：确认
migration文件名含时间戳且无重复；SQL 中DROP TABLE、ALTER COLUMN ... TYPE等破坏性操作已加注释说明回滚方式；未出现DELETE FROM users WHERE 1=1这类危险语句 -
第三方服务调用：检查 API 地址是否仍指向
http://localhost:8080或测试域名（如api-staging.example.com）；密钥是否从环境变量读取（process.env.API_KEY），而非写死在代码里 -
权限与日志：确认新增接口有鉴权逻辑（如缺失
@RequireRole("ADMIN")注解）；敏感操作（如密码重置、资金转账）是否记录了可追溯日志（logger.info("User <id> reset password via email")</id>） -
依赖变更：查看
package.json或pom.xml中新增/升级的包是否带^或~锁定版本（如"lodash": "^4.17.21"）；排除devDependencies误入生产依赖（如webpack出现在dependencies下）
为什么不能只看 diff，还要查 commit message 和 author
一个 git diff 看不出上下文风险。比如某次提交标着 fix login bug，但实际改了支付网关的签名算法——这种错位只有结合 commit message 和作者身份才能发现。
- commit message 必须包含 Jira ID 或 issue 编号（如
PROJ-123: fix token refresh race condition），否则无法追溯需求来源 - 检查 author 是否为预期开发者：避免 CI 账号（
github-actions[bot]）或离职人员账号提交关键逻辑 - 多个小 commit 合并成一个 PR 时，要确认每个 commit 的 message 都有意义，而非全是
update、fix这类无效描述
合并前必须运行的本地验证命令
光靠肉眼检查远远不够。以下命令必须在本地执行并通过，才允许提交合并申请单：
- 运行单元测试：
npm test或mvn test，确保新增/修改代码覆盖率达到团队基线（如 ≥70%） - 检查 lint 错误：
npm run lint或./gradlew ktlintCheck，禁止出现no-unused-vars、no-console等未修复警告 - 验证构建产物：
npm run build或mvn package，确认输出目录（如dist/或target/）生成完整，无缺失文件或空目录 - 启动本地服务：
npm start或java -jar target/app.jar，手动访问关键路径（如登录页、订单创建页），确认无 500 错误或空白页
被忽略最多的 3 个隐性风险点
这些地方不会报错、不显眼，但上线后极易引发线上事故：
-
时区处理：前端传
"2024-05-20T12:00:00Z"，后端用new Date()直接解析，结果在服务器时区下变成错误日期——应统一用moment.utc()或Instant.parse() -
浮点数比较：代码中出现
if (a == b)判断两个number类型，尤其在金额计算场景，必须改用Math.abs(a - b) -
并发控制缺失：新增的优惠券领取接口没加分布式锁（如 Redis lock），也没做数据库唯一约束，导致超发——自查时要重点扫
if (!couponUsed) { useCoupon() }这类竞态代码块
真正卡住合并的往往不是大功能，而是某行看似无害的 console.log 没删、某个 TODO 注释没处理、或者一个没加 try-catch 的外部 HTTP 调用。这些细节，比功能逻辑更需要逐行盯。
