选型不是选技术，是选风险
接了一个新项目，老板对你说：「技术方案你来定，三个月内要上线。」
你打开一堆技术选型文章，越看越乱：有人说微服务是未来，有人说单体会害死你；有人吹 Kafka，有人捧 Pulsar。
到底听谁的？
今天聊一个被写烂、却很少有人讲透的话题：作为技术负责人，从 0 到 1 做技术选型，你到底在做什么选择？
我先给结论：技术负责人的选型，本质上不是「选哪个技术强」，而是「选哪种风险你承担得起」。
想明白这一句，后面所有的决策都会顺。
一、你和普通开发做选型，根本不是同一件事
普通开发做选型，考虑的常常是「哪个用起来爽」「哪个文档全」「哪个我熟」。
技术负责人做选型，考虑的是三件沉甸甸的事：
- 不可逆性：这个决定做错了，三个月后还能不能改？改的成本谁扛？
- 长期成本：这套技术未来三年，招人、维护、升级、交接，各要花多少钱？
- 团队约束：再好的技术，团队没人会用，等于没有。
所以技术负责人的 KPI 从来不是「技术多先进」，而是——项目能不能按时上线、稳定运行、后人不骂你。
二、第一性原理：把决策分成「单向门」和「双向门」
这是我最想让你记住的一个概念。
亚马逊的贝索斯把决策分成两类：
单向门（one-way door）：推开了就回不来，切换成本极高。比如数据库选型、核心语言、主框架。这种决策要慢、要论证、要签字。
双向门（two-way door）：可以随时回头，试错成本低。比如某个监控面板、某个日志库、某个中间件的客户端。这种决策要快、要试、别纠结。
大多数人做选型，恰恰做反了——在「用哪个日志库」上纠结半天，在「用单体还是微服务」上拍脑袋。
我的原则是：把 80% 的精力花在单向门上，双向门直接选个顺手的先用，不行再换。
三、四步决策流程：从 0 到 1 的落地路径
第 1 步：定「不变量」，而不是先定「技术」
动手选型之前，我先问四个问题：
- 业务边界：这个项目到底解决什么问题？一年后的量级大概多大？
- 团队现状：现在有几个人？会什么？能不能招到会这套技术的人？
- 时间窗口：多久要上线？有没有试错的余量？
- 预算：能上多大规格的机器，能买多少云资源？
约束，永远排在偏好前面。一个三人的小团队要三个月上线，你选一套需要五个人维护的微服务架构，那不是选型，是自掘坟墓。
第 2 步：分层选型，别眉毛胡子一把抓
技术选型不是「开一个会把所有技术定完」，而是分层决策：
| 层 | 内容 | 决策方式 |
|---|---|---|
| 基础设施层 | 数据库、消息队列、缓存 | 单向门，慎之又慎 |
| 应用框架层 | 语言、主框架、ORM | 单向门，重论证 |
| 中间件客户端层 | 连接池、熔断器、日志 | 双向门，可快 |
| 业务组件层 | 某个工具库、某个工具类 | 双向门，随时换 |
分层的目的，是让你知道哪些决策值得花时间，哪些不该。
第 3 步：三个铁律，帮你做判断
面对「A 还是 B」的选择时，我用三条铁律过滤：
- 成熟优先于新颖：上线半年内的新技术，除非团队就是它的主力贡献者，否则不用。
- 团队熟悉优先于个人喜好：负责人的技术审美，要让位于团队的战斗力。
- 生态优先于裸性能：能融入现有生态、社区活跃，比跑分快 10% 重要得多。
第 4 步：试点 + 留痕
- 试点：单向门决策，先写 POC 压测一轮，用数据说话。
- 留痕：每个关键决策写一条 ADR（架构决策记录），记下「为什么这么选、拒绝了谁、什么条件下重估」。
四、几个关键决策点，讲透因果
下面是我真实做过的几个选型，每个都带「因为…所以…」的因果链。你可以直接借鉴思路。
1. 单体还是微服务？——从 0 到 1，先别微服务。
这是我给新项目最重要的建议。从 0 到 1 的阶段，业务边界是模糊的，你在「还看不清边界」的时候拆微服务，拆出来的每个边界大概率是错的。
我的做法是：模块化单体（Modular Monolith）起步——代码里按模块严格隔离、定义清晰边界，但先跑在一个进程里。等业务稳定、边界清晰、团队规模上来了，再按模块拆出去。
这样你既保住了单体的「部署简单、开发快」，又为未来的拆分留了「干净的接口」。
2. 语言/框架——LTS + 团队熟悉。
我会优先选有长期支持（LTS）的稳定版本，而不是最新版。理由很简单：一个要跑三年的项目，你要的是「出了问题有人管、补丁持续有」，而不是「用了最新特性」。
3. 消息队列——按业务场景选，不按名气选。
我们的订单业务有「取消超时、延迟确认」这类需求，所以我选了原生支持延迟消息和事务消息的 RocketMQ，而不是 Kafka。
Kafka 很强，但强在日志流式吞吐；业务消息场景，RocketMQ 更顺手。「强」不等于「合适」，这是选型的第一课。
4. 缓存——要高级特性，就别裸用客户端。
我们需要分布式锁、布隆过滤器，所以直接上了 Redisson——开箱即用。裸客户端（Jedis/Lettuce）只是连接层，这些能力都得自己造轮子，自己造的轮子还得自己维护，不划算。
5. ORM——团队习惯写 SQL，就别硬上 JPA。
复杂查询要精细可控，MyBatis-Plus 透明、不黑盒；JPA 的懒加载和 N+1 问题，在复杂查询场景里是高频坑。
6. 熔断器——不选「已停止维护」的组件。
老牌的 Hystrix 早就进入维护模式，我选了更轻量、函数式的 Resilience4j，还支持细粒度熔断。
💡 看出来了吗？这些选择的共同点，不是「哪个技术更强」，而是**「哪个更适合当下的团队、业务和阶段」**。
五、选型之后，怎么让决策「活下来」
选型不是开完会就结束了。真正拉开差距的，是选完之后这三件事：
1. 落地成规范
把选型结果写进团队的「技术规范」，新代码必须遵守，否则选型就是一张废纸。
2. 守住边界
用代码评审、脚手架、公共组件库，把选型「焊死」在流程里，防止有人悄悄引入一套新的。
3. 定期复盘
每季度回头看一眼 ADR：当时的假设还成立吗？不成立了，就重新评估。选型是活的，不是一次定终身。
六、技术负责人最常踩的四个坑
坑 1：过度设计。
一个还没验证的项目，上来就上全套微服务、K8s、分库分表。结果三个月了还在搭架子，业务一行没写。
坑 2：追新。
「这个新框架 star 涨得好快」，你忍不住上了。三个月后作者弃坑了，你成了唯一维护者。
坑 3：被「最佳实践」绑架。
大厂的架构不是你的架构。人家的量级、团队、预算，你一样都没有。抄架构前，先抄约束。
坑 4：忽视团队能力。
选了一套团队没人会、也招不到人的技术，最后只能你一个人扛。
写在最后
技术选型这件事，越往上走，越会发现它不是一道技术题，而是一道风险管理题。
记住这四句话：
- 选型是选风险，不是选技术。
- 单向门慢决策，双向门快试错。
- 约束大于偏好，成熟大于新颖，团队大于个人。
- 从 0 到 1 先别微服务，模块化单体起步。
做到这四点，你做的每一个选择，都能坦然面对三个月后的自己和接手项目的后人。
