为什么都说现代计算机体系里「链表已死」？写业务代码真的用不到吗

你这个"顺手"的结论是怎么得出来的？有 benchmark 数据支撑吗？我见过太多人拿链表当万能药，结果 O(1) 插入删除只是理论值，实际还要算上找节点的 O(n) 遍历。
我给你算笔账：现代 CPU 从 L1 缓存读数据只要 1ns，从主存读要 100ns 以上。链表节点在内存里是离散的，每次访问大概率都要走主存，一次遍历 1000 个节点就是 100 微秒起步。同样是 1000 个元素的数组，顺序访问几乎全命中缓存，10 微秒内搞定。
差距就是 10 倍。这还是中等规模的场景，数据量越大差距越明显。
链表的真正价值在于大节点搬迁成本高的场景，比如内核的任务队列、虚拟内存管理。应用层业务系统里能用数组和切片解决的事，真没必要拿链表硬凑。你确认你的场景真的需要频繁在中间插入吗？如果是，那也该考虑跳表或者 B+ 树，而不是链表。

我也亏过。2024 年给海外仓的库存系统做重构，图省事用链表存 SKU 变更记录，结果高峰期并发一上来，CPU 直接跑满，排查了三天才发现是链表遍历导致的。
从那之后我就给自己定了个规矩：业务代码里凡是能预估最大长度的，一律用数组；实在没法预估的，用切片动态扩容都比链表靠谱。
不过话链表在嵌入式领域活得挺好的，我朋友做物联网网关，跑的是 FreeRTOS，里面任务控制块还是链表。只是咱们这些写云服务的人，碰到的场景确实不太需要它了。反正我现在面试应届生，问链表都是看基础，实际工作里真没几个人写。

楼上说得对一半，链表在业务代码里确实没死，但你要是去优化热点代码，它真的是头号嫌疑人。
我去年接手一个订单聚合服务，每天要处理几十万条流水，用链表存中间结果。本地测试挺好，一到压测就拉胯，延迟从 20ms 飙到 300ms。后来换成切片数组，预分配内存，性能直接回来。原因就是链表节点在堆上乱飞，CPU 缓存命中率低得可怜，每次遍历都在等内存。
但话业务代码里链表的"方便"是给程序员看的，不是给 CPU 看的。你要是写 LRU、写内存池、写文件系统的空闲块管理，那链表还是宝藏数据结构，根本死不了。
所以"链表已死"这个说法，更准确点说是"热点路径上的链表已死"。普通 CRUD 工程师感知不强，但做到底层优化的人天天跟这玩意儿搏斗。反正我现在写代码默认数组，链表只出现在注释里。