做跨境四年了，今天突然看到“链表已死”这个说法，真的假的？我在梳理订单处理流程的时候经常要用到，有点慌

楼主你这问题问得有点外行。链表不是"已经"，是"从性能角度看被CPU干死了"。你想想，现在一个CPU核心每秒钟能触发几十亿次时钟周期，但去主存拿一次数据可能要等几百个周期。链表每跳一步就要等一次主存，数据流量大一点就全卡在内存墙上了。
这些年数据库、操作系统、网络框架这些底层，基本全在推连续内存结构。你去看Redis的跳表、Linux内核的红黑树，哪个不是尽量把数据搞得紧凑一点？连Go语言官方都建议用slice（动态数组）代替链表。你还抱着O(1)插入删除当圣经，绷不住了。
不过话你要是数据量特别小（几百条）、操作又极其频繁地增删，链表确实还能凑合用。但做跨境订单这种大流量场景，换了吧，别犹豫。

这事我也想问，之前我团队请了个架构师，上来就把我们那个库存调度的链表改成了数组，当场我脸都绿了。我跟他说链表插入删除都是O(1)，这不是优化是降级吧？他看了我一眼，给我讲了十分钟现代CPU的缓存行和内存预取。
他大概意思是，链表的数据在内存里是乱跳的，节点A在内存位置100，节点B可能在位置100000，CPU去拿数据的时候要先等很久加载缓存行。而数组是连续的一段内存，CPU一次加载一整条缓存行，后面几个数据可能已经提前准备好了。
我自己后来做过一个测试，用链表去遍历50万笔订单ID，和用数组遍历同样的量，数组快了十倍左右。插入删除O(1)的前提是你已经拿到了那个位置，但链表找位置得寻址啊，寻址的过程O(n)卡死你了。
所以别把教科书上的理论直接搬过来，现实里CPU的物理特性决定了链表的劣势。不是完全不能用，但前提是数据量小、且你访问非常局部。

我2023年接手过一个报关数据处理模块的优化，它核心是一个链表结构，用来存几十万条报关单的待处理状态。我一测，处理一万条数据需要跑七秒多。后来换成双端队列+批量预装载，直接降到0.6秒。
根本原因就是楼上哥们说的缓存不命中。链表节点的内存空间是动态分配的，节点之间可能隔得很远。CPU要处理节点A，从主存加载到L2缓存那一块叫缓存行（64字节），结果下一个节点B可能完全不在这个缓存行里，又得去主存拿。现代CPU的瓶颈根本不是计算而是内存等待，链表刚好撞枪口上了。
数组在内存里连续，CPU一次性加载好几个，循环里大概率全都命中L1/L2缓存。我那个例子测出来，数组遍历速度大约是链表的10-12倍。插入删除O(1)只是理论，实际寻址O(n)已经把这个优势废掉了。

姐妹们，楼上说得对一半，但我也踩过链表的雷。我做跨境物流那个系统，之前用链表存包裹运输状态，一单大促爆仓，时间戳连续读写，几千个包裹的状态在链表上跳来跳去，结果有个节点卡死在更新上，整条链断了，丢了好多单。
后来换成数组+哈希表，快多了。我感觉技术选型真的有"宝藏和踩雷"的对比，数组就像稳定的海运头程，链表就像那种不靠谱的小包直发。但也不是说链表完全死透了，比如那些数据量很小、插入删除超级高频、且路径很稳定的场景（比如某个订单内部的步骤状态），用链表还能省一点内存。
我建议你还是得找你们技术聊一聊，问清他们数据量级和访问模式，别直接换。