---
name: frontend-code-review
description: 当用户需要对前端代码进行全面审查时使用此技能，包括 React、Vue、Angular 或原生 JavaScript/TypeScript 项目。适用于代码审查、Pull Request 评审、性能审计、安全检查等场景。
license: MIT
author: Bamzc
---

# 前端代码审查技能

## 技能用途

对前端代码进行系统化审查，涵盖代码质量、性能、安全、可访问性等多个维度。支持 React、Vue、Angular 和原生 JavaScript/TypeScript 项目。

## 审查工作流程

### 第一步：识别项目类型和范围

执行以下识别工作：

1. 确定框架类型（React、Vue、Angular、原生 JS/TS）
2. 评估代码规模（单组件、功能模块、完整应用）
3. 检查明显的语法错误、格式问题或导入错误

### 第二步：多维度系统审查

按照以下维度逐一审查代码：

**代码质量**
- 检查命名是否语义化且一致
- 识别代码重复和可重构的机会
- 确认函数/组件是否遵循单一职责原则
- 评估文件组织和模块结构的合理性

**功能实现**
- 验证业务逻辑正确性
- 检查边界情况和错误处理
- 审查异步操作处理（Promise、async/await）
- 确认加载状态和错误状态的用户反馈机制

**性能优化**
- 识别不必要的组件重渲染
- 检查列表渲染的 key 使用是否正确
- 评估对打包体积的影响
- 审查图片优化策略（格式、懒加载、响应式）
- 检查网络请求效率（缓存、去重、防抖节流）

**安全性**
- 检测 XSS 漏洞（未转义输入、dangerouslySetInnerHTML 使用）
- 验证输入验证和数据清洗
- 审查敏感数据处理（localStorage、API 令牌）
- 检查 CSRF 保护机制
- 评估第三方依赖的安全风险

**可访问性 (a11y)**
- 检查语义化 HTML 的使用
- 验证 ARIA 属性的正确性
- 测试键盘导航支持
- 检查颜色对比度
- 确认图片 alt 文本和表单 label

**框架特定模式**

*React:*
- 检查 Hook 使用（useEffect 依赖数组、自定义 Hook 设计）
- 识别闭包陷阱
- 验证受控与非受控组件的正确使用
- 评估 Context 使用的适当性
- 审查状态管理设计（本地 vs 全局）

*Vue 3 Composition API:*
- 检查 ref/reactive 使用是否合理
- 验证 computed/watch 使用是否正确
- 评估组件通信方式（props/emit/provide/inject）
- 检查生命周期钩子使用
- 审查组合函数（Composables）抽取是否合理

*TypeScript:*
- 验证类型定义的准确性和完整性
- 识别 `any` 类型的过度使用
- 检查泛型使用的合理性
- 评估接口/类型的可复用性

**浏览器兼容性**
- 检查目标浏览器支持的特性
- 验证 CSS 供应商前缀
- 评估 polyfill 必要性
- 审查响应式设计实现

### 第三步：生成结构化报告

使用以下格式输出审查结果：

```markdown
## 🔍 代码审查报告

### 文件：[文件路径]

#### ✅ 优秀实践

列出代码中做得好的地方：
- 优雅的解决方案
- 良好的设计模式
- 清晰的代码结构
- 周到的抽象设计

#### ⚠️ 需要改进的问题

| 类别 | 问题描述 | 改进建议 | 严重程度 |
|------|---------|---------|----------|
| 性能 | [具体问题] | [改进方案] | 🔴 高 / 🟡 中 / 🟢 低 |

#### 📊 代码评分

> ### 🎯 综合评分：X.X / 10
> **等级：[🏆S/🥇A/🥈B/🥉C/⚠️D/❌F]（[等级描述]）** | **状态：[✅可直接上线/⚠️需修复后上线/❌需要重构]**

| 维度 | 得分 | 评价 |
|------|------|------|
| 代码质量 | X/10 | [简要评价] |
| 功能实现 | X/10 | [简要评价] |
| 性能优化 | X/10 | [简要评价] |
| 安全性 | X/10 | [简要评价] |
| 可访问性 | X/10 | [简要评价] |

**主要扣分项**：[具体说明扣分原因]

#### 📝 改进建议

- **优先修复**：[关键问题列表]
- **后续优化**：[可选改进方向]
```

**评分等级标准：**

| 等级 | 分数范围 | 状态 | 含义 |
|------|----------|------|------|
| 🏆 S | 9.5-10 | ✅ 可直接上线 | 卓越，可作为最佳实践范本 |
| 🥇 A | 8.5-9.4 | ✅ 可直接上线 | 优秀，生产级代码 |
| 🥈 B | 7.0-8.4 | ⚠️ 修复后上线 | 良好，少量问题需修复 |
| 🥉 C | 5.5-6.9 | ⚠️ 修复后上线 | 一般，需要认真修复优化 |
| ⚠️ D | 4.0-5.4 | ❌ 需要重构 | 较差，建议较大范围重构 |
| ❌ F | < 4.0 | ❌ 需要重构 | 不合格，建议重写 |

**严重程度定义：**
- 🔴 高：安全漏洞、严重 bug、崩溃风险 → 必须修复
- 🟡 中：性能问题、代码规范、可维护性 → 建议修复
- 🟢 低：代码风格、优化建议 → 可选改进

### 第四步：积极认可优秀实践

在报告中突出强调：
- 优雅的解决方案和设计模式
- 良好的编码实践
- 结构清晰的代码组织
- 周到的抽象和封装

## 审查深度调整策略

根据以下因素调整审查深度和重点：

- **代码规模**：小改动快速审查核心问题，大功能进行全面深度审查
- **代码上下文**：生产环境代码采用严格标准，原型代码可适度宽容
- **时间限制**：时间紧张时按优先级审查（安全 > 性能 > 规范 > 风格）

## 补充资源

详细的审查检查清单和工具推荐请参考 `references/checklist.md`。