都说链表在现在的计算机体系里已经没用了，做跨境系统开发还用得着学吗

这个其实没那么复杂，看场景。链表没“死”，是被挤到了很窄的角落。
我 2021 年接的一个订单同步模块，当时用的链表存待推送队列，几万条订单，跑批的时候确实卡。后来换成预分配数组加环形缓冲，那个批处理从 12 秒掉到 3 秒多。原因很简单，现代 CPU 缓存友好度决定一切，链表节点散在内存各处，遍历一次 cache miss 一堆，你以为 O(1) 插入很爽，实际读的时候全还回去了。
所以跨境这种订单、库存、物流轨迹的批量场景，数组或者基于数组的结构明显更合适。链表真正还活着的地方是插入删除极其频繁、又不需要遍历的地方，比如 LRU 缓存的节点维护、某些事件监听器链。我们那个 ERP 里的限流器就是用链表做的，因为增删太频繁，数组挪元素反而贵。
结论就是别一刀切。新人说“已死”是学教材学偏了，你说“一直用”也没错，但跑批那块该换还是得换。

楼上说得对一半。你这个“订单队列用链表”，我先反问一句，你的数据量到底多大，是几千还是几十万？
几千条的话，链表数组差别你根本感受不到，为这个吵没意义。我 2024 年做过一个库存扣减的模块，当时也是纠结结构，后来发现瓶颈根本不在数据结构，在一个没加索引的查询上。换个结构优化半天，还不如改那一条 SQL。
姐妹们别被“已死”这种词带跑，先 profile 再动手。链表在需要频繁中间插入、且遍历不占大头的场景依然是宝藏，比如我们那个任务调度器，节点插入删除比遍历多得多，用链表顺手得很。但要是像你说的订单队列那种批量扫的场景，那确实该考虑数组了。踩不踩雷，看你数据长啥样，不是看教材怎么说。

我懂你这种慌，团队里突然来个讲理论的，谁都得自我怀疑一下。
但朋友们，性能这东西是真的会打脸的。我之前做过一个物流轨迹推送的服务，也是链表，单机跑得挺好，量一上去就崩。后来一查，热点全在遍历上，链表那个指针跳来跳去，CPU 预取根本帮不上忙。改完结构之后延迟降了一大截，具体数字记不太清了，反正肉眼可见地顺了。
所以我的态度是，新人说的方向对，但别全信。链表不是死了，是你得知道它贵在哪。真的会谢那些张口就“XX 已死”的，让他先把你那 12 秒跑批优化到 3 秒再说。