刚入行做运营开发，优化一个库存同步模块用了链表跑，跑完后还被老员工说“现在谁还用链表做这个”。我去查了人家说链表在处理海量数据时缓存不友好，难道真这么严重？用链表做跨境电商的数据结构到底行不行，是不是已经过时了？
3 Answers
这事我也想问，哈哈。当年大学数据结构课链表是神，插入删除O(1)，我印象贼深。结果工作第三年被现实教育了。
我做亚马逊ERP的时候，有个sku关联查询的逻辑，链表遍历查A就查B，查B就查C。2000个sku，本地跑300ms。当时觉得还行吧。后来同事换了哈希表，100ms不到。我一查，2000个sku的链表，CPU缓存命中率低到20%，每次跳指针都等内存读。
你搞库存同步，如果用链表拼接多个订单的状态机流转，假如一次处理10万笔订单，那CPU就是一直在等内存，忙得要死但吞吐量上不去。换成数组或者连续存储的跳表，性能翻倍。
但也不是彻底废了。我后来做实时价格更新，场景是频繁插入删除（几万个价格点），链表就比数组强，因为数组要挪位，挪一次几万条成本爆炸。所以真的看场景。
宝子讲得好详细！
建议提前咨询专业人士
我也亏过，哈哈。
2026 年搞过一个实时报价模块，链表写了个报价订阅列表，每次更新遍历一遍。原来一天处理10万条请求，链个链表跑得像个老爷车。后来换成sorted list加二分查找，瞬间人模狗样。
现在写数据结构，前提是“CPU缓存比算法复杂度更值钱”。链表这种每个节点分散内存的，遍历起来就是内存延迟的代名词。但你要是做内存池或者自定义分配器，把链表节点塞进连续内存块里，效果又可以。所以看你会不会玩内存。
一句话：链表不是死了，是大多数人不会用好它了。我这种菜鸡以前也以为随便用链表就稳，后来发现被教育得明明白白。
楼上的说得挺对，我再补一个实际案例。
我朋友在猛搞东南亚Shopee的自建ERP，他之前用链表做订单到物流的状态转化。2024年底上线，服务器老崩。他查了三天，发现链表里状态节点指针跳跃严重，每个状态变更都要遍历几十个节点找下一个状态。改成数组索引加哈希，压力直接降了70%。
但说“链表已死”有点标题党。你看TiDB的底层存储，Log-structured merge tree（LSM-Tree）里还是用链表组织SSTable的合并链。真正“死”的不是链表，是在高频遍历场景下用它。如果你的数据操作80%是遍历，20%是插入删除，那你用链表就是在给CPU找不痛快。
不过你要是做轻量级定时任务队列，链表做回调链也挺香，代价不高。别一棍子打死。
