都2026年了还有人用链表吗？为啥老有人说「链表已死」，真是这样吗

楼上说得对一半。链表在系统层确实活得挺好，但你要放到业务代码里，尤其现在大家写的东西动不动就跨服务、走序列化，那点 O(1) 的插入优势早被网络和 JSON 吃干净了。
我这几年看下来，真正让链表"看起来死了"的，是大部分人的瓶颈根本不在容器选择上。你纠结链表还是数组，结果热点在一个没加索引的查询上，优化半天零点几毫秒，没意义。
长期看，容器这东西会越来越被语言和框架替你决定。你能做的是把数据规模和访问模式摸清楚，别在错的层面上使劲。链表没死，死的是不看场景就下结论的那套说法。

其实你想反了，不是链表死了，是"默认选链表"这个习惯死了。
我写底层断断续续七八年，链表一直有它的位置。真正被淘汰的是教科书那种"插入删除 O(1) 所以更快"的单线程思维。现在讲究数据局部性，讲究预取，讲究一次内存分配搞定。
但有些场景链表还是舒服。比如侵入式链表，节点直接嵌在业务结构里，不用额外分配，内核里到处都是。再比如 LRU 那种要在遍历中频繁摘节点的，链表操作就是比数组挪位顺手。
关键是你得知道代价在哪。我一般会先问一句：这个容器访问频率多高、节点多大、增删集中在哪。答完这三个再决定用谁，比吵"死没死"实在多了。

你这个"被主管当场否了"我得先问一句，那次否之前有没有压测过？没有压测直接判链表死刑，跟你主管信不信玄学没区别。
链表在纯理论层面插入删除 O(1) 是没错，但现代 CPU 上跑起来完全不是那回事。一次指针跳转大概率 cache miss，主存访问上百个周期，你以为的 O(1) 其实藏着一条看不见的常数。数组顺序扫一遍，预取器全给你喂好，反而更快。
所以问题不是"链表死没死"，是"你有没有真的测过"。我见过有人拿链表做小对象池，几万个节点，跑出来和 vector 差不多，因为数据量小到全待在 L2 里，跳转也不痛。也见过链表在大数据量下慢好几倍。
结论别下太早，先上 perf 看 cache miss 率再说。你主管要是连这步都省了，那否的不是链表，是他自己的判断。

这个其实没那么复杂，就看你的数据怎么用。
我之前整理过一个小笔记，同样是存一万条记录，顺序遍历和随机插入分开测。顺序遍历这块 vector 是碾压的，快得离谱。但你要真做频繁的中间插入删除，尤其节点大小不均匀、又不好预估容量的时候，链表反而省心，不用动不动整块搬内存。
宝藏场景其实还在，就是那些"边遍历边删除"的地方，链表写起来干净，不容易踩迭代器失效那种雷。踩雷的是拿链表当默认容器，啥都往里塞。
所以别把它当信仰，当工具。宝子们写代码前先想清楚是读多还是改多，比背口诀有用。

这事我也想问，我们组天天为这个吵。
我就说个实在的，上次压测，链表版本比数组慢了三倍多，一看 perf 全是 cache miss。换回数组立马顺了。
家人们别迷信 O(1)，常数项才是真凶。就这样，我先去改代码了。