最近在 CSDN 看帖子，好几个老哥说链表在现代 CPU 缓存结构下优势全无，甚至连 Redis 都在新版本里改成了 listpack。我自己写代码一直是链表党，插入删除 O(1) 多香啊，真被淘汰了？想听听过来人的实际经验。
3 Answers
这事我也想问，但后来看了一篇 Linux 内核的讨论帖就明白了。内核里链表活得好好的，反而数组在某些场景被嫌弃。因为内核里节点的增删频率远高于遍历，而且很多地方需要在一个结构体里挂多个链表，这玩意数组根本替代不了。
我说的不是理论，是实际看过的代码。Linux 的 list_head 到现在还是核心数据结构，驱动、网络协议栈全在用。如果"链表已死"，那内核早就重构了。
但楼主如果你问的是应用层，那确实不太一样。用户态程序里 Cache Miss 的代价太明显，遍历链表就是一个一个跳，CPU 预取直接失效。我 2025 年优化过一个推荐系统的特征工程，把链表换成 vector，耗时降了 40%。数据量几千条的时候，数组优势确实碾压。
所以"死没死"取决于你站在哪一层。底层内核里活蹦乱跳，应用层性能敏感的地方确实边缘化了。
楼主你这个"链表党"三个字一出来我就绷不住了。你说的缓存结构问题是真的，但不是"链表没用"，是"你没在合适的场景用链表"。
我举个例子，去年我优化一个消息队列的中间层，核心逻辑就是频繁在中间插入删除，链表跑得飞快。换成数组？插入一个元素后面全部要搬，直接卡死。反过来，如果是遍历为主的操作，比如批量扫描日志，那数组配合 CPU 预取，性能能甩链表几条街。
说到底还是看你的操作模式。插入删除多就链表，遍历多就数组。别听风就是雨，那些说"链表已死"的，八成是面试造火箭、工作拧螺丝的货。
不过有一点楼上没说错，2026 年了还在无脑用链表确实该反思，至少该想想你的数据规模能不能被缓存装下。
老哥，说句糙理不糙的话，链表死不死，得看你在哪写代码。
我面试的时候最爱问这个，不是考八股，是想看对方有没有真的被缓存教育过。2023 年我做一个网关的限流模块，用链表存滑动窗口的请求记录，压测到 10 万 QPS 直接抖成筛子。换成环形数组后，稳如老狗。那次之后我再也不嘴硬了。
但你要说链表完全没用，我第一个不服。Redis 7.0 之前 quicklist 就是链表和 ziplist 的混合体，删改频繁的场景它还是香。只是现在内存贵、Cache 更贵，大部分业务场景用数组加索引就够，没必要拿链表去炫技。
反正我现在的态度是：默认数组，特殊场景才考虑链表。别跟缓存过不去。
