为什么有人说在现代计算机体系中「链表已死」？做跨境数据处理的来说两句

你这个结论下得早了一点吧？你确定是链表的锅，不是别的地方在拖？
我之前也这么以为过。有次发现同步慢，第一反应就是砍链表，改完数组就快了 2 秒，结果后来才发现真凶是序列化那段在反复开 JSON 对象，跟数据结构半毛钱关系没有。链表顶多背了三成锅。
姐妹们真别一看到链表就换，先 profile 一下。拿火焰图看时间花在哪，比凭感觉改结构靠谱多了。有时候你把链表换成数组，缓存是好了，但插入一多又开始 memmove，白折腾。
真正该换的场景是：大数组 + 频繁顺序遍历 + 只读或极少改。反过来，频繁在中间插删、对象大小不定、得靠引用共享节点的，链表还是宝藏。
先量再改，别学我瞎优化两天提升 15%。

这个其实没那么复杂，就是缓存不友好。
链表每个节点都是单独 malloc 出来的，内存里东一块西一块。CPU 读的时候 cache line 一次拉 64 字节，结果你下一个节点在另一页，cache 全是 miss。数组是连续内存，预取器一拉一整段，速度差好几倍。
我之前做订单明细聚合，也是链表，百万条跑 14 秒。改成数组 + 索引之后 1.8 秒，跟你这个比例差不多。不是算法复杂度的问题，是常数项被 cache miss 拖死了。
链表没死，但它的主战场早就不在"遍历"上了。LRU、内存池、内核里的 task list、图的邻接表，这些地方还得用它，因为要 O(1) 摘除节点。你要是只做顺序扫，那确实用数组就完了。
所以问题不在链表，在于你拿它干了不适合它的活。

我懂你这种慌，我也是被这个东西教育过的。
你可以把内存想成一条走廊，数组是大家排好队站着，CPU 走过来顺手全带走。链表是你把每个人丢在不同的楼层，还得靠每个人手里一张纸条告诉你下一个人在哪。CPU 每找一个都得重新坐电梯。纸条本身没错，是你让它跑腿跑太多了。
前提是数据量得够大，十万以内链表其实也能忍，你就是感觉不出来。一旦上百万，cache miss 的代价就指数级放大。
我 2023 年重构过一个库存对账脚本，当时也是链表硬扛，跑批要半小时。后来改成块状预分配（不是纯数组，是分块链表），既保留了插删的灵活性，又让每块内存连续，跑批直接进 3 分钟。
所以"链表已死"这话太绝对，准确说法是"指针满天飞的链表在热路径上死了"，分块、跳表、无锁队列里它活得好好的。