有人说现代计算机体系里链表已经死了，这话放到咱们跨境电商的选品工具和订单系统里还成立吗

想起我 2025 年接手的一个坑。一个做家居的小团队，自己写了个利润计算工具，历史订单全用链表存着，每次改个汇率要重算，点一下卡半天，运营小姐姐天天吐槽。
后来拆开看，问题根本不在数据结构选啥，是他们每算一单都要顺着链表从头走一遍，还嵌套了两层循环。换成数组 + 一次遍历，再预先把汇率缓存住，卡顿直接没了。整个过程改的代码不到五十行。
所以姐妹们别被"链表死没死"这种话带跑偏，很多时候卡不是数据结构背锅，是写法的问题。当然真要二选一，读多的场景我会选数组，这个没跑。

楼上说得对一半。链表没死，但你说"订单数据全用链表串着跑十几秒"，那真不是链表的锅，是场景选错了。
订单这玩意儿你是要遍历、要聚合、要按条件筛的吧？这种读多写少的活，链表就是灾难。你每次从头顺着 next 找，节点又散在堆里，内存访问一跳一跳的，数据量一上来全耗在等内存上了。我 2024 年帮一个做 3C 的朋友看他们的库存脚本，也是这样，几万个 SKU 拿链表串，跑一次二三十秒，后来直接换 SQLite 加索引，秒级出结果。
真要说链表还能用在哪，就是那些插删特别频繁、顺序还重要的场景，比如消息队列、撤销栈、播放列表这种。你要是写个最近浏览记录、购物车增删，链表反而比数组舒服。
所以结论不是"链表已死"，是"别拿链表当数组使"。题主你先把订单那块换成数组或者数据库试试，十几秒大概率能压到一两秒。

其实你想反了，不是链表死了，是"用链表的地方"被人抢走了。
我早几年写选品脚本的时候也爱用链表，觉得插入删除快，多优雅。结果一批 3 万个 SKU 跑下来，缓存全miss，CPU 就搁那干等内存，10 几秒是常态。后来数据改成一整块连续存的数组，同样的逻辑，1 秒多就跑完了。老哥当时那个心情，又爽又想砸键盘。
关键在于现代机器吃的是缓存，不是算法复杂度。数组在内存里挨着放，CPU 预取一拿一大把；链表节点东一个西一个，指针跳一次就是一次 cache miss，O(1) 也救不了延迟。所以不是链表挂了，是你拿它干了它不擅长的活。
我现在的习惯是，静态的、要频繁遍历的数据，比如订单列表、SKU 快照，一律上数组或者干脆丢数据库；真要频繁中间插删、量又不大的，比如购物车、任务队列，链表照样好使。
不过话这话题放咱圈子里聊有点偏了，多数卖家根本不到手写数据结构这一步，能跑起来不崩就谢天谢地了。