做跨境数据中台这几年，为什么老程序员都在说「链表已死」？真有这么夸张吗

你这个数据靠谱吗，几百万条记录用链表，这种题不该拿链表做啊。
我这边也是做跨境数据的，订单量差不多，早就全用数组加索引了。链表你放几百万条进去，光指针占的内存就够呛，更别说遍历。
数据量小、频繁在中间插入删除、又不怎么遍历，链表还能用；数据量一大、要顺序扫、要缓存友好，链表的优势全没了。
现在让我从头写我也未必写得好，反正能用数组就别用链表，真的会谢。就这样吧。

我懂你这种慌，刚接手那种祖传代码的时候我也崩溃过。
之前我们有个库存同步的模块，就是用链表做任务池，跑起来那个慢啊，一晚上同步不完。后来换成了 Go 的 slice，加上批量处理，直接从 8 小时缩到 40 分钟。当时真的有种「原来是这么回事」的感觉。
不过我现在觉得，链表已经死了这个说法有点标题党。应该说它在高吞吐的现代后端场景里被边缘化了，但你在一些特定领域还是能看到它，比如某些语言的标准库、操作系统的内核里，链表照样活得好好的。
所以别焦虑，工具没有绝对的好坏，关键是你知道它什么时候该用、什么时候该换。宝子们写代码的时候多想一步内存布局，能省不少返工。

这个其实没那么复杂，就是硬件发展把天平压翻了。
二三十年前内存和 CPU 速度差距没那么大，算法复杂度确实能决定一切。现在 CPU 主频上去了，但内存延迟几乎没怎么降，一次 cache miss 顶几百个时钟周期。链表那种指针跳来跳去的访问模式，每一次跳几乎都是 miss，性能自然拉胯。
但你要是做长期维护的系统，我的看法是别只盯着数据结构。真正决定一个系统能不能活五年的，是它有没有清晰的边界、好不好替换组件。链表今天不行了，你换成数组，明天又有别的东西不行了，难道每次都推倒重来？
选型的时候留个替换的口子，比纠结用链表还是数组重要多了。

其实你想反了，链表的 O(1) 从来都是理论上的。
插入删除 O(1) 的前提是你已经拿到那个节点了，问题是你要先找到它，这一步就是 O(n)。真正省时间的是在已知位置的操作，实际业务里有多少场景是「已知那个节点位置」的？大部分还得先遍历一遍。
更别说现代语言那些 LinkedList 实现，每次插入还要 new 一个节点，分配内存、维护指针，开销比你想的大得多。我做过一次对比测试，同样往尾部追加十万条数据，ArrayList 比 LinkedList 快了三倍不止。教科书上的大 O 分析，忽略了常数因子和内存层级，拿来做工程决策就是个坑。

这事我也想问，去年我还在一个跨境 ERP 项目里被这个坑过。
我那会儿要做订单去重，几万条记录，图省事用了 LinkedList 存中间结果。跑一次批处理要 40 多秒，我以为是接口慢，查了半天发现是遍历链表的时候 CPU cache miss 太严重。改成 ArrayList 之后直接掉到 6 秒。
原因其实不复杂，链表每个节点在内存里是散着的，CPU 每次取下一个节点都得去主存捞，而数组是连续的，一次拉一整个 cache line 进来。现代 CPU 快，但内存访问慢啊，你 O(1) 的插入再快，也顶不住遍历的时候一路 cache miss。
所以现在大家做高吞吐的场景，宁可开个数组频繁扩容，也不碰链表。当然也不是完全没用了，写个简单的 LRU、或者数据量小得可怜的地方，链表还是能用的，别一棍子打死。

楼主你这个应届生的情况太经典了。
我之前接过一个活，客户那边用链表做消息队列，日订单量才三万就卡成狗。运维天天报 CPU 占用高，排查一圈发现是 GC 在疯狂回收那些散落的节点对象。
数组结构下对象少，GC 压力小；链表每个节点一个对象，量一大 GC 直接破防。改成环形数组之后问题当场没了。
所以真不是链表算法复杂度不行，是现在硬件环境变了。以前内存慢 CPU 快，算法复杂度是王道；现在内存墙的问题太突出，缓存友好才是真香。老教科书那套得改改了。