我刚开始搞这行那会儿，真是个愣头青。那时候，我最烦的就是别人跟我说“这事儿得看情况”或者“这取决于什么什么”。我心里就想，妈的，老子要的就是个准话，你跟我打什么太极？
那会儿我刚从一个纯写代码的小螺丝钉，被提拔上去带了个小团队，第一次当头儿。上面交下来一个活儿，要做一个在线教育平台，要求挺急的。我当时就想着，得把所有东西都整得明明白白，万无一失。于是我就开始到处问，到处找“最优解”。
我寻思着，肯定有个“标准答案”？
我记得特别清楚，当时第一个卡壳的问题就是：我们这个平台，将来可能用户量会很大，那数据库到底该用是上传统的MySQL还是SQL Server？要不要试试当时很火的NoSQL，比如MongoDB？我把这个问题拿去问了我那个带了我们好几年的老哥，他一听，不紧不慢地喝了口茶，然后跟我说：“小张，这数据库用什么，取决于你打算怎么用，取决于你的用户量预期，取决于你的团队更熟悉哪个，还取决于你兜里有多少预算。”
我当时听得是血压直线上升。我心想这不废话吗？我知道“取决于”，我就是想让你告诉我，在我的这些“取决于”里，哪个是最好的！我就是想要个现成的、能够直接拿来用的答案！
我当时没听他的，自己一头扎进了各种技术论坛和博客。我翻遍了国内外关于“数据库选型”的文章，什么“百万并发下MySQL性能优化”、“MongoDB在教育行业的应用实践”、“PostgreSQL的十个优势”……看了一大堆，结果脑子里更乱了。每个文章都说自己的每个评论区都吵得不可开交，A说A强，B说B棒，谁也说服不了谁。我甚至还私信去问了几个“大神”，结果他们给的答案也五花八门，根本没有个统一的说法。
我当时就觉得，妈的，这帮人是不是故意的，不肯给我还是他们自己也不知道？我那时就认定，肯定有个“银弹”，他们只是不愿意告诉我。
硬着头皮上，然后就被教做人了
后来我们团队硬着头皮，选了当时觉得社区最活跃、资料最多的MySQL。想着万一出问题，网上肯定能找到解决办法。前期小用户量的时候，跑得确实没啥毛病。我当时还沾沾自喜，觉得那些老家伙就是爱故弄玄虚。
结果？系统上线半年，用户量开始噌噌往上涨。尤其是每次活动高峰期，几万用户一涌进来，我们的系统就开始卡壳，页面半天刷新不出来，后台统计数据跑得贼慢。用户投诉雪片一样飞来，我们团队天天加班加点，又是优化SQL语句，又是加索引，又是上读写分离，又搞了个Redis集群做缓存。那段时间，我们真的忙得跟狗一样，焦头烂额。
有一次，一个关键的报表功能，因为数据量太大，MySQL怎么都跑不动，老板急着要。我当时急得脸都白了，又去请教那个老哥。他过来瞅了一眼，就淡淡地说了一句：“如果当初考虑了大数据量下的查询需求和报表生成场景，可能就不会用MySQL做核心报表库了，也许一开始就该上个专门的数据仓库，或者起码用PostgreSQL。”
我当时听了，心里那叫一个服气又懊悔。是，当初我只想着“哪个最流行”，没想着“它到底适合不适合我的具体场景”。就因为我死活想找个“万能答案”，结果让团队在后面做了无数的补救工作，吃了大亏。
现在我懂了，“取决于”才是真理
再后来又有个新项目，要搞个实时推送通知系统。我团队里有个小伙子，兴冲冲地跑过来问我：“哥，消息队列用Kafka还是RabbitMQ？我看网上都说Kafka性能高！” 我当时听他这么问，没直接给答案，而是反问了他几个问题：“你这个推送，是要求绝对实时性还是允许一点延迟？你每天预计的消息量大概有多少？你团队里有人用过Kafka吗？你们有没有运维团队来维护这个复杂的集群？”
小伙子被我问得愣住了，挠了挠头，说：“额……没想这么多。”
我拍了拍他肩膀，说：“这就对了。你看，不是哪个技术本身牛逼，而是它跟你的实际情况匹不匹配。Kafka虽然性能猛，但是部署和运维复杂，对团队技术能力要求高。如果你消息量没那么大，或者对实时性要求没到毫秒级，RabbitMQ可能维护起来更省心。这都是‘取决于’的东西。”
经过这些年的摸爬滚打，我现在是彻底明白了。以前我把“取决于”当成是敷衍，现在我把它奉为圭臬。这三个字，不是推卸责任的借口，它恰恰是对现实复杂性深刻理解后的智慧。每个项目，每项决策，它的“最优解”从来都不是绝对的，它总是跟你的资源、你的目标、你的团队能力、你的时间节点等等一大堆因素紧密相关。
现在再有人问我“什么最好”，我根本不会直接告诉他一个答案。我会先把他问清楚：你究竟想解决什么问题？你手里有什么牌？你希望达到什么效果？等你把这些搞明白了，那个“取决于”的答案自然就浮出水面了。这可比直接抛一个要负责任得多，也管用得多。
别再傻乎乎地去问“哪个最好”了。多去想想它“取决于”什么，你才能真正学到东西，也才能真正把事情办
