为什么很多人说链表在现代计算机体系里已死？真的没用了还是只是不适合做核心存储

楼上说得对一半，但我觉得对小业务来说，链表死没死根本不重要。
我做了三年多小公司后端，现在项目里连 std::list 都很少见。前后端分离那套，大部分业务逻辑都在数据库里完成，代码层面就是瞎调 API，你根本碰不到链表还是数组这种选择。数据量撑死几十万条，MySQL 加个索引全搞定。
真正让我意识到这事的是前年优化一个导单功能。原来用的 vector 存订单 ID，后面发现有删除需求，我第一反应是换 list。结果测试一跑，几千条数据，list 反而比 vector 慢。后来才知道 vector 的 erase 在现代 CPU 上因为内存连续，实际开销比想象中小得多。从那以后我就记住了，不是面试题怎么说的，是实测什么结果。
所以我的结论是，链表在教科书里活着，在 LeetCode 里活着，在真实业务里基本是个摆设。你有那个纠结的时间，不如把索引建好。

这个其实没那么复杂，朋友们。
一句话，数组适合读多写少，链表适合写多读少。你非要拿链表去遍历，那不叫链表慢，那叫用错地方。
我做嵌入式开发的，内存就几百 KB，链表天然适合那种碎片化分配的场景。你让我在单片机里开个大数组，那才叫真死。
反正我现在写代码就是一句话，能用数组绝不用链表，但链表永远不会死，它只是退回了它该待的位置。写业务的家人们不用纠结这个，该用啥用啥，别整那些虚的。

我说个具体的吧，之前我们做网关限流组件，需要维护一个按时间戳排序的滑动窗口，每秒要插入几万条请求记录，还要定期淘汰过期数据。
一开始用数组加移动头指针，写入没问题，但过期淘汰要 memmove 整个数组，CPU 占用直接飙到 40%。后来改成环形缓冲，还是数组，但头尾指针自己维护，淘汰就是改个指针的事。性能从 40% 降到 3%。这不算链表，但思路是链表的思路，用数组实现。
反过来，我们日志系统里有个等待重试的队列，节点总数永远不超过 200 个，但每个节点可能被反复取出塞回。这种场景我试过数组，频繁删除中间元素会导致大量数据搬移，反而慢。最后用了个最简单的单向链表，配合内存池预分配节点，效果非常好。
所以我的态度是，链表没有死，它只是从"默认选择"变成了"特定场景的选择"。你得先想清楚你的访问模式是什么，再决定用什么结构。而不是背一个"链表 O(1) 插入删除所以快"的结论就到处用。

其实你想反了，不是链表死了，是链表从来就没活在你以为的那个位置上。
我做数据库存储引擎四年了。你说插入删除 O(1)，理论上是没错，但现代 CPU 从内存读一个节点是一次 cache miss，大概 100 个时钟周期。数组顺序访问是预取器提前加载好的，几乎零成本。你链表遍历 100 个节点的开销，数组遍历 1000 个节点都比它快。
但真说死，LRU 缓存淘汰、Linux 内核的任务队列、文件系统的空闲块管理，全是链表。它们共同点是节点数少、访问模式固定、不需要跨大内存跳跃。
我给你个判断标准：你的数据量在十万以内，选数组；百万以上而且访问是随机性的，考虑 B+ 树或者跳表；链表只适合那种"节点总数永远很小，但插入删除极其频繁"的场景，比如消息队列的等待队列。
业务代码里你用链表写个 LRU 没问题，但你要是拿它存几百万条订单然后做条件筛选，那确实是在跟 CPU 对着干。那话怎么说来着，不是链表死了，是你不会用。