为什么有人说"链表已死"？我做跨境 ERP 库存模块时被链表坑惨了，到底该信谁的

你这个"8 秒到 0.6 秒"靠谱吗？我怀疑不全是链表换数组的功劳。
我踩过类似的情况：2024 年优化一个报表接口，从 9 秒压到 1 秒，当时也以为是换了数据结构的功劳，结果回头一查，真正的原因是顺手把 N+1 查询合了、加了缓存。数据结构只贡献了一小部分。
前提是你要把变量控制干净。同一个接口、同样的数据量，只换结构，别的都不动，跑十次取中位数，这才叫数据。
而且"链表已死"这种说法本身就很标题党。很多号称链表慢的 case，其实是内存分配没做池化、节点散落在堆里到处缺页。你换成数组快，可能不是因为数组本身，是因为它连续。
别被结论带着走，先把自己的 profile 看了再说。

楼上说得对一半。你说链表在某些队列场景还留着，这话没问题；但要说"数据量不大就随便用"，我不太同意。
我 2023 年接手过一个老的订单 1688 采集模块，当时觉得才几万个 SKU 无所谓，结果缓存没做好，每次同步都在遍历链表找重复，CPU 直接吃满。业务量翻三倍以后问题才爆出来，那时候改已经很难了，因为到处都在引用那套结构。
我的看法是链表最大的问题是"内存不连续"，CPU 缓存命中率差，就算逻辑上是 O(1) 插入，实际跑起来经常比数组慢。我现在写新模块，除非明确要频繁头尾操作，否则默认用动态数组加索引，省心。
真要我选，链表留给人写不熟练、数据量确定小的地方，别放进核心链路。

我懂你这种慌，我这边的后台一开始也是全链表。去年双十一前一周，订单流水一多，管理后台翻页要转圈十几秒，运营以为断网了，一直打电话问我。
后来找外包的同学看了一眼，说你拿链表去按索引取第几万条，那不是自己找罪受。改成数组加一个哈希索引，同一个页面加载从 12 秒到 1 秒出头。
但你要说链表死了我不完全同意。我们后来做活动秒杀那块的等待队列，还有后台一个频繁往中间插任务的通知队列，用链表反而清爽，因为不挪动元素。前提是你的量到不了百万级，到那个量什么结构都得重新想。
我的体会是：链表没死，是"拿链表当万能结构"这条路死了。国内大部分卖家的 ERP 数据量，其实栽在"随便选了个数据结构"上，不是栽在链表本身。

这个其实没那么复杂，老哥。链表是不是死了，取决于你在它上面干嘛。
我给你个类比：链表像一根绳子串珠子，你手上只有上一颗珠子的位置，想找第 50 颗你得一颗颗摸过去。数组像一排固定座位，报个号就能直接坐下。你说哪种快，看你干的是"插队"还是"点名"。
我们团队做的是库存变动日志，天天要按时间范围查、要按索引翻页，那就是点名场景，链表活该被换掉。但如果是把一个任务插到队列中间，链表的优势是真在的。
别迷信"某结构已死"这种标题，6。先把你的读写比例搞清楚，读多写少基本都轮不到链表。