为什么有人说在现代计算机体系中「链表已死」？我做数据模块那年也信了，结果被现实打脸

这个其实没那么复杂。链表死没死，核心就一句话，你数据量小、访问随机性强的时候它还是香的，一旦数据量上去、要顺序遍历，那基本就是被数组按在地上摩擦。
我以前写个订单对账模块，一开始用链表存流水，几千条还行，跑到几十万条的时候卡得我怀疑人生。后来换成数组加索引，遍历速度快了差不多十倍。
所以别听网上说什么"已死"，场景不对而已。链表在 LRU 缓存、频繁中间插入这种地方还活着呢。真要说死，死的是"无脑用链表"这个习惯。
家人们别被标题党吓到。

2026 年我给一个跨境订单系统做性能优化，那套代码用链表存 SKU 库存快照。
单机跑一万个订单要 8 秒，日志里全是 cache miss 的告警。我把核心结构改成结构体数组加哈希索引，同样的逻辑跑到 0.9 秒。
后来复盘发现，问题从来不是"链表"这两个字，而是设计的人默认随机访问也是快的。只要你的主流程是遍历，数组基本都赢。
我们现在内部规范写得很直白，热路径禁用裸链表，除非有明确的 O(1) 中间插入需求。

其实你想反了，不是链表死了，是"链表当主力存储"这个用法该退休了。
现代 CPU 一级缓存就几十 KB，链表每个节点散在堆里，指针一追一个 cache miss，顺序访问的数组一条 cache line 能塞好几个元素。这不是算法复杂度的事，是硬件在惩罚你。
我 2023 年重构过一个日志聚合的东西，链表改跳表加数组，吞吐直接翻了三倍。复杂度没变，就是缓存命中了。
所以判断标准很简单，你是按顺序扫还是随机插。扫就用数组，插得凶再考虑链表或者别的结构。

姐妹们这个问题我也纠结过。之前实习的时候写了个爬虫去重的模块，脑子一热用了链表，结果几十万 URL 去重慢到想哭。
后来导师让我换成哈希表加数组，速度一下就上来了，那一刻我真是又惊喜又羞愧。
所以我的经验就是，面试背复杂度是一回事，真跑起来是另一回事。缓存、内存布局这些课本上不怎么强调的东西，往往才是决定快慢的关键。

老哥这个我也有话说，刚入行那会儿我也觉得链表无敌，插入删除多优雅啊。
后来做任务队列，用链表存待处理任务，跑压测的时候那个 CPU 曲线，我看到都想砸键盘。换了个环形缓冲数组，稳了。
但你要说链表彻底没用，那也不至于。我写过一个内存池的 freelist，就用链表串空闲块，挺顺手的。
所以这东西吧，就像扳手和锤子，你不能因为锤子砸不了螺丝就说锤子死了。6。

楼主我懂你这种慌，我刚学完数据结构那会儿也以为链表是万金油，写啥都想套一个。
直到有次自己写个排行榜，用链表维护，每次刷新都要遍历半天，那感觉就像用筷子喝汤，能喝但很别扭。
现在我的原则很粗暴，除非真的频繁在中间插删，否则默认数组，能省心一大截。
链表没死，只是别拿它当默认选项。绷不住的是那些还在硬吹链表万能的人。

你这个"链表已死"的结论靠谱吗？我倒觉得更像"链表被过度使用了"。
打个比方，链表像是一列火车，每节车厢你得顺着找下一节，前面车厢没了你也过不去。数组像是一条跑道，你想去哪一步跨过去。
前提是，你得知道自己经常要干嘛。老是要顺序扫全表，那火车肯定慢。老是在中间塞车厢，跑道就得整体平移，反而火车赢。
所以别急着下结论，先看看你业务是读多还是写多。拍脑袋换数据结构，比用错还惨。