320 lines
8.2 KiB
Markdown
320 lines
8.2 KiB
Markdown
## 错误修复
|
|
|
|
从错误信息中识别根本原因，预测解决时间，提出经过验证的解决方案。学习类似错误的模式，立即提供合适的处理方法。
|
|
|
|
### 使用方法
|
|
|
|
```bash
|
|
/fix-error [选项]
|
|
```
|
|
|
|
### 选项
|
|
|
|
- 无 : 标准错误分析
|
|
- `--deep` : 深度分析模式 (包括依赖关系·环境因素)
|
|
- `--preventive` : 重视预防措施的分析
|
|
- `--quick` : 仅提供立即可用的修复方案
|
|
|
|
### 基本示例
|
|
|
|
```bash
|
|
# 标准错误分析
|
|
npm run build 2>&1
|
|
/fix-error
|
|
"分析构建错误并提出修复方法"
|
|
|
|
# 深度分析模式
|
|
python app.py 2>&1
|
|
/fix-error --deep
|
|
"包括环境因素在内分析错误的根本原因"
|
|
|
|
# 即时修复重视
|
|
cargo test 2>&1
|
|
/fix-error --quick
|
|
"提供可立即应用的修复方法"
|
|
|
|
# 预防措施重视
|
|
./app 2>&1 | tail -50
|
|
/fix-error --preventive
|
|
"提出错误修复和未来的预防措施"
|
|
```
|
|
|
|
### 与 Claude 的协作
|
|
|
|
```bash
|
|
# 错误日志分析
|
|
cat error.log
|
|
/fix-error
|
|
"识别错误的根本原因，提出修复方法"
|
|
|
|
# 测试失败的解决
|
|
npm test 2>&1
|
|
/fix-error --quick
|
|
"分析失败的测试，提出可立即应用的修复方案"
|
|
|
|
# 堆栈跟踪的解析
|
|
python script.py 2>&1
|
|
/fix-error --deep
|
|
"从这个堆栈跟踪中定位问题，包括环境因素一起分析"
|
|
|
|
# 批量解决多个错误
|
|
grep -E "ERROR|WARN" app.log | tail -20
|
|
/fix-error
|
|
"按优先级分类这些错误和警告，分别提出解决方法"
|
|
```
|
|
|
|
### 错误解决时间预测
|
|
|
|
```text
|
|
🚀 即时修复 (5 分钟内)
|
|
├─ 拼写错误、import 遗忘
|
|
├─ 环境变量未设置
|
|
├─ 未定义变量引用
|
|
└─ 预测时间: 2-5 分钟
|
|
|
|
⚡ 快速修复 (30 分钟内)
|
|
├─ 依赖关系不一致
|
|
├─ 配置文件错误
|
|
├─ 类型不匹配
|
|
└─ 预测时间: 10-30 分钟
|
|
|
|
🔧 需要调查 (2 小时内)
|
|
├─ 复杂逻辑错误
|
|
├─ 异步处理竞争
|
|
├─ API 集成问题
|
|
└─ 预测时间: 30 分钟-2 小时
|
|
|
|
🔌 深层分析 (半天以上)
|
|
├─ 架构原因
|
|
├─ 多系统集成
|
|
├─ 性能降级
|
|
└─ 预测时间: 4 小时-数日
|
|
```
|
|
|
|
### 类似错误模式数据库
|
|
|
|
```text
|
|
高频错误及即时解决方案
|
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
|
|
📊 "Cannot read property 'X' of undefined/null" (频出度: 极高)
|
|
├─ 主要原因: 对象的 null 检查不足
|
|
├─ 解决时间: 5-10 分钟
|
|
└─ 处理方法: 可选链式调用 (?.) 或添加 null 检查
|
|
|
|
📊 "ECONNREFUSED" / "ENOTFOUND" (频出度: 高)
|
|
├─ 主要原因: 服务未启动或 URL 配置错误
|
|
├─ 解决时间: 5-15 分钟
|
|
└─ 处理方法: 确认服务启动、检查环境变量
|
|
|
|
📊 "Module not found" / "Cannot resolve" (频出度: 高)
|
|
├─ 主要原因: 包未安装、路径指定错误
|
|
├─ 解决时间: 2-5 分钟
|
|
└─ 处理方法: 执行 npm install、确认相对路径
|
|
|
|
📊 "Unexpected token" / "SyntaxError" (频出度: 中)
|
|
├─ 主要原因: 括号、引号不匹配、使用保留字
|
|
├─ 解决时间: 2-10 分钟
|
|
└─ 处理方法: 确认语法高亮、执行 Linter
|
|
|
|
📊 "CORS policy" / "Access-Control-Allow-Origin" (频出度: 中)
|
|
├─ 主要原因: 服务端 CORS 配置不足
|
|
├─ 解决时间: 15-30 分钟
|
|
└─ 处理方法: 服务端 CORS 配置、代理设置
|
|
|
|
📊 "Maximum call stack size exceeded" (频出度: 低)
|
|
├─ 主要原因: 无限循环、递归、循环引用
|
|
├─ 解决时间: 30 分钟-2 小时
|
|
└─ 处理方法: 确认递归的终止条件、解决循环引用
|
|
```
|
|
|
|
### 错误分析优先级矩阵
|
|
|
|
| 优先级 | 图标 | 影响范围 | 解决难度 | 处理期限 | 说明 |
|
|
| ----------------- | ----------- | -------- | -------- | ------------- | -------------------------- |
|
|
| **Critical** | 🔴 紧急处理 | 广 | 低 | 15 分钟内着手 | 系统全体停止、数据丢失风险 |
|
|
| **High Priority** | 🟠 早期处理 | 广 | 高 | 1 小时内着手 | 主要功能停止、多数用户影响 |
|
|
| **Medium** | 🟡 计划处理 | 狭 | 高 | 当日内处理 | 部分功能限制、有规避方案 |
|
|
| **Low** | 🟢 经过观察 | 狭 | 低 | 下次修改时 | 轻微不具、UX 影响小 |
|
|
|
|
### 分析流程
|
|
|
|
#### 阶段 1: 错误信息收集
|
|
|
|
```bash
|
|
🔴 必须执行:
|
|
- 完整获取错误信息
|
|
- 确认堆栈跟踪
|
|
- 确定发生条件 (可重现性)
|
|
|
|
🟡 尽早执行:
|
|
- 收集环境信息 (OS、版本、依赖)
|
|
- 最近的更改历史 (git log、最近提交)
|
|
- 确认相关日志
|
|
|
|
🟢 附加执行:
|
|
- 系统资源状况
|
|
- 网络状态
|
|
- 外部服务状态
|
|
```
|
|
|
|
#### 阶段 2: 根本原因分析
|
|
|
|
1. **整理表面症状**
|
|
- 错误信息的准确内容
|
|
- 发生时机和模式
|
|
- 确定影响范围
|
|
|
|
2. **识别深层原因**
|
|
- 应用 5 Whys 分析
|
|
- 追踪依赖关系
|
|
- 确认环境差异
|
|
|
|
3. **验证假设**
|
|
- 创建最小重现代码
|
|
- 执行隔离测试
|
|
- 缩小原因范围
|
|
|
|
#### 阶段 3: 实施解决方案
|
|
|
|
```bash
|
|
🔴 立即处理 (热修复):
|
|
- 抑制症状的最小修复
|
|
- 应用临时解决方案
|
|
- 准备紧急部署
|
|
|
|
🟡 根本解决:
|
|
- 针对原因的本质修复
|
|
- 添加测试用例
|
|
- 更新文档
|
|
|
|
🟢 实施预防措施:
|
|
- 加强错误处理
|
|
- 设置监控·告警
|
|
- 改进 CI/CD 管道
|
|
```
|
|
|
|
### 输出示例
|
|
|
|
```text
|
|
🚨 错误分析报告
|
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
|
|
📍 错误概要
|
|
├─ 类型: [编译/运行时/逻辑/环境]
|
|
├─ 紧急度: 🔴 高 / 🟡 中 / 🟢 低
|
|
├─ 影响范围: [功能名/组件]
|
|
├─ 重现性: [100% / 间歇性 / 特定条件]
|
|
└─ 预测解决时间: [2-5 分钟 / 30 分钟-2 小时 / 4 小时+]
|
|
|
|
🔍 根本原因
|
|
├─ 直接原因: [具体原因]
|
|
├─ 背景因素: [环境/设置/依赖关系]
|
|
├─ 触发器: [发生条件]
|
|
└─ 类似模式: [已知错误类型 / 首次发生]
|
|
|
|
💡 解决方案
|
|
🔴 即时处理 (预计: X 分钟):
|
|
1. [具体修复命令/代码]
|
|
2. [临时解决方案]
|
|
|
|
🟡 根本解决 (预计: Y 小时):
|
|
1. [本质修复方法]
|
|
2. [必要的重构]
|
|
|
|
🟢 预防措施:
|
|
1. [错误处理改进]
|
|
2. [测试添加]
|
|
3. [监控设置]
|
|
|
|
📋 风险评估
|
|
├─ 修复失败风险: [低/中/高]
|
|
├─ 副作用影响: [无/有限/广泛]
|
|
└─ 回滚计划: [简单/复杂/不可能]
|
|
|
|
📝 验证步骤
|
|
1. [修复后的确认方法]
|
|
2. [测试执行命令]
|
|
3. [功能确认项目]
|
|
4. [性能影响检查]
|
|
```
|
|
|
|
### 错误类型别分析方法
|
|
|
|
#### 编译/构建错误
|
|
|
|
```bash
|
|
# TypeScript 类型错误
|
|
必须确认 (高):
|
|
- tsconfig.json 设置
|
|
- 类型定义文件 (.d.ts) 存在
|
|
- import 语句的准确性
|
|
|
|
# Rust 生命周期错误
|
|
必须确认 (高):
|
|
- 所有权转移
|
|
- 引用的有效期
|
|
- 可变性冲突
|
|
```
|
|
|
|
#### 运行时错误
|
|
|
|
```bash
|
|
# Null/Undefined 引用
|
|
必须确认 (高):
|
|
- 可选链不足
|
|
- 初始化时机
|
|
- 异步处理的完成等待
|
|
|
|
# 内存相关错误
|
|
必须确认 (高):
|
|
- 获取堆转储
|
|
- 分析 GC 日志
|
|
- 检测循环引用
|
|
```
|
|
|
|
#### 依赖关系错误
|
|
|
|
```bash
|
|
# 版本冲突
|
|
必须确认 (高):
|
|
- lock 文件的一致性
|
|
- peer dependencies 的要求
|
|
- 传递依赖关系
|
|
|
|
# 模块解析错误
|
|
必须确认 (高):
|
|
- NODE_PATH 设置
|
|
- 路径别名设置
|
|
- 符号链接
|
|
```
|
|
|
|
### 注意事项
|
|
|
|
- **绝对禁止**: 仅凭部分错误信息判断、未经验证就应用 Stack Overflow 的解决方案
|
|
- **例外条件**: 临时解决方案仅在以下 3 个条件下允许
|
|
1. 生产环境紧急响应 (24 小时内必须根本解决)
|
|
2. 外部服务故障 (等待恢复期间的替代手段)
|
|
3. 已知框架 bug(等待修复版本发布)
|
|
- **建议事项**: 优先识别根本原因，避免表面修复
|
|
|
|
### 最佳实践
|
|
|
|
1. **完整信息收集**: 确认错误信息从头到尾
|
|
2. **确认重现性**: 优先创建最小重现代码
|
|
3. **渐进式方法**: 从小修复开始验证
|
|
4. **文档化**: 记录解决过程以便知识共享
|
|
|
|
#### 常见陷阱
|
|
|
|
- **处理症状**: 表面修复忽略根本原因
|
|
- **过度泛化**: 将特定案例的解决方案广泛应用
|
|
- **省略验证**: 不确认修复后的副作用
|
|
- **知识孤岛**: 不记录解决方法
|
|
|
|
### 相关命令
|
|
|
|
- `/design-patterns` : 分析代码结构问题并提出模式建议
|
|
- `/tech-debt` : 从技术债务角度分析错误的根本原因
|
|
- `/analyzer` : 需要更深入的根本原因分析时使用
|