都2026年了还有人说链表已死，我做了几年后端想问问这说法到底靠不靠谱

我懂你这种慌，被新人当面质疑确实不好受。
这事其实没那么玄。你把计算机想成一栋楼，CPU 是住在高层的人，内存是楼下的仓库。数组相当于你把一整箱货一次性搬上来，叉车一铲就走。链表呢，每件货都单独放在楼里不同角落，你得一趟一趟跑，每次开门关门都是成本。数据结构教科书教的是"跑几趟"，现代 CPU 关心的是"开门关门多少次"。这就是全部的差别。
前提是数据量到了一定规模。几百个节点，链表数组根本没差，别被那些 benchmark 吓到。上了几万几十万，链表的劣势才露出来。
我一直觉得"链表已死"是句偷懒的话。它想说的是"别拿链表当默认选择"，这我完全同意。但说它死了，就像说螺丝刀过时了因为现在有电钻，问题是有些活儿电钻就是干不了。

楼上说得对一半吧。链表"已死"这话太绝对，准确说是"通用场景下被淘汰了"，不是死了。
我去年重构一个订单队列的模块，原来用的是双向链表，跑一批几万条数据要十几秒。换成数组 + 预分配之后，同样的逻辑掉到两秒出头。差异全在缓存命中率上，不是算法复杂度的问题。链表每次跳节点基本都是一次 cache miss，节点散在堆里，CPU 预取根本帮不上忙。数组是连续的，一轮读下来几乎全在 L1/L2 里。
但你说链表彻底没用也不对。我现在的做法是：频繁在中间插入删除、而且数据量不大、又不需要顺序遍历的场景，还是链表省事。比如 LRU 缓存那种要在中间挪节点的，用哈希表挂双向链表依然是最干净的实现，硬改成数组反而代码绕。
核心就一句：现代机器上内存访问比指令本身贵得多，链表输在这一点上，不是输在理论上。真要用，先量一下再说，别拍脑袋。

这事我也想问。前阵子面试被问链表和数组区别，我按八股答了一通，面试官反手一句"那你觉得链表还有存在必要吗"，我当场卡壳。
6，现在这年头背八股都不好使了。我自己的感受是，链表在业务代码里确实越来越少见了，但你去翻内核源码、翻 Redis、翻各种高性能中间件，链表该在的地方还在。说明它不是没用，是轮不到普通业务层用它。上层业务对性能没那么敏感，图省事直接上动态数组就完事了。
所以老哥，你那个老模块只要没成为瓶颈，用链表撑着我一点不觉得丢人。真跑不动了再换，别为了政治正确去重构，重构出 bug 算谁的。

其实你想反了。不是"链表已死"，是"大多数人对链表的预期该更新了"。
我以前也觉得 O(1) 插入删除就是快，直到有次给一个商品 SKU 关联表做优化，节点数量到了几十万，遍历一遍慢得离谱。后来才明白，理论上的 O(1) 只是在数操作次数，没说每次操作多贵。链表每次跳指针几乎都是一次缓存未命中，次数少了不代表总时间短。
现在我的判断很简单：数据小、改动频繁，链表还是宝藏级选择，代码写起来干净。数据大、以遍历为主，老老实实上数组或者更紧凑的结构，别踩这个雷。中间那些拿不准的，测一下，五分钟的事。
反正我的结论是，工具没死，死的是"一把锤子敲所有钉子"的习惯。