2026 年了，为什么都在说链表已死？真做底层优化的老哥来说说

楼上这问题提得挺准，但"已死"说得太绝对了，在业务 CRUD 里确实没它啥事，但在内核、数据库、网络栈里链表照样活得好好的。
我前两年接了个网关性能优化，里面维护了一堆连接状态，用了链表按超时时间串起来，方便 O(1) 剔除过期连接。当时 QPS 一高 CPU 就飙，用 perf 一抓，发现一半时间都耗在遍历链表找超时节点上，缓存命中率惨不忍睹。
后来我换了思路，直接搞了个最小堆 + 数组池，超时节点从堆顶取，状态存数组里按下标访问。改动不到两百行，P99 延迟直接从 80ms 干到 20ms，CPU 占用降了三分之一。那之后我对链表的看法就变了，它真不是写业务该首选的东西。
不过你要说它"死了"，内核定时器那些地儿还大量用时间轮链表呢。只能说，别指望靠一个链表走天下，真到性能瓶颈的时候，缓存局部性比那 O(1) 香多了。

我懂你这种慌，刷了几天题觉得自己学了个寂寞是吧？没事，我当年也这样。
说个真事儿，我朋友去年搞数据库存储引擎，里面存索引用的跳表，他当时还跟我吹说这玩意儿比 B+ 树牛，O(log n) 插入删除。结果一压测，写入吞吐上不去，一查发现跳表节点全是 malloc 出来的，内存碎片化严重，CPU cache 被各种指针跳来跳去搞麻了。后来他还是默默换回了 B+ 树加个写缓冲。
所以会谢，计算机这行很多理论到工程上根本不是一回事。链表在教科书里无敌，在 CPU 面前就是个弟弟，因为它的内存访问模式太随机了。现代 CPU 快主要是靠缓存，你搞一堆不连续的内存地址，性能直接白给。
你要是写业务代码，压根不用纠结这个。但要是想往中间件、存储、后端架构这块走，还是早点把"数组就是比链表适合大部分场景"这个观念焊在脑子里，能少走很多弯路。家人们，别分心到怀疑人生，先把业务做明白再说。

这事我也想问呢，说链表死的是不是都没写过 Linux 内核？我翻了翻内核源码，里面各种 list_head 满天飞，task_struct 里挂了一堆链表节点，socket 管理、文件系统缓存都离不开链表。
不过话业务层真的没人爱碰链表了，这东西 debug 起来贼痛苦，一个野指针能让你查一整天。我之前调一个内存池的 bug，最后发现就是链表节点没初始化，那个给我恶心的。数组出问题直接崩给你看，链表出问题是神不知鬼不觉地跑飞。
所以链表的 O(1) 插入删除是有代价的，空间开销大不说，对 cache 极度不友好。你要是搞底层驱动、内核模块，那链表还是爹，操作系统的调度、文件系统的目录项缓存全都靠它。但做应用层，用 slice 或者动态数组它不香吗？性能差不了多少，还能少掉点头发。
反正这个命题也就图一乐，真搞技术的不纠结这个，什么顺手用什么，别被这些口号带偏了。