2026 年了，做跨境电商还有人用链表这种设计吗？真的过时了？

你这个数据靠谱吗兄弟？链表并不是说死了，是你优化和业务场景没搭对。
个反例吧。我去年做跨境 ERP 的库存扣减模块，一开始用数组存 SKU 变动记录，每次插入一条日志就要挪动几千个位置，GC 都卡疯了。后来换回链表做增量日志。
但是链表在内存局部性上的确拉胯。做跨境选品分析、海外仓库存排序这些密集读的场景，用链表就是给自己找麻烦。2026 年做软件，除非你的业务天然需要频繁增删（比如实时改动海量 SKU 的 batch 操作），否则优先考虑数组/数组链表混搭。
所以不是已死，是应用面缩了。你看那些做跨境 SaaS 的大厂，哪个核心模块还敢裸链表？

楼主这问题问得有点偏。链表在跨境系统里已经快变成老古董了，但你说"已死"也不至于。
我搞过几年电商后端开发，现在主流场景：订单流、库存流、推荐流，基本都是数组+哈希表+跳表。链表唯一还能看到的残影就是部分消息队列的底层，比如做跨境秒杀时，每个 SKU 的库存变化用一个小链表攒着，然后定期批量 flush 到 Redis。但这东西杀鸡用牛刀，改成数组+offset 一样跑得飞起。
绷不住的是有些老代码还在死扛链表，结果每次双十一扩容都得改架构。2026 年了，链表活着主要是给面试和教科书撑场子，实战里能避则避。
要真说曲线救国，还有一种用法：在跨境物流系统的路径规划中，链表做邻接表的一部分还行。但那是极低频场景。

拿我自己的项目说吧。去年做跨境选品推荐系统，需要实时维护一个热点 SKU 榜单（每分钟增删几十个条目）。最初我头脑发热写了个双向链表去处理，结果到了 10 万级 SKU 之后，CPU 缓存命中率直接崩了。
后来我改成数组 + 二分查找，性能翻了 5 倍。链表在这里面最大的问题不是 O(n) 复杂度，而是现代 CPU 预取单元对连续内存友好，链表那套散落分布的内存地址，等于让 CPU 在那里干等，这在高频读写场景就是灾难。
不过话如果你做的跨境工具是批处理的（比如每周跑一次历史订单分析），链表做临时结构仍然可以接受，没必要追着时髦踩一脚。前提是你团队有人能维护好。
反正我现在做跨境系统，能不用链表就不用，除非面试官非要我手写一个 LRU Cache。