为什么老程序员都说现代计算机体系里链表已经没用了？真的假的

这事我也想问来着，每次面别人问到链表和数组，候选人都背"链表插入 O(1)"，我就想笑。先抛个观点：你连缓存行多大都没概念的时候，讨论链表复杂度就是在空中盖楼。前提是，你得知道 L1 缓存访问延迟大概 1ns，主存是 80ns，差两个数量级。链表遍历等于随机散步，每次跳一个地址都可能在主存里翻车，数组是顺着管道跑，差距就这么来的。
我 2024 年碰过一个案例，检索服务里有一段日志解析逻辑，原本 linked_list 存待处理 token，压测 3000 QPS 就抖动。改成 deque 之后 9000 QPS 稳如老狗，代码只改了三行声明。当时小伙伴都绷不住，说人比人得死，数据结构比数据结构得扔。
不过你要说链表完全死透我不认。内核里那些需要频繁从中间摘节点、且节点生命周期差异巨大的场景，链表依然是最直观的表达。只是你我这种写业务 CRUD 的，碰不到那种场景罢了。讲白了，不是链表死了，是它退出了应用层开发者的日常工具箱。

这话题我熟，但懒得搬运教科书。直接说，数组是连续内存，CPU 看它像看连续的电影帧一样顺畅；链表是跳着看的，每跳一次可能卡一下。现代 CPU 缓存就是为顺序访问优化的，你拿链表去喂它，好比拿筷子喝汤，不是不能喝，是蠢。
我之前做交易系统撮合引擎，订单队列用链表维护。高峰期每秒十万笔，链表版本 GC 压力大而且 cache miss 严重。同事改成 ring buffer 大小 65536，直接复用固定内存，性能翻了四倍。从此我们组立规矩，新代码谁敢写裸链表谁请下午茶。
但话别说死，你要是节点数量只有几十个，链表优势在某些场景还在。比如你频繁在头部插入、尾部删除，且节点还是从内存池里分配的固定大块，那链表依然能打。不过这种细节优化，普通业务代码根本遇不到。记住一条，2026 年了，无脑数组走起，链表留给写内核的老哥去爱吧。

我也算半个过来人，刚毕业那会特别迷信教科书，觉得链表是神。后来看组里大佬优化一个实时风控模块，原来用链表存黑名单 IP，每次查询都要从头遍历，贼慢。大佬换成排序数组加二分查找，查询快了十倍不止。当时我就觉得，书本和现实之间隔着一整个 CPU 架构课。
所以姐妹们，如果你还在纠结是不是链表不够优雅，先别急着调代码，去了解一下你们的数据量级和访问模式。数据量小到几百条，链表和数组性能几乎没差。数据量一旦上万，数组加二分或者哈希表基本上屌打链表。虽然有点残酷，但现代体系就是偏爱"空间连续"的选手。
我自己后来写代码的原则很简单，能用顺序存储就坚决不用链式存储。真到了需要链表的场景，先问自己三个问题：节点平均多大？增删频率多高？能不能用内存池？答不上来就别碰。反正我身边混得好的工程师，基本都不怎么聊链表了，都在聊 cache locality 和分支预测。

楼主你说的"教科书说链表牛逼"这个前提，在 2026 年的服务器场景下基本不成立了。我 2023 年调过一个推荐系统召回模块，里面用了大量链表存用户行为序列。当时 QPS 一上来就 CPU 飙满，perf 一看，一半时间耗在 cache miss 等待上。
链表每个节点散落在堆里，CPU 预取器根本猜不到下一个地址，只能傻等内存。你把同样的逻辑改成 vector，哪怕插入删除了 O(n)，实际跑起来反而快三倍。因为内存连续，prefetch 全命中。
但"死"这个字太绝对。Redis 的 quicklist、Linux 内核里大量链表还在用，它们场景是"节点本身很大"或者"需要常驻内存且更新频繁"。你要是写业务代码，从 2026 年回头看，用链表确实欠考虑。除非你能证明你的数据规模小到 cache miss 可以忽略，或者节点对象大到拷贝成本远超链表遍历开销。
反正我这两年 code review 见到链表直接打回，让改成 vector 或者 absl::flat_hash_map。也不是说绝对不行，你得先说服我你的场景真的需要 O(1) 插入且不需要随机访问，并且数据量小到 cache 能兜住。满足这三条我再考虑放你过。