architect/tech-research

# 技术调研方法论

## 适用场景

在进行架构设计和技术选型前，必须先进行系统性的技术调研，了解：
- 业界成熟的技术方案
- 各方案的优缺点和适用场景
- 开源项目的可复用性
- 潜在的技术风险

## 调研流程

### 1. 明确调研目标

基于PRD的技术需求，明确需要调研的技术领域：

**调研背景模板**：

```markdown
### 1.1 调研背景

**需求概述**：[基于 PRD 的技术需求总结]

**关键技术挑战**：
- [挑战 1]：[具体描述]
- [挑战 2]：[具体描述]
- [挑战 3]：[具体描述]

**调研目标**：
- [ ] 前端框架选型
- [ ] 后端框架选型
- [ ] 数据库选型
- [ ] 缓存方案选型
- [ ] 部署方案选型
```

### 2. 使用WebSearch进行调研

#### 搜索策略

**通用搜索模式**：
```
"{技术领域} + best practices + 2026"
"{框架名} vs {框架名} comparison 2026"
"{技术领域} + benchmark + 2026"
"best {技术领域} tools 2026"
```

**具体示例**：

**前端框架调研**：
```
"React vs Vue vs Angular comparison 2026"
"Next.js vs Remix vs Astro 2026"
"best React UI libraries 2026"
```

**后端框架调研**：
```
"Node.js frameworks comparison 2026"
"Express vs Fastify vs Hono benchmark"
"Python web frameworks 2026"
```

**数据库调研**：
```
"PostgreSQL vs MySQL vs MongoDB 2026"
"database for {use case} 2026"
"SQL vs NoSQL when to use"
```

**ORM调研**：
```
"Prisma vs TypeORM vs Drizzle comparison"
"best ORM for {language} 2026"
```

#### 搜索技巧

1. **包含年份**：确保获取最新信息
2. **对比搜索**：使用 "vs" 或 "comparison" 获取对比分析
3. **性能搜索**：使用 "benchmark" 或 "performance" 获取性能数据
4. **实践搜索**：使用 "best practices" 获取最佳实践
5. **问题搜索**：使用 "pros and cons" 或 "disadvantages" 了解缺点

### 3. 使用WebFetch深入分析

对于重要的技术方案，使用 `WebFetch` 深入分析官方文档和技术文章：

**官方文档**：
```
WebFetch("https://nextjs.org/docs", "总结 Next.js 的核心特性、适用场景和最新版本的主要变化")
WebFetch("https://www.prisma.io/docs", "提取 Prisma 的核心功能、支持的数据库和性能特点")
```

**技术对比文章**：
```
WebFetch("[对比文章URL]", "提取各方案的优缺点对比、性能数据和推荐场景")
```

**GitHub仓库**：
```
WebFetch("https://github.com/{org}/{repo}", "提取 Star 数、最近更新时间、维护状态和主要贡献者")
```

### 4. 技术方案对比

#### 对比维度

对每个技术方案，从以下维度进行评估：

| 维度 | 评估内容 |
|------|----------|
| **功能完整性** | 是否满足项目需求 |
| **性能** | 响应时间、吞吐量、资源消耗 |
| **生态系统** | 社区活跃度、插件丰富度、文档质量 |
| **学习曲线** | 团队学习成本、上手难度 |
| **成熟度** | 版本稳定性、生产案例、维护状态 |
| **扩展性** | 是否易于扩展和定制 |
| **兼容性** | 与其他技术的集成难度 |
| **成本** | 开发成本、运维成本、授权成本 |

#### 对比表格模板

**前端框架对比**：

| 方案 | 优点 | 缺点 | 适用场景 | 推荐度 |
|------|------|------|----------|--------|
| Next.js | SSR/SSG、SEO友好、全栈能力 | 学习曲线陡、打包体积大 | 内容型网站、SEO要求高 | ⭐⭐⭐⭐⭐ |
| Vite + React | 开发体验好、构建快 | 需要自己配置路由等 | SPA、快速原型 | ⭐⭐⭐⭐ |
| Remix | 数据加载优雅、Web标准 | 生态较新、案例较少 | 数据密集型应用 | ⭐⭐⭐ |

**后端框架对比**：

| 方案 | 优点 | 缺点 | 适用场景 | 推荐度 |
|------|------|------|----------|--------|
| Express | 成熟、生态丰富、灵活 | 性能一般、缺少约定 | 通用后端、快速开发 | ⭐⭐⭐⭐ |
| Fastify | 性能高、插件系统好 | 生态较Express小 | 性能要求高的API | ⭐⭐⭐⭐ |
| Hono | 极致性能、边缘计算 | 生态较新 | Serverless、边缘函数 | ⭐⭐⭐ |

