microwind 范式选择指南 (Paradigm Selection Guide)
决策流程
1. 项目类型是什么？
├── 业务系统 → OOP 为主 + FP 辅助
├── 数据处理 → FP 为主
├── 实时系统 → 响应式 + 并发
├── 脚本工具 → 过程式
├── 游戏引擎 → OOP + 面向数据
└── AI Agent → 面向代理
2. 团队熟悉什么范式？
→ 主范式选团队最熟悉的
3. 性能要求如何？
├── 极致性能 → 面向数据
├── 高并发 → FP（不可变）+ 响应式
└── 一般 → OOP 即可
4. 数据特征是什么？
├── 复杂对象关系 → OOP
├── 数据转换管道 → FP
└── 事件流 → 响应式
按项目类型推荐
| 项目类型 | 主范式 | 辅助范式 | 代表语言 |
|---|---|---|---|
| Web 后端 | OOP | FP, AOP | Java, C#, Python |
| Web 前端 | FP + OOP | 响应式 | TypeScript, React |
| 数据工程 | FP | 过程式 | Python, Scala |
| 移动开发 | OOP | FP, 协议 | Kotlin, Swift |
| 系统编程 | 过程式 | 面向数据 | C, Rust |
| DevOps/脚本 | 过程式 | FP | Bash, Python |
| 游戏开发 | OOP + DOD | 过程式 | C++, C# |
| AI/ML | FP + 过程式 | OOP | Python |
| 微服务 | OOP | 响应式, FP | Java, Go |
| 嵌入式 | 过程式 | — | C |
语言支持矩阵
| 语言 | OOP | FP | 过程式 | 响应式 | 并发 | AOP |
|---|---|---|---|---|---|---|
| Java | ✅✅ | ✅ | ✅ | ✅ | ✅✅ | ✅✅ |
| Python | ✅ | ✅ | ✅✅ | ⚠️ | ✅ | ✅ |
| TypeScript | ✅ | ✅✅ | ✅ | ✅✅ | ✅ | ✅ |
| Kotlin | ✅✅ | ✅✅ | ✅ | ✅✅ | ✅✅ | ⚠️ |
| Rust | ⚠️ | ✅✅ | ✅ | ✅ | ✅✅ | ⚠️ |
| Go | ⚠️ | ⚠️ | ✅✅ | ⚠️ | ✅✅ | ⚠️ |
| Swift | ✅✅ | ✅ | ✅ | ✅ | ✅✅ | ⚠️ |
| Scala | ✅✅ | ✅✅ | ✅ | ✅✅ | ✅✅ | ⚠️ |
✅✅ = 优秀支持 ✅ = 良好支持 ⚠️ = 有限支持
常见错误
❌ 强行用一种范式解决所有问题
❌ 选择团队完全不熟悉的范式
❌ 为了"先进"而选择不适合的范式
❌ 忽视语言对范式的支持程度
❌ 项目中途大规模切换范式
✅ 以一种范式为主，其他辅助
✅ 渐进式引入新范式
✅ 团队学习后再采用
✅ 选择语言原生支持的范式
总结
核心：没有最好的范式，只有最合适的。根据项目类型、团队能力、语言支持综合选择。
原则：主范式统一、辅助范式灵活、团队达成共识。