为什么现在写代码都默认不用链表了？我 2026 年面试还被问这个心里没底

其实你想反了，链表没死，死的是"裸链表"。
我做嵌入式那会儿，芯片寄存器描述表、内存池的空闲块管理，全是链表。2025 年调一个传感器驱动，那块内存只有 4KB，你让我用 vector？用不了，分配器开销直接爆。
只能说，业务层跟底层是两套逻辑。你写 CRUD 用不上链表，不代表它没了。面试官问这个问题，大概率不是考你会不会用，而是看你知不知道"为什么"。

我懂你这种慌，两年前我也一样。但个反常识的：正经系统里链表用得比你想象的多，只是它们都藏在你看不见的地方。
Linux 内核里的 task_struct 就是链表串起来的，文件系统的 inode 也在链表里。Redis 的 quicklist、streams 底层都有链表参与。你写业务用不上，不代表这门技术废了。
面试被问这个，你就答两点：一是链表在内存管理和内核里的价值还在，二是业务层因为缓存局部性更倾向连续内存结构。能说出这两条，面试官就知道你不是只会调 API 的。

我也亏过，刚入行时跟风骂链表，结果被一个内核题问懵了。
后来翻 Linux 源码，发现 list_head 这个结构无处不在，而且它不存数据，只存指针。你把 list_head 嵌到你自己的结构体里，就能用一套统一 API 操作所有链表。这种设计模式在业务代码里几乎见不到，但底层到处是。
还有无锁队列，MPSC 那种，本质也是链表。多线程场景下，你用数组做无锁队列试试，ABA 问题能折磨死你。
所以我的体会是，业务代码里链表确实退场了，但系统软件里它活得很好。你面试遇到这题，往这个方向答基本不会错。

这事我也想问呢，面试官是不是题库就那几道题啊？
家人们，我 2026 年面了 7 家公司，这题被问 4 次。我现在的标准答案是：链表适合写多读少、元素大小不固定的场景，但现代业务数据基本都在内存里，用连续存储配合索引更香。
我刷了三个月题，最后发现面试官要的不是标准答案，是你有没有真的写过错代码，有没有踩过性能坑。没走过弯路的人，背再多八股也白搭。

2026 年我接手过一个网关项目，老代码里有一段数据转发逻辑，用的就是链表。量起来之后，CPU 跑满，延迟从 2ms 飙到 40ms。
查了三天，问题出在链表节点是 malloc 出来的，高频插入删除导致内存碎片化，cache miss 率接近 80%。后来改成预分配数组加游标，延迟直接掉回 3ms。
那次之后我明白了，链表本身的复杂度没问题，问题是它跟现代 CPU 的缓存机制不对付。你顺序访问数组，硬件帮你预取；你顺着指针跳，每次都是随机访问。

这个其实没那么复杂。链表的问题就一个：它对缓存不友好。
现代 CPU 快得离谱，但内存跟 CPU 之间的差距越来越大。数组是连续内存，遍历起来 cache miss 少；链表节点散落各处，你访问一个节点就要等一次内存。
数据库为什么用 B+ 树不用链表？因为 B+ 树一个节点能装几十上百个 key，一次 I/O 把一整块数据拉进来，链表一次只能拿到一个节点。这个差距在数据量大的时候是数量级的。
所以不是链表错了，是时代变了。单核时代指针跳转是小事，多核加缓存之后，局部性才是王道。

楼上说得对一半。链表没死，但"用链表当主要数据结构"这事儿确实快死了。
我举个具体例子，我司消息队列早期用链表存待处理的消息，单机吞吐 2 万条/s 顶天。后来改成环形缓冲区，同样的机器跑到 15 万条/s。不是程序员技术差了，是 CPU 的预取器根本没法对链表做优化。
还有一点，现在内存便宜了，没人愿意为省那 8 字节指针去写一堆复杂逻辑。数组扩容浪费点内存算什么，时间省下来比什么都值。