**数据库对比**：

| 方案 | 类型 | 优点 | 缺点 | 适用场景 |
|------|------|------|------|----------|
| PostgreSQL | 关系型 | 功能强大、扩展性好、JSON支持 | 运维复杂度高 | 复杂查询、事务、JSONB |
| MySQL | 关系型 | 简单、普及、性能好 | 功能较PostgreSQL少 | 通用场景、读多写少 |
| MongoDB | 文档型 | 灵活、易扩展、开发快 | 事务支持弱、数据一致性 | 非结构化数据、快速迭代 |
| SQLite | 嵌入式 | 零配置、单文件、轻量 | 并发限制、功能有限 | 小型应用、原型、嵌入式 |

### 5. 开源方案评估

对于可能复用的开源项目，进行系统性评估：

| 开源项目 | 功能 | Star 数 | 最近更新 | 维护状态 | 是否采用 | 理由 |
|----------|------|---------|----------|----------|----------|------|
| [项目名] | [功能描述] | [数量] | [日期] | 活跃/停滞 | 是/否 | [理由] |

**评估标准**：
- **Star 数 > 1000**：说明有一定用户基础
- **最近更新 < 6个月**：说明项目活跃
- **Issue响应及时**：说明维护良好
- **文档完善**：说明易于使用
- **License友好**：MIT/Apache 2.0 等宽松协议

### 6. 调研结论

基于调研结果，给出明确的技术选型建议：

| 层级 | 推荐方案 | 选择理由 | 备选方案 |
|------|----------|----------|----------|
| 前端 | [方案] | [理由] | [备选] |
| 后端 | [方案] | [理由] | [备选] |
| 数据库 | [方案] | [理由] | [备选] |
| 缓存 | [方案] | [理由] | [备选] |
| 部署 | [方案] | [理由] | [备选] |

**选择理由应包含**：
- 为什么选择这个方案（优势）
- 为什么不选其他方案（劣势）
- 与项目需求的匹配度
- 团队能力的匹配度

## 输出要求

完成技术调研后，应输出以下内容（通常作为架构文档的第1章）：

```markdown
## 1. 技术调研

### 1.1 调研背景

**需求概述**：[基于 PRD 的技术需求总结]

**关键技术挑战**：
- [挑战 1]
- [挑战 2]
- [挑战 3]

### 1.2 技术方案调研

#### 前端框架对比

| 方案 | 优点 | 缺点 | 适用场景 | 推荐度 |
|------|------|------|----------|--------|
| [方案1] | ... | ... | ... | ... |
| [方案2] | ... | ... | ... | ... |

#### 后端框架对比

[同上]

#### 数据库对比

[同上]

### 1.3 开源方案评估

| 开源项目 | 功能 | Star 数 | 维护状态 | 是否采用 |
|----------|------|---------|----------|----------|
| [项目1] | ... | ... | ... | ... |

### 1.4 调研结论

| 层级 | 推荐方案 | 选择理由 | 备选方案 |
|------|----------|----------|----------|
| 前端 | [方案] | [理由] | [备选] |
| 后端 | [方案] | [理由] | [备选] |
| 数据库 | [方案] | [理由] | [备选] |
```

## 关键原则

1. **真实调研**：必须真实使用 WebSearch 和 WebFetch，不能凭空编造
2. **数据支撑**：结论必须基于调研数据，不能主观臆断
3. **对比分析**：至少对比3个方案，说明为什么选择A而不是B
4. **考虑现状**：如果项目已有技术栈（通过 shared/tech-stack-detection 检测），优先考虑兼容性
5. **团队能力**：考虑团队的技术背景和学习成本

## 常见误区

❌ **不调研就选型**：直接给出技术方案，没有调研过程
❌ **只看优点**：只列优点不列缺点，缺乏客观性
❌ **追新求异**：盲目选择最新技术，忽略成熟度和风险
❌ **忽略现状**：不检测项目现有技术栈，推荐不兼容的方案
❌ **缺少备选**：只给一个方案，没有Plan B

## 调研时间建议

- **简单项目**：30分钟 - 1小时
- **中型项目**：1-2小时
- **复杂项目**：2-4小时

不要过度调研，调研的目的是支持决策，不是写论文。