为什么现在写代码都不太用链表了？是性能问题还是单纯被放弃了

我懂你这种困惑。做了七年多后端，手写链表次数一只手数得过来，但每次用都很值。
有一次做消息推送系统，用户订阅的频道列表是动态的，频繁增删。用数组的话每次删除都要搬移，流量高峰期 CPU 直接报警。换成双向链表，删除就是改两个指针的事，问题瞬间解决。
我的看法是，链表不是被淘汰了，是它的适用场景本来就窄。大部分人写的业务代码确实用不上。但你要是做基础组件、中间件、游戏引擎这些，链表还是绕不开的。
面试考这个就当是考基本功吧，懂原理不吃亏。真让你在项目里选型，优先数组没错的。

楼上说得对一半。链表确实在缓存局部性上吃亏，但说它"死"了有点绝对。
我做过一个内存数据库的存储引擎，里面有个结构叫跳表，本质上就是多层级链表。为什么不用 B+ 树？因为跳表在并发场景下锁粒度更好控制，写操作不需要像 B+ 树那样做复杂的节点分裂。LevelDB、Redis 的有序集合都用这个。
另外还有个容易被忽略的点，链表在无锁编程里很重要。CAS 操作天然适合在链表节点上做，你试试用数组做无锁队列，ABA 问题能把你折磨死。
所以更准确的说法是：通用业务代码里链表死了，但系统级编程里它还活得挺好。前提是你真的需要那些特性，否则用数组准没错。

楼主这个问题我太有感触了。之前优化一个日志处理模块，老代码里用链表存待处理的任务，跑一次要十几秒。我一开始也以为是算法问题，翻来覆去优化了两天，什么缓存、批量处理全试了，性能就提了百分之十几。后来破罐子破摔，把链表换成动态数组，直接快了三倍。当时就绷不住了，合着这几天白忙活。
核心问题就是缓存命中率。链表节点在内存里东一个西一个，CPU 预取根本猜不到下一个在哪。数组是连续的，预取一抓一个准。现代 CPU 的 L1 缓存访问就几个周期，但内存访问要上百个周期，这个差距太大了。
现在除非是那种极端场景，比如频繁在中间插入删除而且数据量特别大，否则我真想不到用链表的理由。面试考反转链表纯粹是考察指针操作基本功，跟实际用不用是两码事。

姐妹，你这个困惑我太懂了。我去年校招面了十几家，每家必问反转链表，当时我也很迷，写业务代码一年了连一次链表都没用过。
后来问了个在阿里做中间件的大佬，他说了一句点醒我：面试考链表不是考你会不会用，是考你懂不懂内存。数组和链表的选择其实是内存布局的选择，这个思维才是最重要的。
我自己写代码的经验是，比如做优惠券列表展示，数据量就几百条，直接数组遍历随便怎么搞都行。但要是做订单流水那种持续追加的场景，用链表做队列就挺合适，因为不用频繁搬移数据。
别太纠结这个，工作中遇到性能瓶颈再回头想这些就懂了。