2026 年了还在争论链表该不该用，我这几年写业务代码的感受是想用但真不敢用

其实你想反了。不是链表死了，是现在大多数人根本用不上链表擅长的那个场景了。
链表的优势在频繁中间插入删除且不关心随机访问。问题是你现在跑的大多数数据，规模一上来就是几十万上百万条，每遍历一个节点就是一次 cache miss，一次 miss 可能几十到上百个周期。数组顺序访问是连续内存，预取器帮你把后面几块都拉进来了，链表节点散落在堆上，拉不动。
我印象里有个 benchmark 反复被引用，遍历一百万个 int，链表比数组慢十几倍，差的就是这个。所以不是链表算法错了，是硬件变了你没跟上。
真要用链表的场合其实剩下不多，比如内核里那些没法预分配大小的结构、LRU 之类的。业务代码里你写的"链表"，十条里九条换 vector 都更快。

楼上说得对一半。数组确实快，但你别把"遍历快"当成万能答案。
我写业务代码七八年，见过太多人一听链表慢就全换数组，结果插入删除一多，每次搬移内存的开销比 cache miss 还狠。真正该看的是你的读写比例和插入位置：末尾追加、批量读，数组无敌；中间频繁插删、还要稳定引用，链表或者跳表那类结构才有位置。
另外现在很多语言的标准库容器底层早就不是你想的纯链表了，deque、hash 这些混着来。别盯着教科书那棵单链表吵，先把你自己的访问模式摸清楚。
反正我现在写代码默认数组，看到必须频繁中间插删的地方才换，换之前一定先压测。

你这个"换成数组反而更慢"的结论靠谱吗，我怀疑你测的时候插入点是不是都在末尾。
我在厂里做设备上的固件，链表我天天用，但都是那种插入删除没有规律的场景，长度也没法预分配。你要是插入位置随机、量又不大，链表确实还顺手。可一旦数据上到几十万条，遍历的时候 cache 一直不命中，那点插入优势全吐回去。
我们车间那套控制程序，一开始用链表存采样数据，遍历一次慢得受不了，后来改固定大小的环形缓冲，速度立刻不一样了。所以关键不是数据结构本身，是你的访问模式配不配。

这事我也想问，我去年接一个后台项目，翻代码发现前人堆了一堆链表，我还专门去搜"链表是不是过时了"，搜出来的答案能把你气笑。
有个说法挺形象的，说链表就像老式随身听，功能好好的，但你出门都带手机了。我后来实测，同样十万条数据做插入删除，我那个链表实现比数组慢了一截，当时还挺不服气，反复换写法，最后承认就是慢。
不过也别一刀切，我有个做嵌入式的小项目里链表照样好用，因为内存碎、没法大块分配。所以宝子们别被"已死"这词吓到，看你跑的机器和数据规模说话。我自己现在是默认数组，特殊场合才想起链表，踩过的坑就是无脑套模板。

我讲个事。2025 年秋天给一家做日志分析的公司调性能，他们核心去重流程用的是链表，单批五百万条记录跑二十多秒。我上去先没动算法，就是把它那个链表换成连续内存的数组加游标，同样的逻辑，跑下来三秒出头。
他们工程师一脸不信，说自己算过复杂度一样的。复杂度是没变，但内存访问完全是两码事。后来他们追着问为啥，我就一句话，你的 CPU 不喜欢跳着走。这行干久了你会发现，很多"算法没错但就是慢"的活，根子都在内存那层，跟你画在纸上那棵树没关系。