很多同学觉得，做架构师最爽的事情就是「点将」：这个项目用 Rust，那个项目用 K8s，手起笔落，风光无限。
但在老夫看来，技术选型是架构师离悬崖最近的时候。一念之差，可能就会让整个团队陷入长达数年的泥潭。今天，我们就来扒一扒那些年，我们一起跳过的技术选型大坑。
坑一：粉丝驱动选型 (Fan-driven)#
有些同学是某项技术的死忠粉。对他来说，选型不需要逻辑，只需要信仰。
- 症状：不管业务适合与否，统统梭哈。因为「那个框架的设计太优雅了」或者「那是谷歌出的」。
- 后果：拿着手术刀去砍柴。技术很先进，但开发难度、招聘成本、运维门槛全部超标，最后项目死在「落地」的路上。
坑二：简历驱动开发 (Resume-driven)#
这在一些喜欢折腾的团队里非常普遍。为了让自己的简历更好看，架构师会故意选择一些复杂、冷门、但听起来「逼格」很高的技术。
- 症状：为了一个简单的内部系统，强行引入区块链、流计算或 Service Mesh。
- 后果：留下一堆只有他自己懂（甚至他自己也不懂）的烂摊子，然后他拿着镶金的简历跳槽了，剩下的兄弟们在废墟里哭。
坑三：盲目追求「工业标准」#
有些公司喜欢照搬大厂的方案。阿里用这个，我也要用；字节用那个，我也得跟上。
- 症状：完全无视自己的业务规模和团队能力。
- 后果：大厂的方案是为了解决「亿级并发」下的问题，那是用极高的复杂性去换取极致的性能。如果你的并发只有三位数，用这种方案就是「大炮打蚊子」，光是维护那套基础设施就能耗尽你所有的研发人力。
科学选型的三个维度#
真正的技术选型，应当是冷静的计算，而不是热血的冲刺。
- 匹配业务生命周期：初创期的项目，速度第一，选成熟、生态好、上手快的；稳定期的项目，性能和可靠性第一，可以选更硬核、更专精的。
- 匹配团队内功：如果团队大部分是 Java 背景，你非要让他们去维护一套复杂的 Rust 系统，那不是激励，那是自残。
- 考察「拥有权总成本」 (TCO)：技术选型不只是写代码那几天，还要看后续三五年的升级成本、学习曲线、云服务开销以及人才市场的招聘难度。
结语#
技术永远是手段，业务才是目的。
正如《孙子兵法》所云：「知己知彼，百战不殆。」
在选型之前，先审视自己的团队（知己），再洞察技术的本质与局限（知彼）。不要做技术的奴隶，要做技术的主人。愿每一位架构师都能做到「君子不器」，让每一次选型都成为项目腾飞的翅膀，而不是脚下的镣铐。