# 技术选型 -- 智能技术选型

## 输入要求

1. **项目需求**（必填）：项目类型、核心功能、目标用户
2. **团队情况**（必填）：团队规模、技术背景、经验水平
3. **约束条件**（可选）：预算、时间、性能要求、合规要求
4. **已有技术栈**（可选）：如果已有部分技术选型
5. **排除选项**（可选）：明确不用的技术

## 执行流程

### 第一步：需求分析

- 识别项目类型（Web应用、移动端、数据平台、工具库等）
- 明确核心功能和非功能需求
- 识别关键约束（性能、安全、扩展性）

### 第二步：技术分类推荐

| 分类         | 考虑因素                       | 推荐维度                       |
| ------------ | ------------------------------ | ------------------------------ |
| **前端框架** | 交互复杂度、SEO需求、团队经验  | React/Vue/Angular/Svelte       |
| **后端框架** | 并发量、实时性、生态成熟度     | Spring/FastAPI/Express/Django  |
| **数据库**   | 数据模型、读写比例、一致性要求 | PostgreSQL/MySQL/MongoDB/Redis |
| **部署运维** | 规模、预算、团队运维能力       | Docker/K8S/Serverless/VPS      |
| **缓存消息** | 性能要求、解耦需求             | Redis/RabbitMQ/Kafka           |

### 第三步：方案对比

对每个候选技术：

- **优势**：核心卖点、生态成熟度、社区活跃度
- **劣势**：已知问题、学习曲线、局限性
- **适用场景**：最佳使用场景
- **不适用场景**：明确不适合的情况

### 第四步：给出推荐

- 首选方案 + 备选方案
- 选型理由（基于需求匹配度）
- **反选论证（必填）**：明确说明「为何不选备选方案」——逐条列出备选方案的 trade-off 为何在本项目约束下不可接受，而非仅罗列优劣
- **接受的代价**：首选方案在本项目下的已知技术债与限制
- 风险评估和缓解措施
- 迁移/学习成本估算

> ⚠️ 重点：技术选型必须输出「反选论证」，只给"首选+理由"视为不完整；反选论证须说明「为何不选 B」，而非仅罗列「为何选 A」。

#### 选型验证（必填）

推荐方案确定后，必须完成以下验证才能进入决策记录：

- [ ] **可行性验证**：首选方案在目标环境是否能跑通最小原型
- [ ] **兼容性验证**：与现有技术栈（PHP 版本/CMS/框架/数据库）兼容，无已知冲突
- [ ] **依赖验证**：依赖包是否存在、是否维护中、是否有重大版本变更风险
- [ ] **性能验证**：预期性能是否满足需求（如已存在 benchmark 数据则引用，否则标注"待实测"）
- [ ] **安全验证**：是否有已知 CVE、是否需要额外权限、是否引入新的攻击面

如某项无法验证，必须在推荐中标注"未验证项"和风险评估，不得跳过。

### 第五步：决策记录

选型完成后记录决策到项目记忆：

```markdown
## Decision Record: [技术选型名称]

**日期**: [YYYY-MM-DD]
**问题**: [需要解决的技术问题]

### 选项分析

| 选项    | 优势 | 劣势 | 适用场景 |
| ------- | ---- | ---- | -------- |
| [选项A] | ...  | ...  | ...      |
| [选项B] | ...  | ...  | ...      |

### 决策

**选择**: [最终选项]
**理由**: [核心原因]
**Trade-offs**: [接受的代价]

### 影响范围

- [影响的模块/项目]
- [需要学习的成本]

### 撤销条件

[什么情况下重新评估]
```

**提示用户**：使用 `project-memory-management` 将此决策记录到项目记忆中。

## 输出格式

```
## 技术选型报告

**项目类型**：[类型]
**团队规模**：[规模]
**核心需求**：[需求摘要]

## 推荐方案

### 首选方案

| 层级 | 推荐技术 | 选型理由 |
|------|---------|---------|
| 前端 | [技术] | [理由] |
| 后端 | [技术] | [理由] |
| 数据库 | [技术] | [理由] |
| 部署 | [技术] | [理由] |

### 备选方案

[简要说明备选方案及适用情况]

## 详细对比

### [技术A] vs [技术B]

| 维度 | [技术A] | [技术B] |
|------|---------|---------|
| 学习成本 | [高/中/低] | [高/中/低] |
| 社区活跃度 | [高/中/低] | [高/中/低] |
| 性能 | [优/良/一般] | [优/良/一般] |
| 招聘难度 | [易/中/难] | [易/中/难] |

## 风险评估

| 风险 | 概率 | 影响 | 缓解措施 |
|------|------|------|---------|
| [风险1] | [高/中/低] | [高/中/低] | [措施] |

## 实施建议

1. [阶段1：MVP技术栈]
2. [阶段2：扩展和优化]
3. [阶段3：长期演进]
```

