# 技术选型

## 规则（Rules）

# 技术选型规范

## 适用对象和范围

本规范适用于所有评估和选择技术方案的场景。

---

## 1. 多维度评估规范

**规则**：必须从功能完整性、性能表现、社区活跃度、学习成本、维护成本5个维度进行评分。

**违反后果**：单维度评估导致选型决策片面。

---

## 2. 客观决策规范

**规则**：禁止仅凭个人偏好做出选型决策，必须基于多维度评分数据。

**违反后果**：主观决策可能导致技术方案不适合项目实际需求。

---

## 3. 长期维护规范

**规则**：必须评估技术方案的长期维护成本，包括社区活跃度和版本更新频率。

**违反后果**：忽略长期维护成本可能导致项目后期面临技术债务。

## 方法（Methods）

# 技术选型方法

## 前置条件

- [ ] 已获取需求文档，了解技术需求和约束条件

---

## 流程概览

```
梳理技术需求 → 调研候选方案 → 方案评估 → 输出选型报告
```

---

## 详细步骤

### 步骤1：梳理技术需求

分析需求文档，明确技术需求和约束条件。

### 步骤2：调研候选方案

列出每个技术领域的候选方案（至少2个），收集优缺点和适用场景。

### 步骤3：方案评估

从功能完整性、性能表现、社区活跃度、学习成本、维护成本5个维度评分。

## 技巧（Tips）

# 技术选型技巧

## 1. 优先考虑团队熟悉的技术

**适用场景**：多个候选方案评分接近时。

**具体做法**：优先选择团队已有经验的技术，降低学习成本和风险。

**注意事项**：如果新技术带来显著收益（性能提升50%以上），可以考虑引入。

---

## 2. 关注社区生态

**适用场景**：评估第三方库或框架时。

**具体做法**：查看GitHub Star数、Issue响应速度、版本更新频率、文档质量。

**注意事项**：Star数高不一定代表质量好，需要结合项目实际需求判断。

---

## 3. 常见问题速查

| 问题 | 原因 | 解决方案 |
|------|------|---------|
| 候选方案不满足需求 | 调研范围不够 | 扩大调研，补充更多候选方案 |
| 评估数据不足 | 信息不充分 | 标注不确定性，建议PoC验证 |