2026年了为什么老码农说链表已死？我看算法书不都还是重点吗

这个其实没那么复杂：看你在哪一层干活。
我做嵌入式底层，链表用得还是多的。FreeRTOS的任务控制块链表、协议栈的报文队列，这些地方不可能用数组，你不知道任务数上限，动态分配就必须用链表。但我们也不会裸用，都做了节点池预分配，避免频繁malloc/free。
你要是写云服务、后端高并发、数据库引擎，那链表确实不该出现，连续内存访问才是王道。
所以不是链表死没死，是你站哪个山头。

我也亏过，去年有个小项目，图省事用链表存用户浏览历史，就几千条数据。结果用户一多，后退操作要遍历整个列表才能找到上一条记录，卡得要命。后来换了slice+map，代码更简单，速度还快了。
链表这东西，写写算法题还行，真上线就是给自己挖坑。反正我以后不碰了。

你这个数据我怀疑是看的古董教材。链表面试还是考，但工程里真用的少了。
我2019年接手过一个订单路由模块，里面链表套链表，查一个订单状态要O(n)遍历，结果每秒并发上200就扛不住了。我换成连续数组+哈希索引，同样硬件QPS直接翻三倍。后来我看那老代码，设计的人可能是2008年那批，那时候内存小，觉得链表省空间。现在2026年，L1/L2缓存都多大你算过吗？
面试归面试，真业务谁敢用链表做核心数据流？除非是写JVM底层或者操作系统的，但那种活儿普通人碰不到。

楼上说得对一半。说"链表已死"太绝对，说"工程里别用"也不全对。
我举个楼主的例子：楼主你现在学链表，面试要考的，那些手撕反转链表、合并链表、LRU缓存，哪个不是链表？面试官要看你指针操作和数据结构理解。但是面试过了你进组，leader大概率不会让你在核心路径上写链表，最多让你写个环形缓冲区或者任务队列，那底层还是数组。
绷不住的是，现在有些培训班的老师还教"链表插入删除O(1)比数组快"，这理论没错，但实际一跑，数组预分配后用memmove批量移动，比你一个个改指针快多了。2026年的CPU早就不吃这套了。

这事我也想问：既然链表面试还考，那到底有没人敢在代码评审里说"我这个地方用了链表"？
反正我身边，包括我自己，2020年之后没人敢在新项目里加链表了。旧代码里留下的链表，谁敢重构谁背锅。所以它"活着"，但是半死不活，像过期药一样，吃着没用，扔了怕万一。
说句不好听的，2026年了你用链表，别人看你的眼神就像你在用C++98写代码一样。

其实你想反了。链表没死，是"纯链表"死了。
2026年还在大规模用链表的场景：Linux内核的链表、Redis的quicklist、一些嵌入式RTOS。但这些都不是纯链表，都做了数组化或预分配池化处理。比如Redis list底层用quicklist，本质是双向链表节点里挂ziplist数组，就是混合结构。
你写业务代码还敢裸用链表做主存储？那性能监控图一拉，CPU缓存miss率绝对让你破防。所以不是链表这东西不能用，是"教科书里那种每次malloc一个节点"的用法，在2026年属于老古董了。
我刚毕业那会儿也写了个链表实现LRU缓存，上线第一个月就挂了两次，纯属自找的。

我去年帮一个客户做支付系统审计，他那边有个转账路由表用了链表。
一查，每笔转账要遍历上百个节点，延迟动不动300ms。后来我们改成数组+二分查找，延迟降到15ms。客户的运维老哥说这段代码是2015年一个外包写的，后来没人敢碰。
链表在这个场景里没死，但"死在代码仓库里"了，没人维护，没人理解，没人愿优化。合规审计时我们直接建议重写整个模块。如果链表是你的核心结构，建议你立刻评估下是不是该换了，不然哪天暴雷，排查成本比重写还高。

我懂你的疑惑，毕竟刚学数据结构时链表确实精妙。但现实是，2026年的Java工程师，你写个LinkedList去存几万条数据做遍历，那性能比ArrayList差一个数量级。
打个比方：链表就像手动挡的跑车，结构炫酷，操控感强，但日常通勤你开自动挡电车更省心。面试考手动挡是为了看你会不会开车，不是让你拿它去跑滴滴。
我2017年一个同事，死活要用链表做实时排名榜，代码写了两周，上线第一天就OOM。后来换成跳表+数组，三天搞定。这事让我彻底明白，纸上结构和工程结构是两码事。