/tech-research

name: architect/tech-research
description: 技术调研方法论，通过系统性调研和对比分析，为技术选型提供数据支持
version: 1.0.0
agent: architect
type: methodology
user-invocable: false
agent-invocable: true
dependencies:
  - shared/tech-stack-detection
triggers:
  - 开始架构设计前
  - 需要技术选型时
  - 评估新技术方案时

技术调研方法论

适用场景

在进行架构设计和技术选型前，必须先进行系统性的技术调研，了解：

• 业界成熟的技术方案
• 各方案的优缺点和适用场景
• 开源项目的可复用性
• 潜在的技术风险

调研流程

1. 明确调研目标

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

**调研背景模板**：

### 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章）：

## 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小时

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