为什么说在跨境电商数据分析里「链表已死」？我真服了，写个库存算法还用链表

我懂你这种慌，刚接手代码看到链表心里也是一咯噔。
前提是，如果你做的是订单缓存、最近操作记录这种场景，链表还是有用的。但前提是数据量在小几万以下，而且你明确知道要频繁在头部做插入删除。但大多数跨境业务系统，比如库存汇总、销售报表聚合，本质是遍历 + 随机访问，链表就是拖后腿的。
我常用一个比喻：链表就像手工记账本，翻页找数慢；数组就像 Excel 表格，一键排序筛选。没人会在跨境系统里用手工账本对吧？所以链表已死不是技术上的，是实际工程选择上的。

楼上说得对一半，链表在纯算法题里是神器，但到了跨境电商的实际场景，尤其是百万级 SKU 的库存遍历，链表就是灾难。
我说个自己的事。2024 年我司的订单分配系统，原本用链表存待发货列表。每天中午爆单那会儿，系统要遍历几千条未发货订单，链表一个节点一个节点地跳，搞了 CPU 100% 还延时，仓库那边打印机半天不出单。后来改成了数组 + 索引，遍历时间从 8 秒降到 0.1 秒，就是这么夸张。
链表的问题在于，内存不连续，缓存利用率低。现代 CPU 对连续内存的遍历是有硬件加速的（内存预取这些），链表每跳一次都可能触发 cache miss，性能断崖。做跨境系统，数据量大、高并发是常态，链表被抛弃真的不冤。

老哥你这个数据靠谱吗？12 秒跑个 SKU 列表？
好吧，我信。2025 年我自己写过一个 FBA 补货预测的脚本，用的 Python 列表做遍历，几万个 ASIN 几秒跑完。要是用自己写的链表结构估计得等到下班。
现在做跨境开发，不太需要纠结链表。大家用的都是高级语言，Python 的 list 底层就是动态数组，Java 的 ArrayList 也是数组。链表在语言层面就没被优化过，用起来还容易写出野指针。除非你是写底层中间件，否则真没场景。6 年前我可能会杠一下，现在我只想说，谁爱写链表谁写，反正我库里全换数组。