⚠️ 第3章 技术选型雷区
盲目追新 · 技术栈不统一 · 忽略社区活跃度 · 许可证风险 —— 四大雷区让项目从起点埋下隐患。
🚩 雷区一：盲目追新
团队倾向于使用最新发布的框架或中间件，却忽略了稳定性、生态成熟度与学习成本。新版本往往存在隐藏缺陷，且文档与最佳实践不足。
💡 避坑建议： 选择发布超过6个月且至少一个中小型生产案例的版本；优先采用LTS（长期支持）版本。
🚩 雷区二：技术栈不统一
不同团队各自为政，微服务使用不同语言、框架、消息协议，导致运维复杂度飙升、知识无法沉淀、人员流转困难。
| 问题 | 后果 | 收敛策略 |
|---|---|---|
| 多语言/多框架 | 构建工具链膨胀，CI/CD 配置复杂 | 制定《技术栈选型标准》 |
| 消息协议不统一 | 数据互通困难，额外网关转换 | 统一使用 gRPC 或 CloudEvents |
| 序列化格式混用 | 调试困难，性能损失 | 强制 Protobuf / Avro |
🚩 雷区三：忽略社区活跃度
选型时只关注功能特性，却忽视社区健康度。一旦遇到棘手 bug 或安全漏洞，无人响应或项目已停滞，风险极高。
GitHub 星数 > 5k
最近一月有发版
Issue 中位数响应 < 48h
贡献者 > 50
🚩 雷区四：许可证风险
使用带有传染性许可证（如 GPL、AGPL）或商业限制的库，可能迫使整个项目开源或面临法律索赔。尤其在使用云服务时需注意 SSPL、BSL 等。
⚖️ 常见许可证对比
| 许可证 | 风险等级 | 典型组件 | 注意事项 |
|---|---|---|---|
| MIT / Apache 2.0 | 🟢 低 | Spring, React | 保留版权声明即可 |
| GPL v2/v3 | 🟡 中 | 某些数据库驱动 | 衍生代码必须开源 |
| AGPL v3 | 🔴 高 | MongoDB (旧版) | 网络交互视为分发 |
| SSPL / BSL | 🔴 极高 | Redis Stack, Elasticsearch | 云服务商受限 |
🧠 技术选型决策框架
🔍 选型四步法：
- 需求匹配度 — 功能覆盖、性能基线
- 社区与生态 — 活跃度、插件/工具链
- 团队能力 — 学习曲线、内部经验
- 合规与风险 — 许可证、商业限制