--- 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`。