为什么有人说在现代计算机体系中「链表已死」？做跨境数据这块我也迷茫

其实你想反了。不是链表死了，是它被降级成"低频写、高频读"场景里才配用的东西。
老代码里动不动就用链表存订单、存日志、存库存变更，那是没得选。现在内存便宜了、数组扩容也便宜了，大部分业务就是先读后写，链表反而拖后腿。
我这边订单模块 2026 年初刚改过，把原来一条链存当日订单换成数组加 map 索引，读那份报表从 8 秒降到 1 秒多。不是算法多牛，就是少跳指针。
但你要说链表彻底没用，我不认。LRU 的 evict、任务队列、undo 栈，这些地方用链表比数组顺手得多。说它死的多半被坑过一次。

你这个"几万条订单"靠谱吗？几万条压根不用纠结链表还是数组，随便写写都跑得动。
真正卡的大概率是别的东西：是不是循环里查了库，是不是每条订单都单独发一次 HTTP，是不是锁粒度太粗。
我们 2024 年做过一个对账任务，一开始也觉得是数据结构问题，结果查下来是一条一条去请求物流接口，改成批量 500 条一次，时间直接砍掉八成。数据结构那点开销根本没排上号。
先把 profile 跑一遍，看热点在哪。别上来就换结构，换完发现跟你想的不是一回事。

这个其实没那么复杂，宝子们别被"死不死"绕进去。
我给你们打个比方。数组就像一排连着的座位，你从头走到尾很顺；链表是每张椅子上贴个纸条写着"下一个坐哪"，你得挨个找过去。数据少的时候感觉不出来，数据一多，找人这条路本身就把时间耗光了。
我踩过一次雷，用链表存了十几万条库存快照，查询慢到想砸键盘，后来换成数组重做，同一台机器快了好几倍。
但也不是说链表就废了。消息队列、撤销栈这种"频繁在两头加和减"的，用链表照样香。关键是你的场景是"翻得多"还是"两头加得多"，对上了就好用，对不上就是宝藏变踩雷。

这事我也想问呢，上次说我们仓管系统要重构，技术那边一句话怼回来：链表早不行了，现在都用数组加索引。我当时也没敢接话。
后来我自己去翻了一遍。真正的问题不在插入删除是不是 O(1)，而在内存里那些节点是散着放的。CPU 读数据是一块一块读进缓存的，链表每跳一个节点就大概率要重新去内存捞一次，数组就顺顺利利一行带过去。数据量一上来，这个差距能把 O(1) 那点优势全吃回去。
所以你看 Redis 的 list，量小了用 ziplist 那种挤在一块的结构，大了才转成 quicklist。人家不是不用链表，是不敢让指针到处乱飞。真别只看大 O 记复杂度。

楼上说得对一半。链表没死，是被误解了。
真正变的是硬件。二三十年前内存和 CPU 速度差不多，指针跳一下不算事，链表的 O(1) 插入删除就是真优势。现在 CPU 快了几百倍、内存相对慢了一大截，随机访问的代价被放大了，数组的连续访问才显得香。
所以你看内核里链表还在用，只是没人拿它当默认结构了。判断标准其实很朴素：如果你几乎不按顺序遍历、只是频繁在两处增删，链表还是好使；要是三天两头扫全表，趁早换数组。
拿"死没死"当口号没啥意义，看场景就是了。