## 质量标准

- 推荐必须基于具体需求，不能给通用答案
- 必须给出至少2个候选方案的对比，不能只推荐一个
- 风险评估必须具体
- 必须考虑团队现有技术栈和学习成本
- 不得推荐已停止维护或社区活跃度低的技术
- 性能对比必须有量化依据

## 失败回退机制

| 步骤                 | 失败条件                              | 回退目标                               | 最大重试 | 不可恢复时升级路径                               |
| -------------------- | ------------------------------------- | -------------------------------------- | -------- | ------------------------------------------------ |
| 第一步：需求分析     | 项目需求过于宽泛，无法识别关键约束    | 列出常见约束清单，要求用户勾选         | 2        | 输出"需求澄清问卷"，等待用户补充                 |
| 第二步：技术分类推荐 | 团队技术背景与推荐方向严重不匹配      | 优先推荐团队熟悉的技术栈，标注学习成本 | 1        | 输出两套方案（团队熟悉 vs 技术先进），由用户权衡 |
| 第三步：方案对比     | 候选技术缺乏量化数据                  | 标注"数据待验证"，提供定性对比         | 2        | 建议POC验证后补充量化数据                        |
| 第四步：给出推荐     | 首选与备选方案trade-off接近，难以抉择 | 输出决策矩阵，由用户最终决策           | 1        | 建议小范围POC验证后再决策                        |
| 第五步：决策记录     | 项目记忆系统不可用                    | 输出Decision Record到本地文件          | 1        | 标注"决策未沉淀"，提示用户手动保存               |

### CMS PHP 版本推荐矩阵

当项目涉及 PHP+MySQL CMS 时，以下矩阵为必查依据：

| CMS           | 最低版本 | 推荐版本 | 不兼容提示            |
| ------------- | -------- | -------- | --------------------- |
| EmpireCMS 7.5 | 7.4      | 8.2      | 需 PHP 8 兼容补丁     |
| WordPress 6.x | 7.4      | 8.2      | 部分老插件不兼容 8.3+ |
| ThinkPHP 6    | 7.4      | 8.2      |                       |
| ThinkPHP 8    | 8.0      | 8.2      |                       |
| Laravel 9     | 8.0      | 8.1      |                       |
| Laravel 10    | 8.1      | 8.2      |                       |
| Laravel 11    | 8.2      | 8.3      |                       |
| CodeIgniter 4 | 7.4      | 8.2      |                       |
| DedeCMS v5.7  | 5.6      | 7.4      | 不支持 PHP 8          |
| Hyperf        | 8.0      | 8.2      | 跟随 Swoole 版本      |

**选型原则**：CMS 要求优先 → 用户指定 → 默认 8.2。详见 `cms-development.md`。

## 关联 reference

- **software-project**（软件项目总控）— 技术选型结果应回连 `software-project.md` 总控流程，作为架构决策记录和交付物的一部分
- **frontend-design**（前端设计）— 前端框架/组件库/设计系统选型后可用 `frontend-design` 输出页面和组件落地规范
- **api-design**（API设计）— 确定技术栈后可用 `api-design` 设计接口规范
- **cms-development**（CMS二次开发）— PHP+MySQL CMS 场景参考 `cms-development.md` 的 PHP 版本推荐和 CMS 探测
- **mysql-database**（MySQL数据库）— 选择 MySQL 或涉及 SQL/索引/事务/迁移时参考 `mysql-database.md`
- **code-generation**（代码生成）— 确定框架后可用 `code-generation` 生成项目脚手架
- **doc-generation**（文档生成）— 选型完成后可用 `doc-generation` 生成技术决策文档
- **project-memory-management**（项目记忆管理）— 记录技术选型决策（Decision Record）和 CMS 版本推荐矩阵