## 错误修复

从错误信息中识别根本原因，预测解决时间，提出经过验证的解决方案。学习类似错误的模式，立即提供合适的处理方法。

### 使用方法

```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` : 需要更深入的根本原因分析时使用