技术选型维度
技术选型要按统一维度评估，而不是凭印象综合感觉：问题匹配度、成熟度与生产案例、团队技能与学习曲线、生态与社区活跃度、性能与容量、运维成本、许可与合规、退出成本。维度确定后先给权重再收集证据，可以减少先有结论再找理由的偏差。
退出成本最容易被低估
引入一个框架或数据库时，团队通常只算接入成本，忽略将来替换时的数据迁移、接口改造与重新学习成本。判断退出成本的简易方法是看三点：数据格式是否开放、是否提供标准协议接口、核心业务逻辑是否会被特有 API 绑死。绑定越深，未来的选择空间越小。
评估维度
| 维度 | 评估问题 | 证据来源 |
|---|---|---|
| 匹配度 | 能否解决核心问题 | 场景验证与可行性验证 |
| 成熟度 | 生产案例与版本稳定性 | 案例库与版本历史 |
| 团队 | 学习曲线与招聘难度 | 团队试用评估 |
| 运维 | 部署、监控与升级成本 | 运维演练 |
| 退出成本 | 替换与数据迁移代价 | 接口开放性与数据格式 |
操作要点
| 权重先行 | 不同项目核心约束不同，先定权重再评估 |
|---|---|
| 决策记录 | 记录选择理由与被放弃的备选方案 |
| 复核时点 | 在项目里程碑处重新审视当时的假设 |
| 反证练习 | 主动列出可能让该选择失败的场景 |
典型使用场景
- 引入新框架或语言：评估团队承接能力与生态
- 更换数据库：权衡迁移成本与性能收益
- 选择消息中间件：比对语义保证与运维复杂度
- 云服务商选型：考虑成本模型与锁定程度
- 自建与采购决策：比较长期运维投入与采购费用
维度权重要先定：不同项目的核心约束差别很大，把权重写下来再收集证据，能显著减少技术偏好与个人经验对结论的干扰。