为什么有人说在现代计算机体系中「链表已死」？做跨境电商后端的有同感吗

其实你想反了，链表"已死"说的是主流通用场景，但嵌入式、驱动、操作系统内核里活得好好的。Linux内核的进程调度就是链表遍历，大量数据结构还是双向链表的变种。前提是数据量小且高度局域化，CPU缓存就算差也比内存快一个数量级，几百个节点来回跑压根没影响。你电商后端处理百万级订单，当然不会用链表做主数据结构，但TCP连接管理、内存池那块，链表依然主流。就像手工炒菜不会被预制菜完全取代，链条在底层场景里就是那把菜刀。

这个其实没那么复杂。我做了十年物流系统开发，后台处理包裹路由的中间层，早期全用链表存待处理的订单ID，结果一次生成300万条路由记录，链表遍历慢到爆。后来换成数组+二分查找，时间从12秒降到0.8秒。但从物流链角度说，链表"已死"更多是现代CPU设计逼的，缓存行预取对连续内存友好，链表跳来跳去等于给CPU喂屎。电商系统里数据量过万就该警惕链表，大促时订单量千万级，用链表就是自寻死路。反正我团队早淘汰了，除非是写底层驱动。

楼上说得对一半，链表确实缓存不友好，但说"已死"太绝对了。我搞过几年电商后台，处理高并发分拆的订单排序，用链表插入删除O(1)比数组香多了，尤其哈希表链地址法解决冲突，底层就是链表。问题是现代CPU缓存行一次拉64字节，链表节点分散在堆里，遍历时CPU大量等待内存，性能崩得一批。你拿链表跑大数据集排序，当场教你做人。做订单处理时，我数据量几万条用链表还行，到百万级换成数组+索引标记删除，性能翻了快四倍。反正你要看场景，别一棍子打死。

家人们，我搞跨境电商后端快三年，链表这玩意真让我崩过。2025年有一次订单退款模块崩了，查系统日志发现是链表遍历卡在热点数据上，十万个节点打散在堆里，CPU缓存命中率跌到4%，服务器跑了半小时报警。当时我以为是代码bug，debug两天才发现是数据结构问题，换数组+二分法，退单处理时间从120秒降到3秒。真的会谢。现在写业务代码我默认不用链表，除非是极小的L1缓存级数据，比如内存池里连几百个节点。