做营销平台选型的时候，我们最后弃用了 Flowable、Activiti、Camunda 这几个现成的流程引擎，自己写了一套。当时团队里有人觉得是重新发明轮子，理由是「业界都这么用」。但做这个决策的过程，恰恰是第一性原理这套思考方法最典型的一次练习。
先把话说清楚。第一性原理不是一句能贴墙上的口号，它是一种把问题拆到没法再拆的底层约束、然后从那里重新往上推的思考方式。亚里士多德最早提出来，后来被马斯克带火。它的核心只有一条，不类比、不跟风，回到问题最基础的 truth 去推理。
这篇文章想讲明白三件事。第一，类比思维和第一性原理到底差在哪。第二，怎么把一个模糊的技术问题拆成物理约束。第三，这套方法什么时候用、什么时候别用，因为它成本很高。
类比思维快，但有天花板
图：类比思维站在别人的答案上、快但有天花板；第一性原理站在问题的约束上、慢但可能突破。两者配合：日常类比提效，关键决策用第一性原理兜底。
日常开发里我们绝大部分时间在用类比。看到秒杀系统，脑子里立刻浮出 Redis 预扣库存 + MQ 异步下单 + 限流这几件套。看到分布式锁，想到 Redisson 或者 Zookeeper。这没毛病，类比能让你在几分钟内拿到一个「够用」的方案，不用每次都从零想。
问题在于，类比给你的永远是「别人怎么做的」，不是「这个问题到底要什么」。一旦你面对的场景和别人的不一样，类比就会把你带偏。我们做营销流程引擎就是个例子。开源流程引擎解决的是审批流、BPM 这类节点数有限、视图简单、流量可控的场景。但营销画布要的是，每个节点都能看到策略转化率，画布上一个策略的执行上下文 JSON 序列化之后能到 20M，C 端流量每天 4000 万人次。把这几个约束摆出来，你会发现现成引擎不是「不好用」，是它的设计假设和我们的物理约束根本对不上。
类比是站在别人的答案上，第一性原理是站在问题本身的约束上。前者快但有天花板，后者慢但可能突破。日常用类比提效，关键决策用第一性原理兜底。
怎么拆，找到物理约束
图：第一性原理最难的一步是区分物理约束（必须遵守）和人为约束（可打破）——绝大多数「做不到」其实是没想过打破人为约束。
第一性原理最难的一步，是区分两种约束。
一种是物理约束。它来自硬件、来自数学、来自系统本身的性质，你绕不开。磁盘是块设备、随机 IO 慢，这是硬件特性。网络可能延迟、丢包、分区，这也是物理事实。内存的访问速度比磁盘快好几个数量级，这也是。这类约束你必须遵守，因为它就长那样。
另一种是人为约束。它来自团队习惯、历史选择、行业惯例，看起来像约束，其实是可以打破的。「我们系统必须用 MySQL」，这是历史选择，换个存储也能存数据。「这块必须走微服务」，这是组织决定，不是物理必然。
第一性原理的要害就在这里，绝大多数「做不到」，其实是没想过打破人为约束。很多看起来理所当然的技术选型，拆到底会发现它依赖的假设早就不成立了，只是没人去拆。
下面用三个最常见的子系统把这套拆法走一遍。
存储，从 IO 推到 B+ 树和 LSM
图：B+ 树和 LSM 树都不是天才灵感，而是从「磁盘是块设备、减少 IO」这一物理约束推出的两条最优解——前者让树变矮减读 IO，后者把随机写变顺序写提写吞吐。
存数据这件事，物理约束只有三条。数据得持久化，掉电不能丢。要能快速读写。容量得能扩展。
真正的瓶颈在第三条和第二条的交叉处。磁盘是块设备，一次读一个块，随机访问一次就是一次寻道加旋转延迟，机械盘是毫秒级，SSD 好一些但还是比内存慢几个数量级。这是你绕不开的物理事实。
从这个约束出发，B+ 树和 LSM 树几乎是必然的推导，不是某个天才的灵感。
B+ 树为什么是胖的、叶子层存数据、非叶子层只存索引。因为一个块能装下越多索引项，树就越矮，磁盘 IO 次数就越少。一个三层的 B+ 树，每层如果是 100 路分支，就能索引一亿条记录，三次 IO 搞定。这不是发明，是从「块设备 + 减少 IO」推出来的最优解。
LSM 树走的是另一条路。既然随机写慢、顺序写快（这同样是磁盘的物理特性），那就把所有写都变成追加写，先写内存的 MemTable，攒够了顺序刷到磁盘的 SSTable，读取的时候在多层 SSTable 里合并。写放大和读放大是它付出的代价，但换来的是写入吞吐量的本质提升。
「这张表必须用 InnoDB」是惯性，不是约束。如果你的场景是海量写入、读多写少还能接受最终一致，LSM 类的存储可能更合适。很多团队一辈子只泡在 MySQL 里，慢慢就把「习惯」当成了「物理规律」。
理解了这些，回过头看业务里那些存储选型就清楚多了。为什么 Kafka 把消息追加写到底，因为顺序写的吞吐量是随机写的几十倍。为什么 HBase 适合蜂控平台那种 TB 级发票宽表的查询，因为它底层是 LSM，写入快、靠 Rowkey 范围扫描高效。当年我们查 TB 级发票数据，就是用 ES 做辅助索引先拿到 Rowkey，再回 HBase 大宽表取明细。这套「索引和存储分离」的设计，拆到底也是从磁盘 IO 的物理约束推出来的。
缓存，从局部性推到淘汰策略
缓存的物理约束更直观。内存访问速度远超磁盘，这是第一条。热点数据被反复访问，访问有局部性，这是第二条。
有了这两条，缓存的所有设计都能推出来。热点数据放内存，能挡住大部分请求。既然内存放不下全量数据，就得有淘汰策略保住热点。于是 LRU 淘汰最久没用的，LFU 淘汰访问最少的，本质都是在用有限内存最大化命中率。
但这里有个反直觉的点，命中率才是缓存的北极星指标，不是缓存大小。我经手过人群底座优化，一开始缓存粒度是按接口维度放的，命中率只有 40%。后来把粒度细化到单个的人群 ID 维度，再叠一层 Caffeine 二级缓存、监听 binlog 旁路异步刷新（接受分钟级延迟），命中率直接拉到 99%，人群服务 RT 从 45ms 降到 30ms，上游策略服务从 1300 QPS 扛到 2800 QPS。
整个过程没有一行代码是「别人怎么做的」，全是顺着两个物理约束往下推。内存有限，所以粒度要贴近访问模式；局部性存在，所以预编译和异步刷新能让热点常驻。理解了约束，方案自然浮现，这就是第一性原理的力量。
缓存最容易翻车的地方不是命中率，是写。先写库还是先写缓存、缓存挂了怎么办、并发写怎么保证不读到脏数据，这些没有银弹。我们当时的取舍是接受分钟级延迟换吞吐量，前提是业务允许。你的业务允不允许，得自己判断。
分布式，从不可靠推到 CAP 和共识
分布式的物理约束最硬，也最容易让人痛苦。网络不可靠，可能延迟、丢包、分区。节点可能故障，宕机、重启、时钟漂移。
这两条是 CAP 定理、Paxos、Raft、最终一致性所有分布式理论的共同起点。因为网络可能分区，所以在一致性和可用性之间必须有取舍，这就是 CAP。因为消息可能丢，所以不能假设它一定到达，必须有确认、重试、幂等。因为节点可能挂，所以多副本之间必须有共识算法保证大多数节点同意了才算数。
理解了这一点，分布式系统的很多「反直觉」设计就有了根基。为什么 2PC 这么慢，因为它要在网络可能分区的世界里强行保证强一致，代价是阻塞和协调者单点。为什么 Saga 和本地消息表更常用，因为它接受了网络不可靠这个前提，用补偿和重试换可用性。为什么幂等是分布式系统的一等公民，因为重试是常态，不幂等就会重复扣款、重复发货。
回看前面那个弃用开源流程引擎的决策，走的是同样的拆法。把「业界都这么用」这条人为约束剥掉，回到营销画布的真实物理约束，超大执行上下文、节点级可观测、C 端高流量，结论就变成了自研。这不是为了深刻而深刻，是约束推到那了。
别对每个件事都用
第一性原理的思考成本很高，不是所有问题都值得。
值得深思考的，关键技术决策、架构选型、核心数据结构设计、一致性方案。这些一旦定下来改动成本极高，值得花时间拆到底。我们花在流程引擎选型上的论证时间，换来了后面两年几乎不用动核心架构，这笔账划算。
不值得的，日常小决策。用哪个工具函数、变量怎么命名、用 ArrayList 还是 LinkedList、要不要抽个工具类。这些用类比、用经验、用团队约定就够，强行第一性原理是浪费时间，还容易把自己绕进去。
一个简单的判断标准，这个决策的「反向成本」有多高。改个函数名五分钟的事，类比。定个存储方案、定个一致性级别、定个限流策略，改动要牵连一堆上下游的，第一性原理。
经验和第一性原理，不是二选一
纯靠经验容易盲从。看到别人都用 Redis 做分布式锁就跟着用，不去想 Redlock 在网络分区下的争议，不去想自己的场景到底需要多强的一致性。纯靠第一性原理又太慢，什么都从头推，一天干不了几件事。
最好的配合是，经验给你候选方案，第一性原理帮你验证这些候选方案到底符不符合你真实的物理约束。候选方案越多，你推得越快，因为大部分时候你是在做排除法而不是发明。这也是为什么平时要多看别人的方案、多拆解成熟系统，不是为了照抄，是为了在需要第一性原理的时候，脑子里有足够的素材。
培养这套思维
落到日常，有几件事能帮上忙。
多问为什么，经典的是 5Why 法，连续问五层为什么，往往能逼到物理约束那一层。一个请求慢，为什么，SQL 慢。为什么，全表扫描。为什么，没建索引。为什么，查询条件没用上索引。为什么，条件列上加了函数。问到这，根因和方案都清楚了。
学基础原理。操作系统、计算机网络、数据结构与算法、数据库原理，这些是物理约束的来源。不学这些，你的「第一性原理」就是无源之水，拆到一半就拆不动了。这也是为什么很多八股看起来散，其实一脉相承。聊 Redis 能聊到 IO 多路复用，聊多路复用能聊到操作系统的 epoll，聊 epoll 能聊到事件驱动，聊着聊着就到了 Netty、到了 GC、到了数据库索引。底层原理是连通的，这是第一性原理能成立的地基。
拆解成熟方案，理解它为什么这么设计，而不只是记住它这么用。挑战惯例，碰到「必须这样」的时候多问一句，是物理上必须，还是只是大家都这么做。
第一性原理的价值，说到底是四个字，知其所以然。深度理解，让你能迁移、能突破、能避坑。它不保证你比别人快，但它能让你在关键决策上不犯方向性错误。对于一个把系统拆到底的工程师来说，这就够了。
