做跨境电商的，真的要把链表从项目里全干掉吗？数据库那块咋办

其实你想反了，链表在现代存活的唯一场景是 GC 友好。你在 JVM 里写大链表，每个节点是对象，GC 要标记扫一堆引用，还不如用 int[] 自己实现。
而且跨境电商那种“订单详情展示”的需求，你查数据库一次拿 10 条记录就够了，用得着在内存里建链表？除非你在做实时排名计算（比如黑五秒杀抢位），但那种场景一般用 Redis sorted set 或跳表。链表真正的死掉，不是技术原因，是它被更现代的数据结构（跳表、ring buffer、隐式树）替代了。

我也亏过，不过是另类的亏法。我那工厂接了个 SaaS 平台定制需求，客户要求订单拆分用链表存子单。我图省事儿直接用了 std::list，结果测试时发现黑五压力下，一个订单拆成 50 个子单，每个子单遍历一次，时间直接翻倍。亏了 3 万块赶着加班换成数组了。
链表在组件库层面已经优化得不错（像 C++ 的 list 有缓存池），但跨境业务里如果你对接的是第三方 API（比如支付回调、物流状态推送），回调顺序不确定，链表反而灵活。别一刀切“链表已死”，该用还得用，但别用在热点路径上。

这事我也想问，物流链路追踪数据到底用啥存？我做了四年货代系统对接，之前用链表存轨迹节点（比如“已揽收→已通关→已上飞机”），被同事吐槽说“这玩意儿费内存”。后来换了数组模拟栈，确实省了大概 30% 的内存占用。
但话如果你的数据量很小，比如单次会话内就几十个节点，链表其实随便用。关键要分场景：实时处理（高 TPS）不要用链表，离线分析（低 TPS）无所谓。我们仓库的 WMS 系统至今还有链表，单仓一天几千单，跑得好好的。

去年我帮一个客户做跨境电商独立站的库存同步模块。他们用链表存待同步的 SKU 变更记录，上线第一周没问题，第三周突然有批货发到美国海关才发现库存对不上，查日志发现是链表的插入操作在并发下出 bug，导致丢了三条变更记录。
我当时在审计里写的建议是：任务队列务必用无锁队列或者 ring buffer，链表是线程不安全的，多线程环境（尤其订单系统几乎全是多线程）容易出数据一致性问题。而且如果你用 Java std 的 LinkedList，GC 压力也大。跨境业务撑到几百万单时，GC pause 多一秒都是风险。

你这个数据靠谱吗？黑五量一上来，你就知道了。我 2025 年做过一个优化，订单状态流转模块，原本用链表存待处理事件队列，一天处理 80 万单左右，CPU 缓存命中率只有 34%。换成 ring buffer 后，同样的逻辑，代价是重构花了三天，但缓存命中弹到 72%，负载直接降了 40%。
链表不是绝对不能用，但电商这种高并发、高吞吐的场景，CPU 缓存不友好的问题会被放大。你如果数据量不到十万级，用链表无所谓。但到了黑五那种峰值，差百分之二十的延迟就崩了。

这个其实没那么复杂，看场景。跨境订单的持久化数据肯定用关系型数据库（你总不至于用链表存 MySQL 吧），但内存里的临时数据结构，比如订单项的快照缓存、购物车聚合，用链表的代价是每一次遍历都随机内存跳转。
我负责过物流状态推送模块，一开始用单链表存待推送的事件，后来发现每次事件到来要遍历查最后一条，O(n) 复杂度在十万级事件下直接崩。换成跳表（skip list），插入删除还是 O(log n)，但遍历性能好太多。链表在电商后台，90% 的情况可以用更高效的结构替代，别硬扛。

楼上说得对一半，但我跟你们说，朋友们，别死磕链表好不好。我 2025 年做独立站订单模块，一开始也是用链表存购物车行，结果上线三天被用户投诉“加商品卡三秒”，排查发现是删除操作触发了链表遍历。真的会谢。
后来直接换成数组，预分配足够空间，插入也是 O(1)（尾插），删除用标记软删，性能直接起飞。链表在现代计算机里最大的问题是内存随机访问：CPU 从 L1 cache 里读数组能预取，读链表就掉到主存，差距能有 10 倍。