1. 为什么“推代码前先 /review”值得单独拎出来说1.1 一个被大多数人忽略的真相质量和安全从来不是同一件事先把结论摆在最前面代码质量审查和安全审查是两条平行线永远不要指望用同一个动作同时搞定。我见过太多团队在 CI 里挂一个 lint 工具跑过了就认为“质量没问题了”再挂一个依赖扫描没报高危漏洞就认为“安全也没问题了”。然后某天线上出了一个空指针把服务打挂或者一个越权接口被人刷了一遍复盘的时候大家面面相觑——工具明明都过了。问题出在哪出在质量审查关注的是“代码能不能按预期工作”安全审查关注的是“代码在被人恶意使用时会不会出问题”。这两个问题的出发点完全不同检查的维度也完全不同。举个特别朴素的例子。一个用户查询接口参数是userId代码写得干干净净命名规范、函数短小、有单元测试、覆盖率 90%质量审查满分。但是这个接口没有校验“当前登录用户是否有权查询这个 userId 的数据”任何人改一下 URL 里的数字就能看到别人的信息。质量没问题安全是零分。反过来一个接口做了严格的鉴权、参数白名单、SQL 注入防护、速率限制安全审查满分。但代码里全是 500 行的巨型函数、魔法数字满天飞、异常处理全靠catch(Exception e){}三个月后没人敢改。安全没问题质量是零分。所以“推代码前先 /review”这个动作核心不是让你多跑一个命令而是让你在脑子里建立两条独立的检查线。下面我会把这两条线拆开讲清楚再讲怎么把它们串成一个不折磨人的工作流。1.2 谁最需要这套东西如果你符合下面任意一条这篇内容就是写给你的团队里没有专职的代码审查人员大家都是“谁有空谁看一眼”用过 Cursor 这类 AI 辅助工具但只把它当补全用没想过让它做审查CI 里挂了工具但说不清楚每个工具到底在查什么每次发版前都心虚总觉得“应该没问题吧”被线上事故教育过但复盘时只能得出“下次注意”这种没用的结论我自己的经历是早期带项目的时候代码审查就是“同事扫一眼点个 approve”安全审查基本靠“感觉”。直到有一次一个内部接口因为没做权限校验被爬了一遍数据才开始认真对待这件事。后来慢慢摸索出一套用 AI 工具辅助 人工聚焦关键点的方法效率比纯人工高很多也比纯工具靠谱很多。2. 把“审查”拆成两条线质量线和安全线2.1 质量审查到底在查什么质量审查的目标是可维护性和正确性。具体拆开看大概是这几个维度可读性命名是否表意、函数是否单一职责、注释是否解释了“为什么”而不是“是什么”。这一块是最容易被工具覆盖的lint 规则基本能搞定 80%。正确性边界条件有没有处理、异常路径有没有覆盖、并发场景有没有考虑。这一块工具只能帮你发现一部分比如空指针、资源未关闭但业务逻辑层面的正确性还是得靠人。一致性同一个项目里错误处理方式是否统一、日志格式是否统一、接口返回结构是否统一。这一块最容易被忽视但它是团队协作效率的隐形杀手。我见过一个项目里三种不同的错误返回格式前端同学每次对接新接口都要问一遍“这个接口报错返回啥”。可测试性代码是否容易写测试、依赖是否可注入、副作用是否隔离。这一块在写的时候就要考虑审查的时候主要是看有没有“明显没法测”的写法比如在函数内部直接 new 一个数据库连接。性能隐患循环里查数据库、大对象频繁创建、没必要的全表扫描。这一块需要审查者对业务数据量有感知工具很难判断“这个循环会不会跑一万次”。2.2 安全审查到底在查什么安全审查的目标是在恶意输入和恶意使用下系统是否还能保持预期行为。这个视角和 quality 完全不同它假设“所有人都是坏人”。输入验证所有外部输入是否都经过校验。注意是“所有”包括 URL 参数、请求体、Header、Cookie、文件上传内容。我见过只校验了请求体、忘了校验 Header 里某个字段导致注入的案例。权限控制每个操作是否都检查了“当前用户是否有权做这件事”。这里有个常见的坑只检查了“是否登录”没检查“是否有权操作这个资源”。前者是认证后者是授权两码事。数据暴露返回给前端的数据是否包含了不该包含的字段。比如用户信息接口把密码哈希、内部 ID、手机号全返回了。这个在质量审查里完全看不出来因为代码“工作正常”。注入类问题SQL 注入、命令注入、模板注入、XSS。这类问题的共同点是“用户输入被当成了代码或指令执行”。现代框架大部分场景已经帮你处理了但一旦你用了字符串拼接框架也救不了你。敏感信息处理密钥是否硬编码、日志是否打印了敏感数据、错误信息是否暴露了内部结构。这一块在代码审查时特别容易被放过因为“能跑就行”。依赖安全引入的第三方库是否有已知问题、版本是否过旧。这一块必须靠工具人脑记不住那么多版本信息。2.3 两条线的交叉点那些既影响质量又影响安全的地方有些问题同时属于两个范畴最典型的是错误处理。从质量角度看错误处理要清晰、要能帮助排查问题。从安全角度看错误处理不能泄露内部信息、不能因为异常导致权限绕过。比如一个登录接口密码错误时返回“用户名不存在”还是“密码错误”从质量角度看前者更友好从安全角度看前者会被人用来枚举用户名。这种地方就是两条线的交叉点需要同时考虑。再比如日志。质量角度希望日志越详细越好方便排查。安全角度希望日志里不要有敏感信息。这两个诉求是冲突的需要根据具体场景做权衡。我的做法是在审查清单里把这类交叉点单独列出来每次审查时专门过一遍。下面会给一个具体的清单。3. 用 Cursor 做审查具体怎么操作3.1 为什么选 Cursor 而不是纯靠人眼先说清楚Cursor 不是替代人工审查而是把人工审查的注意力从“找低级问题”转移到“判断关键决策”上。人眼审查代码有个致命问题注意力是有限的。你盯着一个文件看十分钟前五分钟能发现命名不规范、缺少边界检查这类问题后五分钟就开始走神了看到if (a b)这种赋值当判断的 bug 都可能滑过去。Cursor 这类工具的价值在于它可以不知疲倦地做第一遍扫描把明显的问题列出来然后人只需要判断“它说的对不对”和“有没有它没发现的”。这个分工比纯人眼高效得多。具体来说我用 Cursor 做审查主要用它三个能力对话式审查选中一段代码直接问“这段代码有什么潜在问题”自定义规则通过.cursorrules文件定义项目的审查规则多文件上下文让它同时看几个相关文件发现跨文件的逻辑问题3.2 配置一个专门用于审查的提示词Cursor 的默认行为是“帮你写代码”但审查场景需要的是“挑毛病”。这两个目标的提示词完全不同。我的做法是在项目根目录放一个.cursorrules文件专门定义审查相关的规则。下面是我实际在用的一个配置你可以直接抄# 代码审查规则 ## 审查视角 你是一个严格的代码审查者不是代码生成者。 你的任务是找出问题不是重写代码。 ## 质量维度检查项 1. 命名是否表意清晰是否存在误导性命名 2. 函数是否单一职责是否超过 50 行 3. 边界条件是否处理空值、空集合、极值、并发 4. 异常处理是否合理是否存在吞异常的情况 5. 是否存在重复代码是否可以抽取 6. 日志是否合理是否包含足够的排查信息 7. 是否存在明显的性能隐患循环内 IO、N1 查询 ## 安全维度检查项 1. 所有外部输入是否都经过校验 2. 每个操作是否检查了权限不只是登录状态 3. 返回数据是否包含敏感字段 4. 是否存在字符串拼接构造 SQL/命令/模板 5. 敏感信息是否硬编码 6. 错误信息是否泄露内部结构 7. 日志是否打印了敏感数据 ## 输出格式 按严重程度分级输出 - [阻断] 必须修复才能合并 - [重要] 应该修复除非有明确理由 - [建议] 可以考虑优化 每个问题必须包含 - 文件路径和行号 - 问题描述 - 为什么这是问题 - 修复建议不要直接给完整代码给思路这个配置的关键在于明确告诉它“你是审查者不是生成者”。如果不写这句Cursor 很容易变成“帮你重写一遍代码”那就失去审查的意义了。3.3 实际操作流程从提交到合并我现在的流程是这样的你可以根据团队情况调整第一步本地自查。写完代码后不急着提交先在 Cursor 里选中改动的文件用/review或者直接问“按项目审查规则检查这段代码”。这一步能过滤掉 60% 以上的低级问题。第二步修复阻断项。Cursor 标为 [阻断] 的问题必须当场修掉。标为 [重要] 的判断一下是否真的重要如果是就修如果不是就在提交信息里说明理由。第三步提交并触发 CI。CI 里跑的是工具链包括 lint、单元测试、依赖扫描、静态分析。这一步是兜底防止本地漏掉的问题流到主干。第四步人工审查。到了这一步代码已经没有低级问题了人工审查的注意力可以全部放在业务逻辑正确性和架构合理性上。这才是人最擅长、工具最不擅长的部分。第五步合并前最后一遍安全确认。如果这次改动涉及权限、输入处理、数据返回我会专门再过一遍安全清单。这一步不能省因为安全问题的代价比质量问题高一个数量级。3.4 一个真实的审查案例说个具体的。之前有个同事提交了一个“导出用户列表”的接口代码看起来很正常接收筛选条件、查数据库、生成 Excel、返回下载链接。Cursor 审查后报了三个问题[阻断] 筛选条件直接拼接到 SQL 里存在注入风险[重要] 没有检查当前用户是否有权导出用户数据[建议] 导出大量数据时没有分页可能 OOM第一个是安全问题第二个是安全问题第三个是质量问题。如果只跑 lint这三个一个都发现不了。如果只靠人眼第一个和第三个可能会被发现第二个大概率会被放过——因为代码“看起来”没问题它确实能正常工作只是任何人都能调用。这就是为什么我说质量和安全要分开查。它们的检查视角不同漏掉任何一个都会出问题。4. 质量审查的实操清单和避坑经验4.1 命名最容易被低估的审查项命名问题看起来是小事但它是代码可维护性的第一道防线。一个误导性的命名比没有命名还糟糕。我审查命名时主要看这几点是否表意data、info、temp、flag这类命名除非上下文极其明确否则一律要求改。userList比data好activeUserList比userList好。是否误导getUserInfo如果内部有写操作就是误导。isValid如果返回的是字符串而不是布尔值就是误导。是否一致同一个概念在不同地方用不同的词比如一会儿user一会儿account一会儿member这是团队协作的隐形税。是否过长或过短getUserByIdAndStatusAndCreateTimeRange这种命名说明函数职责太多应该拆。f这种命名说明作者不想让别人看懂。我的经验是命名问题在审查时提出来作者通常会改因为改起来成本低。但如果不在审查时提合并之后就没人会改了它会一直在那里恶心后来的人。4.2 边界条件80% 的线上问题出在这里边界条件是质量审查的重中之重。我见过太多“正常流程没问题边界情况炸了”的案例。审查边界条件时我会按这个清单过一遍边界类型检查点常见问题空值null、undefined、空字符串直接调用方法导致空指针空集合空数组、空 Map取第一个元素时越界极值最大值、最小值、负数、零除法除零、数组越界并发同时读写同一资源竞态条件、死锁超时外部调用超时没有超时设置导致线程挂死部分失败批量操作中部分失败没有回滚导致数据不一致这里有个实操技巧审查时不要只看代码要看代码对应的业务场景。比如一个“批量导入用户”的接口你要问的是“如果文件里有 10000 行第 5000 行格式错了前面 4999 行怎么办”。这个问题光看代码是看不出来的必须结合业务逻辑判断。4.3 异常处理最容易写出“看起来没问题”的代码异常处理是质量审查里最微妙的部分。因为异常处理的代码“看起来”都很正常但实际行为可能完全不是预期的。我审查异常处理时重点看这几个反模式吞异常catch(Exception e) {}或者catch(Exception e) { log.error(e); }然后继续执行。前者是完全无视后者是记了日志但没处理。这两种都会导致“出了问题但没人知道”。异常转换丢失信息把底层异常包装成业务异常时没有保留原始异常。排查问题时只能看到“操作失败”看不到“为什么失败”。异常粒度过粗一个 try-catch 包了 50 行代码出了异常根本不知道是哪一行。应该缩小 try 的范围只包可能出异常的部分。用异常控制流程用抛异常来实现正常的业务分支比如“查不到就抛异常”。这会导致性能问题和逻辑混乱。我的建议是审查异常处理时问作者一个问题“如果这里出异常了你怎么知道知道了之后怎么处理”如果作者答不上来这段异常处理就是有问题的。4.4 性能隐患审查时最容易放过的地方性能问题在审查时特别容易被放过因为“代码能跑”而且在小数据量下确实没问题。但上线后数据量一上来问题就暴露了。我审查性能时主要看这几个信号循环内有 IO循环里查数据库、调接口、读文件。这是最经典的性能杀手。应该改成批量查询。N1 查询查出一个列表然后遍历列表逐个查详情。应该用 join 或者批量查询。无限制的查询select * from table没有 limit数据量大了直接 OOM。频繁创建大对象在循环里创建大数组、大 MapGC 压力会很大。同步阻塞在请求线程里做耗时操作比如发邮件、生成报表。应该改成异步。这里有个经验审查性能问题时不要只看代码要问“这个接口的预期 QPS 是多少数据量级是多少”。一个每天调用 10 次的内部接口和一個每秒调用 1000 次的核心接口性能要求完全不同。5. 安全审查的实操清单和避坑经验5.1 输入验证假设所有输入都是恶意的安全审查的第一原则所有外部输入都是不可信的。外部输入包括但不限于URL 参数和路径参数请求体Header包括 Cookie、User-Agent、Referer文件上传的内容和文件名第三方回调的数据数据库里读出来的数据可能被之前的安全问题污染了审查输入验证时我主要看这几点是否校验了类型字符串长度、数字范围、枚举值是否在允许范围内。是否校验了格式邮箱、手机号、URL 是否符合预期格式。是否做了白名单对于枚举类参数是用白名单只允许特定值还是黑名单禁止特定值。白名单更安全。是否在正确的层校验校验应该在进入业务逻辑之前完成而不是在业务逻辑中间。这里有个常见的坑只在 Controller 层校验Service 层假设输入是合法的。如果 Service 被其他地方调用比如定时任务、消息消费校验就被绕过了。我的做法是关键校验放在 Service 层入口Controller 层的校验只是快速失败。5.2 权限控制认证和授权是两码事这是安全审查里最容易出问题的地方。很多开发者把“登录了”当成“有权操作”这是完全错误的。认证Authentication解决的是“你是谁”授权Authorization解决的是“你能做什么”。一个用户登录了不代表他有权删除任何人的数据。审查权限时我按这个清单过每个接口是否都检查了认证有没有漏掉的接口特别是内部接口、调试接口、健康检查接口。每个操作是否都检查了授权不只是“是否登录”而是“当前用户是否有权操作这个资源”。授权检查是否在正确的位置应该在业务逻辑之前而不是在返回数据之前。是否存在越权可能水平越权操作别人的资源和垂直越权低权限用户执行高权限操作。批量操作是否逐个检查批量删除时是否检查了每一个 ID 的权限还是只检查了第一个。我踩过的一个坑是一个“更新用户信息”的接口检查了“当前用户是否登录”但没检查“当前用户是否在更新自己的信息”。结果任何人登录后都能改别人的信息。这个 bug 在质量审查里完全看不出来因为代码逻辑是“正确”的。5.3 数据暴露返回给前端的数据要过滤数据暴露问题在审查时特别容易被放过因为代码“工作正常”前端也能正常显示。但返回了不该返回的字段就是安全问题。审查数据暴露时我主要看返回的实体是否包含了敏感字段密码哈希、盐值、内部 ID、手机号、身份证号、地址。错误信息是否暴露了内部结构堆栈信息、SQL 语句、文件路径、内部 IP。日志是否打印了敏感数据完整的请求体、响应体、用户凭证。接口文档是否暴露了内部接口Swagger 文档在生产环境是否关闭。我的做法是对于返回给前端的实体专门定义一个 VOView Object只包含需要返回的字段。不要直接把数据库实体返回出去因为数据库实体里可能有后来加的敏感字段而返回逻辑不会自动更新。5.4 注入类问题现代框架也救不了字符串拼接注入类问题的本质是“用户输入被当成了代码执行”。现代框架在大部分场景已经帮你处理了但一旦你用了字符串拼接框架的保护就失效了。审查注入问题时我重点看SQL 拼接有没有用字符串拼接构造 SQL包括where条件、order by字段、表名。命令拼接有没有用字符串拼接构造系统命令。模板拼接有没有用字符串拼接构造模板。XSS前端渲染时有没有对用户输入做转义。这里有个容易忽略的点order by和表名不能用参数化查询。参数化查询只能用于值不能用于字段名和表名。所以如果order by的字段来自用户输入必须用白名单校验。5.5 依赖安全人脑记不住必须靠工具依赖安全是唯一一个必须靠工具的领域。人脑不可能记住几万个开源库的版本和已知问题。我的做法是CI 里挂依赖扫描工具每次提交都跑定期比如每周跑一次全量扫描因为新的问题会不断被发现对于扫描出来的问题按严重程度处理高危立即修中危排期修低危评估后决定这里有个经验不要盲目升级依赖。升级依赖可能引入新的问题也可能导致不兼容。我的做法是对于高危问题优先考虑是否有 workaround如果没有再升级。升级时先在小范围测试确认没问题再全量。6. 把两条线串起来一个不折磨人的工作流6.1 提交前的自查清单我在提交代码前会花 5 分钟过一遍这个清单。这个清单是给作者自己用的不是给审查者用的。质量自查命名是否表意有没有data、temp这类命名边界条件是否处理空值、空集合、极值异常处理是否合理有没有吞异常有没有明显的性能隐患循环内 IO、N1 查询日志是否合理能不能帮助排查问题安全自查所有外部输入是否都校验了每个操作是否都检查了权限返回数据是否包含敏感字段有没有字符串拼接构造 SQL/命令/模板敏感信息是否硬编码错误信息是否泄露内部结构这个清单看起来长但熟练之后 5 分钟就能过一遍。关键是养成习惯就像出门前检查有没有带钥匙一样。6.2 CI 里应该挂什么工具CI 是兜底不是主力。主力是本地自查和人工审查。但 CI 必须要有因为人总会漏。我建议 CI 里至少挂这几类工具工具类型作用建议Lint代码风格、明显错误必须阻断合并单元测试逻辑正确性必须覆盖率设阈值依赖扫描第三方库问题必须高危阻断静态分析潜在 bug、安全模式建议重要问题阻断密钥扫描硬编码密钥必须阻断合并这里有个经验CI 的阻断规则要明确不要什么都阻断。如果 CI 太严格大家会想办法绕过反而更危险。我的做法是只阻断“必须修”的问题其他问题以警告形式输出人工判断。6.3 人工审查应该聚焦什么到了人工审查这一步低级问题已经被工具过滤掉了人的注意力应该放在工具不擅长的地方业务逻辑正确性代码是否真的实现了需求有没有理解偏差。架构合理性这个改动是否在正确的位置有没有破坏现有的架构。边界场景结合业务知识判断有没有工具发现不了的边界问题。可维护性三个月后别人能不能看懂这段代码。安全决策权限设计是否合理数据暴露是否可接受。我的经验是人工审查的时间应该花在“判断”上而不是“找问题”上。找问题交给工具人只做判断。6.4 一个完整的审查流程示例假设有一个“用户修改密码”的接口要提交完整流程是这样的本地自查作者过一遍清单发现异常处理里吞了异常修掉。Cursor 审查选中代码按项目规则审查。Cursor 报了三个问题密码强度没有校验、旧密码没有验证、错误信息暴露了“密码错误”还是“用户不存在”。作者修掉前两个第三个判断为可接受因为这是内部系统。CIlint 通过、单元测试通过、依赖扫描通过。人工审查审查者看业务逻辑发现“修改密码后没有使旧会话失效”这是一个安全问题提出来。作者修复。合并前安全确认专门过一遍安全清单确认权限、输入、数据暴露都没问题。这个流程看起来步骤多但实际跑下来本地自查 5 分钟Cursor 审查 2 分钟CI 自动跑人工审查 10 分钟安全确认 3 分钟。总共 20 分钟左右比出了问题再排查的成本低得多。7. 常见问题与排查技巧实录7.1 Cursor 审查结果太多怎么办这是最常见的问题。Cursor 一次性报 20 个问题看着就头大最后干脆不看了。我的做法是分级处理先看 [阻断] 级别的这些必须修[重要] 级别的快速扫一遍判断是否真的重要[建议] 级别的直接忽略或者记下来以后再说另外调整.cursorrules里的规则。如果某个规则总是报很多不重要的问题就把它从规则里去掉。规则是为了帮你不是为了折磨你。7.2 团队不配合怎么办这是管理问题不是技术问题。我的经验是不要一上来就要求所有人按你的流程来。先自己用用出效果比如“我这个月提交的代码零回滚”然后在团队里分享。别人看到有效果自然会问你怎么做的。另外把流程做得足够简单。如果流程需要 30 分钟没人会坚持。如果流程只需要 5 分钟大家就愿意做。我的清单之所以设计成 5 分钟能过一遍就是为了降低执行成本。7.3 工具报的问题不准确怎么办工具报误报是正常的关键是不要因为误报就放弃工具。我的做法是对于反复误报的规则调整配置或者关掉对于偶尔误报的手动忽略对于不确定的人工判断这里有个经验工具的误报率超过 30%就应该调整规则了。如果误报太多大家会养成“看到工具报错就忽略”的习惯那工具就白挂了。7.4 安全审查发现的问题业务方不接受怎么办这是最棘手的情况。安全审查发现了一个问题但业务方说“这个不影响先上线”。我的做法是把风险量化这个问题被利用的概率有多大被利用后的影响是什么数据泄露、服务不可用、资金损失修复的成本是多少然后把这个分析给业务方看让他们做决策。决策权在业务方但风险要讲清楚。如果业务方决定接受风险那就记录下来以后出了问题有据可查。7.5 常见问题速查表问题排查思路解决方法Cursor 审查结果太多检查规则是否太严格调整.cursorrules分级处理团队不配合流程太复杂简化流程先自己用出效果工具误报多规则不适配项目调整规则误报率控制在 30% 以下安全问题和业务冲突风险没有量化量化风险让业务方决策审查时间太长没有分级阻断项必须修其他分级处理漏掉安全问题没有专门的安全审查安全清单单独过一遍8. 我个人的一些经验和建议8.1 审查不是找茬是共同提高我早期做审查的时候总是不自觉地用“挑毛病”的心态结果作者很抵触审查效果也不好。后来我调整了心态审查的目的是让代码更好不是证明我比你强。具体做法是提问题时说清楚“为什么”而不是只说“这里不对”。比如不说“这里没有校验权限”而是说“这个接口如果没有校验权限任何人登录后都能调用可能会被刷数据”。作者理解了风险自然会改。8.2 把审查清单变成肌肉记忆清单刚开始用的时候需要对着一条条过。用多了之后就变成肌肉记忆了。写代码的时候脑子里会自动跳出“这里边界条件处理了吗”“这里权限检查了吗”。我的经验是坚持用一个月就能形成习惯。前两周可能觉得麻烦第三周开始就顺了第四周之后不用清单也能想到大部分检查点。8.3 安全审查要趁早不要等到上线前安全问题越早发现修复成本越低。上线前发现一个权限问题可能要改接口、改前端、改测试成本很高。写代码时发现改一行代码就搞定了。所以我的做法是安全审查不是上线前的最后一步而是写代码时的持续动作。每写一个涉及权限、输入、数据返回的接口就顺手过一遍安全清单。8.4 工具是辅助判断在人最后再强调一遍工具是辅助判断在人。Cursor 能帮你发现问题但判断问题是否重要、是否必须修、怎么修还是得靠人。我见过有人完全依赖工具工具没报问题就认为没问题。这是很危险的。工具只能发现它被训练来发现的问题新的问题模式它发现不了。人的判断力才是最后一道防线。8.5 一个实用的小技巧如果你觉得每次审查都要过一遍清单太麻烦可以试试把清单贴在显示器旁边。物理上的提醒比脑子里的提醒有效得多。我刚开始的时候就是这么做的过了一个月才撤掉。另外把审查清单做成模板每次提交代码时在提交信息里附上清单的勾选结果。这样审查者能看到你已经自查过了审查时可以更聚焦。这个内容后续还可以这样扩展针对不同技术栈比如 Java、Go、前端做专门的审查清单或者针对不同业务场景比如支付、用户数据、内部系统做差异化的安全审查规则。核心思路是一样的质量和安全分开查工具和人分工清单和习惯结合。