提交代码审核被拒？这些常见原因你可能天天在犯

格式混乱，一眼就被打回来

刚写完代码，兴冲冲提交审核，不到十分钟就收到“拒绝”通知。打开一看，没具体理由，只有一句“请规范代码风格”。这种情况太常见了。很多团队用了 Prettier 或 ESLint，但你本地没配，结果缩进用的是 Tab，别人全是空格；括号换行方式不一样，甚至分号都时有时无。机器都能检测出来的问题， reviewer 通常直接拒掉让你重改。

function getUser(id) {
    return db.find(u => u.id == id)
}

上面这段看着没啥大问题，但如果项目要求必须加分号、箭头函数体换行，那它就是不合格的。别觉得这是小题大做，统一格式能减少合并冲突，也方便后期排查。

注释要么太多，要么没有

有些同学写代码像写日记，每行都有注释：“// 这里开始循环”、“// 调用接口获取数据”。其实变量名和结构已经足够清晰，这种注释纯属干扰。反过来，另一些人写了个复杂算法，比如处理时间戳偏移的逻辑，却一个字不写，reviewer 看半天才明白意图，这种大概率也会被拒。

合理的做法是：简单操作不用注，复杂逻辑补说明。比如：

// 将客户端本地时间转换为 UTC，并补偿网络延迟（约 200ms）
const utcTime = new Date(localTime - 200).toUTCString()

测试用例缺失或敷衍了事

加了个新功能，改了核心逻辑，却没有新增测试用例，或者只测了正常路径，异常情况直接忽略。CI 流水线可能卡住，reviewer 更不会放行。特别是涉及到金额计算、权限判断这类敏感逻辑，少一个边界测试都可能被退回来。

比如你写了这样一个函数：

function calculateDiscount(price, level) {
  if (level === 'vip') return price * 0.8;
  return price;
}

测试里只验证了 vip 用户打折，但没测 price 为负数或 level 是 null 的情况。这种漏洞明显的代码，基本过不了审核。

提交信息写得像谜语

git commit 写的是“fix bug”或者“update code”，这种信息对 reviewer 来说毫无意义。他们不知道你到底修了啥，也没法追溯变更原因。规范的提交信息应该说明动机，比如：“修复用户登出后 token 未清除导致误登录问题”。

想象一下，几个月后有人发现一个 bug，翻 git log 找修改记录，看到满屏的“修改文件”、“调整逻辑”，根本没法下手。负责任的团队会对提交信息有明确要求，不合规直接打回。

一个人改了十几个文件，还全是无关改动

本来只是修个按钮样式，结果顺手把整个项目的 import 顺序整理了一遍，连隔壁模块的日志输出也重构了。这种“顺手改”最容易被拒。因为 reviewer 得额外花时间确认这些附带修改有没有引入新问题，风险太高。

一次提交只解决一个问题，这是基本原则。想优化其他地方？另开分支，单独提 MR。别让一个小修bug变成高风险合并事件。

忽视 CI/CD 报错提示

提交后 CI 明明标红了：单元测试失败、代码覆盖率下降、安全扫描出高危依赖。你还去 @reviewer 让人家看。这种情况，多数人会直接留言“先修 CI”，然后关闭页面走人。自动化流程已经告诉你有问题，非要让人肉再指出一遍，显得不够专业。

有个同事曾提交代码，ESLint 报了 15 个警告，他觉得“不影响运行”，结果被 team lead 在群里点名。后来大家笑称他的 MR 是“告警炸弹”。别成这样的反面教材。