为什么现在做后端的人越来越不爱用链表了？是我技术太落后了吗

这个其实没那么复杂。链表在现代系统里不是死了，而是被细分到特定领域了。
你做嵌入式、驱动、操作系统的内核开发，链表还是爹。Linux内核的list_head、task_struct结构体里全是链表。但你要写个Web后端或者微服务，用链表就真没必要。
我2019年做个电商订单处理系统，一开始用的链表做订单缓存，后来发现并发锁竞争太严重。改成无锁队列（基于数组的CAS操作），吞吐量翻了3倍。从那以后我就学乖了：能用数组的绝不碰链表。
另外说一句，现在很多新语言比如Rust，标准库里链表都快被边缘化了。Vec（动态数组）才是亲儿子。语言设计者不是傻子。
所以别纠结，按场景选就行。心里没底就多测测，数据会说话。

物流系统里也经常碰到链表。我给大家说个真实的。
2026 年有个跨境大卖客户的WMS（仓库管理系统）模块调优，里面用了链表存SKU库存变更记录。每次盘点都要遍历整张链表查历史，数据量大概50万条，一跑就是几十分钟。后来帮他们改成了按时间分片的数组+索引，查询时间从几十分钟降到几十秒。
链表在物流里最大的坑是：你以为是O(1)插入，实际上每次写操作都要重新分配节点内存，内存碎片一多，GC压力大，系统抖动。物流系统最怕的就是不稳定，一抖订单处理就慢了。
所以现在我做系统方案，能不用链表就不用。当然如果要实现FIFO队列，还是会用LinkedList，但那是JDK自带的，不是我手写的。靠谱还是靠谱的。

楼上说链表慢，我部分同意。链表当年确实很牛，但那是针对单线程、小数据量的场景。
我17年刚入行的时候，接了个游戏排行榜模块的优化。里面用了大量链表存玩家数据，每次排序都是O(n log n)操作，n一上百万，服务器直接炸。后来改成数组+timsort，性能提升了40倍。
你说插入O(1)，那是忽略了你找位置的时间。链表要找到插入点必须遍历，这个开销在数据量稍微大点的时候直接把O(1)变成了O(n)。
而且现代CPU有缓存行预取，数组这种连续内存结构，读一条能带出后面好几条。链表节点散落在堆里，每次访问都是缓存miss，性能差距能差十倍以上。
所以现在工业界用链表，基本就是队列ring buffer这种特化场景，或者做LRU缓存。让链表当主力结构，那是十年前的老黄历了。

姐妹们我跟你们讲，这个坑我真的踩过。毕业第一份工作，写了个消息队列，里面核心用双向链表存消息。
当时觉得可牛了，插入删除O(1)。结果线上压测，吞吐量比同事用数组实现的差了3倍。我老板看了一眼，说"你去看看CPU缓存行是什么"，我查完当场裂开。
链表不是不能用，是得用对地方。比如嵌入式那种内存管得很死、东西又少的场景，链表反而是宝藏（反直觉吧）。但服务器端动不动几百万数据，还是老老实实用数组吧。
我现在写代码，超过100个节点基本就不考虑链表了。除了LRU缓存和某些回调链表，其余都是数组。简洁、快、好debug。

其实你想反了，链表不是"已死"，是"已退"到该在的位置。
我学数据结构的时候老师就说，链表适合频繁插入删除、不关心随机访问的场景。这话到现在都没错。但问题是，咱们实际项目里，那种场景真的很少。大部分时候你都得查、得遍历、得排序，数组+哈希表一把梭就够了。
我面试过好几个"手写链表"的候选人，面的时候吹得天花乱坠。结果进来写第一个API，一个list遍历写了三个for循环嵌套，链表的优势全没用上，人麻了。
我说句实话，你现在的代码如果链表用得很多，八成是设计过度。先把需求理清楚，再看结构该用什么。

这事我也想问呢。面试八股文里链表问得飞起，反转链表、合并有序链表，背得滚瓜烂熟。结果真干活，写了一个链表，被代码review打回来，说"换成ArrayList"。
我后来想明白了，面试是考你数据结构基础，不是考你实际技术选型。就跟问你"TCP三次握手"一样，实际写代码谁手写TCP啊，还不是调库。
链表现在最大的价值是教你指针怎么玩、内存怎么管。真到生产环境，大部分人做CRUD，用链表就是给自己找不痛快。所以"已死"有点夸张，但作为主力数据结构，确实被淘汰了。
你同事说得对，还是换数组吧。我当初也是硬着头皮换的，换完之后真香。