代码审查 共 45 条
通用代码审查
你是一位资深代码审查专家。请审查下面的代码：{粘贴代码}。按以下维度输出：1）正确性（bug与边界条件，标注严重级别P0-P2）；2）可读性（命名/结构/注释）；3）性能隐患；4）安全问题；5）改进后的代码示例。只报告确定的问题，不确定的标注「待确认」并说明验证方法。
安全审计专项
请以安全工程师视角审计下面的代码：{粘贴代码}。重点检查：1）注入类漏洞（SQL/命令/XSS）及具体触发路径；2）认证与授权缺陷；3）敏感信息泄露（日志/异常/硬编码密钥）；4）不安全的依赖或API用法；5）每个漏洞给出：风险等级、利用场景示意、修复代码。
性能审查
请从性能角度审查代码：{粘贴代码}。分析：1）算法复杂度与数据规模的增长关系；2）N+1查询/循环内IO等反模式；3）内存问题（大对象/泄漏风险）；4）缓存机会识别；5）按「影响×成本」矩阵排序的优化建议，并标注哪些建议需要压测验证。
重构建议生成
下面的代码能工作但很乱：{粘贴代码}。请给出重构方案：1）识别代码坏味道（对照Fowler的坏味道清单）；2）目标设计（类/函数的职责划分，可用简单的结构图描述）；3）分步重构路径（每步可独立验证，遵循小步快跑）；4）哪些行为必须保持不变（安全网：先补测试的清单）。
API 设计评审
请评审下面的API设计：{接口定义}。检查：1）RESTful规范性（资源命名/HTTP方法/状态码）；2）参数与响应结构的一致性；3）错误响应的标准化；4）分页/过滤/排序的设计；5）向后兼容性风险。给出改进后的接口定义（OpenAPI片段）。
数据库设计评审
请评审下面的数据库设计：{表结构DDL}。检查：1）范式与反范式的取舍；2）索引设计（查询模式匹配、冗余索引）；3）字段类型选择（精度/长度/枚举vs字典表）；4）潜在的扩展性问题；5）给出优化后的DDL与迁移注意事项（线上表变更的风险）。
测试用例生成
请为下面的函数/接口生成测试用例：{粘贴代码}。输出：1）正常路径用例；2）边界条件（空值/极值/零/负数/超长输入）；3）异常路径（非法输入/依赖失败）；4）用表格呈现：用例名/输入/期望输出/覆盖的逻辑；5）指出哪些逻辑难以测试并给出可测性重构建议。
PR 描述生成
请根据下面的代码变更生成PR描述：{diff或变更说明}。结构：1）一句话说明改了什么、为什么；2）变更点列表（按模块分组）；3）风险与影响范围（哪些功能可能受影响、需要的发布注意事项）；4）测试情况（已验证的场景清单）；5）reviewer需要重点关注的位置。
遗留代码理解助手
我接手了一段没有文档的历史代码：{粘贴代码}。请帮我快速理解：1）这段代码的职责（一句话）；2）核心执行流程（按步骤）；3）外部依赖与副作用（数据库/接口/文件）；4）疑点清单（看起来奇怪或可能有坑的地方）；5）如果要安全修改，建议先补哪些测试。
日志规范审查
请审查下面的代码日志实践：{粘贴代码}。检查：1）日志级别使用是否恰当（info/warn/error的语义）；2）关键路径是否有足够日志（可排障性）；3）敏感信息是否被记录（脱敏检查）；4）日志格式的一致性（可检索性：traceId/关键字段）；5）给出规范化后的日志代码示例。
异常处理审查
请审查代码的异常处理：{粘贴代码}。检查：1）吞异常问题（捕获后不处理/只打日志不处理）；2）异常粒度（过度笼统的catch Exception）；3）异常信息质量（是否包含上下文）；4）资源泄漏风险（未关闭的资源）；5）给出异常处理的设计原则和修改示例。
并发问题审查
请审查代码的并发安全性：{粘贴代码}。检查：1）共享可变状态（谁在什么时机读写）；2）竞态条件的具体场景（时序图描述）；3）锁的使用（粒度/死锁风险/替代方案）；4）线程安全集合的正确使用；5）给出修复方案，并说明如何用测试复现该并发问题。
代码风格统一检查
请按照以下规范检查代码并给出修正：{粘贴团队的规范要点}。代码：{粘贴代码}。输出：1）违规点清单（行号/规则/现状）；2）自动修复后的代码；3）无法自动修复需要人工判断的点；4）建议加入lint规则避免同类问题的配置片段。
依赖安全审查
请审查项目的依赖声明：{粘贴依赖清单}。分析：1）已知漏洞风险高的依赖（说明理由与查证方法）；2）重复功能的依赖（可移除项）；3）过时或停止维护的依赖及替代品；4）升级优先级（安全补丁>功能>大版本）；5）升级的风险评估与回归测试范围。
单测覆盖率分析
我的测试文件如下：{粘贴测试代码}，被测代码：{粘贴源码}。请分析：1）未覆盖的分支与边界（逐个列出）；2）现有测试的问题（断言过弱/耦合实现细节）；3）优先补充的5个测试用例（按业务风险排序）；4）测试代码本身的改进建议（可读性/复用）。
代码注释审查
请审查代码的注释质量：{粘贴代码}。原则：注释解释「为什么」而非「是什么」。检查：1）无意义注释（复述代码的）删除清单；2）缺失注释的关键位置（魔法数字/绕行方案/临时处理）；3）过时注释（与代码不符的）；4）TODO/FIXME的规范处理；5）给出修改示例。
错误码与消息设计
请帮我设计一套API错误码体系：{业务场景描述}。输出：1）错误码分段规则（系统级/业务级/第三方）；2）错误响应的标准结构（code/message/detail/traceId）；3）面向用户的错误消息原则（可行动、不暴露内部细节，给出10个示例）；4）错误码的注册与管理流程建议。
配置管理审查
请审查代码中的配置管理实践：{粘贴代码}。检查：1）硬编码配置（应外部化的项）；2）配置的分级（默认值/环境覆盖/运行时覆盖）；3）敏感配置的处理（密钥不入库不入日志）；4）配置变更的生效机制（重启/热更新）；5）给出配置结构的重构示例。
Code Review 沟通话术
我是reviewer，发现同事的代码有问题：{描述问题}。请帮我起草评审意见：1）区分「必须修改」与「建议考虑」的措辞（前者直接，后者留余地）；2）对事不对人的表达模板（聚焦代码行为而非作者）；3）对每个问题的提问式表达（引导思考而非命令）；4）如果是反复出现的同类问题，如何提出流程改进建议。
技术债盘点
请帮我盘点并汇报技术债：{描述系统现状与痛点}。输出：1）技术债清单（分类：代码/架构/依赖/文档/流程）；2）每项的利息评估（不还债的持续成本）与偿还成本；3）优先级矩阵（利息×偿还成本四象限）；4）向管理层汇报的一页纸摘要（用业务语言，附技术细节附录）。
安全编码检查清单
请为{语言/框架}项目生成一份上线前安全检查清单：覆盖输入验证、认证会话、访问控制、数据加密、日志脱敏、依赖漏洞、错误处理、文件上传、CSRF/SSRF、第三方集成。每项给出：检查方法（如何自查）、通过标准、常见错误示例。按「漏掉会出大事→漏掉会出小事」排序。
Git 提交规范审查
请审查下面的提交历史：{粘贴git log}。检查：1）提交粒度（是否一个提交混多个不相关变更）；2）提交信息规范（type(scope): subject格式）；3）可疑提交（fix typo类的连续提交说明工作流问题）；4）给出改进建议（commit规范/分支策略/何时squash）；5）输出规范化的提交信息改写示例。
前端代码审查
请从前端视角审查代码：{粘贴代码}。检查：1）XSS风险（不安全的DOM操作/v-html使用）；2）状态管理（状态冗余/提升不当）；3）渲染性能（不必要的重渲染/大列表处理）；4）内存泄漏（事件监听/定时器清理）；5）可访问性（语义化/键盘操作）。输出按严重度排序的问题清单与修复代码。
SQL 审查
请审查下面的SQL/ORM查询：{粘贴SQL}。检查：1）索引利用（EXPLAIN视角分析，指出全表扫描点）；2）隐式转换与函数导致的索引失效；3）大事务与锁风险；4）注入风险（拼接处）；5）给出优化后的写法与需要的索引DDL，并说明验证方法。
代码评审 checklist 生成
请为{团队技术栈}生成一份Code Review checklist：分为「必须否决」（会出事故的：数据丢失/安全/兼容破坏）、「应该修改」（质量债）、「建议讨论」（设计取舍）三档。每条给出：检查点、判定标准、典型反例。控制在一页内，要求reviewer能在10分钟内完成基础审查。
设计模式应用建议
这段代码有明显的重复与耦合问题：{粘贴代码}。请判断：1）哪些场景适合引入设计模式（策略/工厂/观察者/模板方法等），并说明为什么该模式匹配；2）哪些地方刻意不引入（过度设计的风险）；3）给出应用模式后的代码结构示例；4）重构的迁移步骤（保证每步可运行）。
回归影响分析
我要修改这个函数：{粘贴代码，说明修改意图}。请分析影响面：1）所有调用方（基于代码结构推断）及各自的行为假设；2）可能被破坏的隐式契约（返回值约定/异常语义/性能特征）；3）需要的回归测试范围（按风险排序）；4）兼容性策略（参数默认值/旧路径保留的取舍）；5）推荐的灰度或分步发布方案。
开源引入评审
团队想引入开源库「{库名，用途}」。请给出引入评审框架：1）健康度检查维度（维护活跃度/issue响应/文档质量/社区规模的具体指标）；2）许可证合规检查点；3）替换成本评估（封装层设计的必要性）；4）安全供应链风险（依赖树、更新渠道）；5）引入决策的一页纸模板。
代码评审优先级排序
我作为reviewer只有20分钟，面对这个PR：{diff规模与变更点摘要}。请帮我规划审查策略：1）先看什么（变更的意图与整体设计，通过PR描述+核心文件）；2）重点审查区（风险最高的20%代码：并发/边界/安全敏感处）；3）可以放过的部分（格式化/重复模式）；4）20分钟内来不及看的部分如何处理（标注与跟进机制）。
复盘报告生成
线上出了这个故障：{故障描述：现象/影响/根因/处理过程}。请生成一份无指责的复盘报告：1）时间线（发现→响应→定位→恢复，精确到动作）；2）根因分析（5 Whys，追到流程层面而非只停在技术原因）；3）影响量化；4）改进项（每项：负责人角色/截止时间/验证方式，区分短期修复与长期机制）；5）值得表扬的应对动作。
安全审计
以安全工程师视角审计：「{粘贴代码}」。检查注入漏洞（SQL/命令/XSS）及触发路径；认证授权缺陷；敏感信息泄露（日志/异常/硬编码密钥）；不安全API用法。每个问题给出：风险等级、利用场景示意、修复代码。
重构方案
这段代码能用但很乱：「{粘贴代码}」。识别代码坏味道（对照Fowler清单）；目标设计（职责划分，文字结构图）；分步重构路径（每步可独立验证）；必须保持不变的行为清单与安全网（先补测试的清单）。
遗留代码理解
我接手了无文档的历史代码：「{粘贴代码}」。请输出：代码职责（一句话）；核心执行流程（分步）；外部依赖与副作用（DB/接口/文件）；疑点清单（奇怪或有坑的地方）；安全修改前建议补的测试。
并发安全审查
审查并发安全：「{粘贴代码}」。共享可变状态识别；竞态条件的时序描述；锁粒度与死锁风险；线程安全集合的正确用法；修复方案，以及如何编写一个能复现该并发问题的测试。
依赖引入评审
团队想引入「{库名，用途}」。评审框架：健康度检查（维护活跃度/issue响应/文档/社区的具体指标）；许可证合规；封装层设计（降低替换成本）；供应链安全（依赖树/更新渠道）；一页纸引入决策模板（结论先行）。
Review 沟通话术
我是reviewer，同事代码有问题：「{描述问题}」。起草评审意见：必须修改vs建议考虑的措辞区分；对事不对人的表达（聚焦代码行为）；提问式表达（引导思考而非命令）；同类问题反复出现时的流程改进建议措辞。
设计模式应用判断
这段代码有重复与耦合：「{粘贴代码}」。判断哪些场景适合引入设计模式（策略/工厂/观察者/模板方法）及匹配理由；哪些地方刻意不引入（过度设计风险）；应用模式后的代码结构示例；保证每步可运行的迁移步骤。
Code Review 清单
为{技术栈}生成Review checklist：必须否决（会出事故：数据丢失/安全/兼容破坏）；应该修改（质量债）；建议讨论（设计取舍）。每条含：检查点、判定标准、典型反例。控制在一页，10分钟可完成基础审查。
故障复盘报告
线上故障：「{现象/影响/根因/处理过程}」。生成无指责复盘：时间线（发现→响应→定位→恢复的精确动作）；5 Whys根因（追到流程层面）；影响量化；改进项（负责人角色/截止/验证方式，区分短期修复与长期机制）；应对得当值得表扬的动作。
错误码体系设计
设计API错误码体系：「{业务场景}」。错误码分段规则（系统/业务/第三方）；标准响应结构（code/message/detail/traceId）；面向用户的消息原则（可行动、不暴露内部，10个示例）；错误码注册与管理流程。
上线前安全清单
为{语言/框架}生成上线安全检查清单：输入验证/认证会话/访问控制/加密/日志脱敏/依赖漏洞/错误处理/文件上传/CSRF/SSRF/第三方集成。每项：自查方法、通过标准、典型错误示例。按「漏掉会出大事→小事」排序。
20分钟 Review 策略
我只有20分钟审这个PR：「{diff规模与摘要}」。规划策略：先看意图与整体设计（PR描述+核心文件）；重点审查风险最高的20%（并发/边界/安全敏感）；可放过的部分（格式化）；来不及看的处理（标注跟进机制）；输出一份时间分配方案。
重构与测试保护网
重构前的安全网设计：目标代码「{粘贴}」。分析：现有行为清单（显式功能+隐式契约）；需要先补的特征测试（characterization tests）清单；重构步骤中每步的验证方法；哪些重构适合工具自动化（IDE重构）哪些必须手动。
Code Owner 视角审查
以模块负责人视角审查新人提交：「{diff}」。重点：是否理解了该模块的历史约束（为什么当初这么设计）；是否引入了不必要的抽象或依赖；测试是否覆盖了关键路径；命名是否符合领域语言；给出反馈结构（先肯定→再问题→后建议）。
性能回归定位
上线后性能劣化：「{现象：接口变慢/内存上涨的监控数据}」。定位框架：变更范围回溯（最近发版diff）；分层排查顺序（应用层/DB层/依赖层/基础设施）；关键指标对比（发布前后）；常用定位工具链；临时缓解与根本修复的分离策略。