老哥你这个标题看得我血压上来了。
链表要是死了，那 RCU（Read-Copy-Update）在内核里还用得那么欢？我搞系统编程的同事天天怼我，说链表是锁并发的暴力解药。比如写一个共享日志队列，用单向链表加原子操作，不用加锁就能做到无锁写入，性能吊打我写的数组那套加锁方案。
当然，你们搞应用层的可能感受不到。我只是想说，它没死，只是从通用场景退到了基础设施层面。你手机里的内核、路由器固件、防火墙判断规则，哪个不用链表？只是轮不到我们这一层去写而已。
而且面试嘛，不还是得刷反转链表？你当面试官图啥，图你那点业务经验？图你会用 ArrayList？不，图你能理解指针跳转那层抽象。这不是过时，是基本功。

这事我也想问呢。
我觉得"链表已死"这个说法有点标题党。真正死的是"人人都应该手动实现链表"这种模式。现在 Java 的 LinkedList、C++的 list，甚至 Go 里的 slice，哪个底层不依赖连续内存和动态数组？但真正的链表数据结构，比如 LRU Cache 的双向链表、Redis 的 ziplist 变种，在特定场景下依然活得不错。
我的实践是：做跨境库存管理模块，需要频繁插入删除过期批次数据，链表写起来比数组省一半代码，性能也能接受。当然，这是百万级以下的数据。上了千万就得换 B+tree。
所以对我来说，不是链表死了，而是我们这代程序员被教育得太抽象了，学数据结构时不理解硬件代价，写业务时不理解场景选择。真要死，是"只会写链表而不考虑性能"的程序员死了。

这个其实没那么复杂。
家人们，链表在现代业务里就跟老式座机一样，能用，但你真不会主动去用。我去年优化一个订单处理模块，原本用链表存待发货队列，结果 CPU 缓存命中率惨不忍睹，一秒才处理 200 条。换成数组加索引，直接飙到 3000 条。真的会谢。
不是数据结构不好，是硬件变太快了。现在内存随机访问快得离谱，而链表那种离散存储、指针跳来跳去，对缓存极度不友好。你插入删除 O(1)有啥用？跑一次要跳几万个地址，还不如数组 O(n)搬数据快。
但你能说它完全死了吗？比如做并发队列操作，一些嵌入式场景，或者你手写一些老系统的核心逻辑，链表还是香的。不过对我这种做电商后台的，反正我是基本不碰了。别问，问就是数组真香。

我也亏过，刚入行那会用 Redis 的 List 做任务队列，逻辑很顺，结果高峰期延迟爆炸。
后来读了几篇论文才发现问题：链表最大的软肋是指针爆炸。现代 CPU 从内存取数据是按缓存行（64 字节）加载，链表节点分散，缓存行频繁失效。而数组是连续存储，预取机制能猜到你下一步要读哪。实际测试，同样 100 万个节点的遍历，数组快 3-8 倍。
但从数据量看，如果你的数据规模小（几百个节点），链表和数组差别不大，用哪个都行。可一旦上了几十万、几百万的规模，链表的内存碎片化和 cache miss 就是真实杀手。
所以我的结论是：链表没死，但活成了小众场景的专属工具。银行交易系统、某些嵌入式实时控制，还是用它。但做跨境这种高并发、大数据量的，你选链表就是给自己挖坑。