2026 年了，还有人在用链表做核心数据结构吗？性能优化真的得靠它？

这个其实没那么复杂。姐妹们听我说，我之前在一家做推荐系统的公司实习，里面存用户行为序列，用的就不是传统链表，而是设计了类似链表的分块结构。
当时我也困惑，为什么不直接用数组。带我的师傅说：因为你要频繁在中间插入新行为，数组扩容和搬移成本太高，分块链表是折中方案。
所以链表不是死了，是进化了。裸链表像一块未经雕琢的石头，真正常用的是把它打磨成适合业务的形状。你看到很多所谓"链表已死"的论调，大概率是没见过这些实际应用。
建议楼主去看下 Go 的 container/list 源码，再对比下 slice 的实现，你会对"什么时候用链表"有新的理解。

朋友们，这题我真的会谢。看完标题我以为穿越回 2015 年了，这话题怎么还在吵。
我做业务后端五年，链表这东西就面试和写算法题的时候碰过。平时工作全是数组、哈希表、Redis、MySQL，链表？不存在的。
你要真在业务代码里大用链表，先问问自己是不是被什么"高级感"冲昏头了。代码是给人读的，不是用来炫技的。出问题排查起来，数组比链表好 debug 一百倍。
当然，你要是去面大厂底层岗位，那当我没说，你继续卷。

你这个数据靠谱吗？"链表已死"这种说法从 2018 年就开始传了，到现在还在讨论，本身就说明它没死透。
我 2023 年做游戏服务器的时候，场景里的 AOI 管理就是链表实现，几千个实体同屏，增删频繁，数组根本扛不住频繁的插入删除。换成链表后，单帧耗时降了 30% 左右。
链表的问题是局部性差，但它在高频增删场景下的优势是结构性的，这点数组改不了。关键是你的场景匹配不匹配。
我只能说，教科书上讲的都是理想情况，真到线上还得看数据长什么样。你项目里链表慢，说不定是数据量太小，优化了个寂寞。

前提是，你得先分清楚是"链表的问题"还是"你写的问题"。
我之前优化过一个日志收集模块，里面用链表存待落盘的数据块，插入删除确实 O(1)，但遍历和缓存命中率惨不忍睹。换成连续内存的 deque 后，吞吐量直接涨了 40%。
不过这不代表链表该死。像 Redis 的 quicklist，就是链表和压缩列表的结合体，在内存和性能之间做平衡，照样跑得好好的。
我的看法是：链表作为通用库函数确实退居二线了，但在特定场景下它还是那个最顺手的工具。你项目里那个链表，先看看是不是访问模式有问题，别急着推翻。

我懂你这种慌。当年我接手一个订单处理服务，里面就是个大链表存储待处理任务，当时也以为换数组或者哈希表就完事了。
结果你猜怎么着？瓶颈根本不在数据结构上，是隔壁服务返回数据太慢，我在链表上拼命优化等于白干。最后把超时时间调短，性能直接翻倍。
链表这东西，真到生产环境，除非你是写内核、写高并发中间件那批人，不然碰到的概率很低。大部分业务场景数组够用了。
与其纠结链表死没死，不如先学会用 profiler 看瓶颈在哪。不然你花三天优化链表，别人改个配置就完胜你。

楼主别被那帮知乎大神忽悠了，链表没死，死的是无脑用链表的人。
我大学数据结构课设就是用链表写的学生管理系统，当时觉得牛逼坏了。工作后第一年也总想秀操作，结果被老大骂了一顿，说这年代还写个链表当宝，直接 vector 不香吗。
但你看那些搞 Redis、搞 Linux 内核的，哪个不用链表？只是人家用得精，知道什么时候该用什么时候不该用。说"已死"的都是业务写多了，没碰过底层。
反正你要是遇到性能问题，先怀疑数据量，再怀疑 IO，最后才轮到怀疑数据结构。顺序反了，那你就在原地打转吧。