code-review

name	code-review
description	代码修改后的全局兼容审查与质量保障。Use when: 代码变更后需要全局兼容性检查、前后端适配验证、Bug 审查、代码质量把控。Covers: compatibility check, frontend-backend sync, bug review, code quality assurance, regression prevention.

代码修改全局审查

每次代码修改后，执行系统化的全局兼容性检查、前后端适配验证与 Bug 审查，确保代码高质量且无遗漏。

触发时机

• 任何功能新增、修改或删除
• 接口变更（请求/响应结构、参数、状态码）
• 数据模型或数据库结构变更
• 依赖升级或配置修改
• 样式、布局或组件结构调整

审查流程

第一步：变更影响分析

1. 明确本次修改涉及的所有文件
2. 梳理修改点的上下游依赖关系（谁调用了它、它调用了谁）
3. 列出可能受影响的模块和功能

第二步：前后端接口适配

1. 若后端接口有变更（路径、参数、响应结构、状态码），前端调用处必须同步更新
2. 若前端请求格式有变更，后端接收与校验逻辑必须同步适配
3. 检查接口的错误处理是否前后端一致（错误码、提示信息、异常兜底）
4. 验证数据类型在前后端传递过程中是否保持一致（避免类型隐式转换问题）

第三步：全局兼容性检查

1. 类型安全：检查修改是否引入类型不匹配、空值未处理、越界访问
2. 引用完整性：所有引用该模块/函数/变量的地方是否已同步更新
3. 配置一致性：环境变量、路由配置、权限配置等是否同步修改
4. 数据流完整性：数据从输入到存储到展示的完整链路是否通顺
5. 边界条件：空数组、空对象、undefined、null、超长字符串、并发场景

第四步：Bug 排查清单

针对每个修改点逐项检查：

• 是否存在未处理的异常（try-catch 缺失、Promise 未 catch）
• 是否有逻辑分支遗漏（if 无 else、switch 无 default）
• 是否有死循环或无限递归的可能
• 是否有资源泄漏（未关闭的连接、未清除的定时器、未销毁的监听器）
• 是否有竞态条件（异步操作顺序依赖、状态更新时序问题）
• 是否有安全漏洞（SQL 注入、XSS、未校验的用户输入、敏感信息泄露）
• 是否影响已有功能的正常运行（回归问题）

第五步：代码质量检查

• 命名是否语义清晰、风格统一
• 函数职责是否单一，是否过长需要拆分
• 是否有重复代码可以提取复用
• 关键逻辑是否有高质量中文注释
• 是否有硬编码的魔法数字或字符串需要提取为常量
• 性能是否合理（避免不必要的循环、重复计算、大量 DOM 操作）
• 异步操作是否正确使用 async/await，避免回调地狱
• 组件/模块的导入导出是否正确，有无循环依赖
• 数据库操作是否使用参数化查询，防止 SQL 注入
• 敏感信息（密钥、token、密码）是否未硬编码在代码中
• 前端是否对用户输入做了合法性校验与 XSS 转义
• 接口是否有适当的鉴权与权限校验
• 文件操作、网络请求是否有超时与重试机制

第六步：输出审查报告

完成审查后，输出如下格式的审查结论：

## 审查结论

**修改范围**：（涉及的文件与模块）
**前后端适配**：✅ 已同步 / ⚠️ 需补充（说明）
**兼容性**：✅ 无破坏性变更 / ⚠️ 存在风险（说明）
**Bug 风险**：✅ 未发现 / ⚠️ 发现问题（逐条列出）
**代码质量**：✅ 达标 / ⚠️ 建议优化（说明）
**需要额外修改的文件**：（列出需同步修改的文件及原因）

原则

• 宁可多查一遍，不漏一个问题
• 修改一处，全局验证，杜绝连锁 Bug
• 前后端视为一个整体，接口变更必须双向同步
• 审查发现的问题必须当场修复，不留待办