fmode-app/.claude/skills/dev-expert/references/tech-selection.md

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

输入要求

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、是否需要额外权限、是否引入新的攻击面

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

第五步：决策记录

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

## 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 版本推荐矩阵