我也亏过，而且亏的挺惨。2024 年接手一个实时日志收集模块，老代码的核心队列是链表，面试官出身的好好先生写的，天天炫耀 O(1) 插入。结果日志吞吐量一上来，CPU 飙到 90%，排查发现 60% 的时间都在等内存分配器从堆里拿新节点，链表每个元素都要动态申请。换成环形缓冲区（固定数组 + 原子操作指针）后，CPU 直接降到 20%。
所以结论很伤人：链表是个好数据结构，但现代编程里你大概率不需要自己手写它。标准库里 vector、deque、list 各有各的槽点，但都比自己撸个链表靠谱。

这个其实没那么复杂，就是"硬件的锅"。
我工作第八年的时候，优化过一个老项目的内存分配器。核心数据结构就是链表，每个节点动态分配、散落在内存各个角落。理论上一查就是 O(1) 时间增删，跑起来奇慢无比。后来换成了 vector（动态数组）+ 空闲索引池，性能直接翻了四倍。为什么？因为现代 CPU 有三级缓存，数组是连续内存，一次缓存行命中就能拉十几个元素进来；链表节点东一个西一个，每次访问都缓存缺失，性能直接崩。
前提是：你处理的数据量要够大、访问要够频繁。链表在小规模或低并发场景下没问题，但在高吞吐、低延迟的中间件和数据库内核里，它就是性能杀手。Redis 6.0 以前还大量用链表做列表底层，后来也被压缩列表 + quicklist 替代了，道理一样。
所以不是链表这玩意儿死了，是硬件变化导致它的适用场景越来越窄了。

楼上说得对一半，但也不能一棍子打死。这事我也想问，大家说的"已死"其实主要针对高性能场景吧？
我 2022 年搞过一个嵌入式项目，单片机 RAM 总共 64KB，用数组预分配内存根本不够，最后就是靠链表做内存池管理，每个节点按需分配、用完释放。这时候链表活的挺好。
所以得看语境：你说的是后端 Java 程序员天天写高并发服务，那链表确实别碰；但你要是搞底层驱动、操作系统内核、或者内存受限的嵌入式设备，链表还是亲爹。
另外 Linux 内核里各种链表宏（list_head）用的飞起，总不能说内核也是"已死"吧。