为什么有人说现代计算机体系里「链表已死」？我做跨境订单系统时也踩过这个坑

这事我也想问，我现在做的订单后台也是链表，看着简单，但我不敢动。
反正能跑就行，哪天慢了再说吧。

楼上说得对一半。
链表慢不只是"找节点"那一下，还有内存这块。链表每个节点是散着 new 出来的，地址不连续，CPU 缓存基本帮不上忙，每次跳指针都是一次 cache miss。你数据量小无所谓，上到百万级，光这个就够你喝一壶。
但说"已死"我觉得夸张了。链表在有些地方还是最优解，比如你要频繁在中间插删、又已经持有节点引用、还不想整体搬移数据，数组反而更亏。
所以不是死了，是大部分写业务的人，用错了场景。

我朋友去年接了个活,给一个做 ERP 的公司改性能,那套系统也是全程链表存订单明细，一张单子几百行明细。
他去 profile 了一下,发现 70% 的时间花在遍历找节点上,不是插删本身。改成用数组加索引之后,同样那批数据从 8 秒降到 0.9 秒。他跟我说那两天他就干了一件事：把"我以为是 O(1) 就快"这个念头扔掉。
我倒不觉得链表死了,我觉得是很多人对复杂度的理解停在课本上。课本讲 Big-O 是不管常数项的,但真实机器里那个常数项（缓存、分支预测、内存局部性）有时候比阶数还重要。你说一个链表遍历,和一个数组遍历,都是 O(n),跑起来能差个五到十倍。
前提是你真的在关心性能。如果你那套系统一天就跑几十条数据,那随便你链表还是数组,谁维护起来顺手用谁。

我一开始也不太信这个说法，直到自己动手改了一次我们发货系统的库存扣减逻辑。
当时那套代码用链表存库存，我看着挺对，插一个删一个都是 O(1)。结果双十一那天并发一上来，系统直接卡成 PPT。后来找我们后端小哥看，他说问题不在插删快不快，在于你要找到"那一条"库存记录之前，得从头一个个爬。
这就是关键。链表插入删除是 O(1)，但你想插到第 5000 个位置之前，你得先走 5000 步。你平时数据量小看不出，一上量，这个爬的过程就吃掉你所有性能。数组虽然插入要挪数据，但人家能二分、能预取、CPU 缓存命中率高得不是一点半点，这两笔账根本不是一个量级。
所以我理解"链表已死"不是说它不能用，是说在现在这种内存便宜、CPU 缓存金贵的环境里，大多数场景数组或者哈希表都比它划算。链表真正还活着的场景，基本就是那些"拿到了节点指针、只做局部插删、压根不需要随机访问"的地方，比如 LRU 淘汰、内核里那些调度队列。你要是在业务代码里靠遍历去找节点，那就是拿链表当数组用，属于自找的。