为什么有人说在现代计算机体系中「链表已死」？我做数据模块优化那两年也有点懵，想听听同行怎么看

楼上说得对一半。
我这边是硬件厂，做产线数据采集。嵌入式那点内存，链表真的省，动态申请节点比一次性开大数组稳得多。MCU 上 RAM 就那么几 KB，你上来一个万级数组，直接爆。
所以「链表已死」这话在我们厂子这边不成立，死的是「不分场合无脑用链表」。现代计算机缓存友好确实偏向连续内存，这个我认，但别把 PC 上的结论套到所有设备上。我们产线那批采集板，2024 年换方案之前全是链表撑着。

你这个数据靠谱吗？15% 提升这个数看着就很奇怪。
我去年做选品爬虫那块也踩过这坑，一开始用链表存商品列表，插数据是快，但每次跑分页要顺着指针一个个跳，CPU 缓存全打空了。后来改成数组分块存，同一批 20 万条数据从 8 秒掉到 0.9 秒。
所以问题不在链表本身，在于你怎么用。你要是频繁遍历、还要随机访问，链表就是坑；要是纯头插尾删、数据量大又不想搬家，它还是香的。别一概而论说它死，姐妹们选数据结构跟选品一样，得看场景。

我也亏过，当年面试被问链表，背得滚瓜烂熟，进了项目一次没用上。
朋友们真别纠结它死没死，你就记住两条：连续内存对缓存友好，指针跳转对缓存不友好。剩下的按你实际数据说话。
我现在写代码默认数组起步，真测出来插入是瓶颈了再换。就这么简单，非黑即白说它死的，八成自己也没测过。

这个其实没那么复杂。
现代 CPU 的内存墙才是关键。链表节点到处散，读一个跳一次 cache line，硬件预取器基本白给。数组是连续的，从头扫到尾预取拉满，看着 O(n) 其实比链表还快。
就这么个事。你真要频繁插入删除又不在乎遍历速度，链表照样能用，没人拦你。老哥别被标题党吓到。

其实你想反了。
不是链表死了，是大多数人在不需要链表的场景硬用了链表。教科书教你链表是因为它逻辑清晰、好讲指针，不代表工程里就该默认选它。
我刚开始写业务代码那会儿也是，一看到「频繁增删」就上链表，结果列表总共就几百条，遍历还占了大头，纯属自己给自己找事。真该问的是：我的瓶颈在插入还是在扫描。搞清楚这个再选结构。

我懂你这种慌，刚看到「链表已死」这种说法谁都会懵一下。
但你去翻实际 benchmark，结论没那么绝对，得看数据规模。小规模（几百到几千）两者差别几乎测不出来，编译器优化一下就抹平了。真正拉开差距是数据量上万、而且访问模式随机的时候，链表因为 cache miss 吃亏明显。
所以别被一句口号带跑，先量你自己的数据量和访问模式，再决定换不换。我见过太多人没测就重构，改完还不如原来。

2026 年我重构过一个订单去重模块，原代码用链表维护一个去重队列，每来一条新订单从头扫一遍找重复。日订单量上到 30 万之后，那个模块直接成瓶颈，P99 延迟飙到 2 秒多。
改成哈希表加环形数组，同样的机器，P99 掉到 80 毫秒。链表没做错什么，它只是被放错了位置。
前提是你的数据访问模式是「查找密集」而不是「插入密集」。前提不成立，换什么结构都白搭。

这事我也想问呢，每次面试问「链表和数组选哪个」，标准答案都是「看场景」。
结果一看实际项目，链表出现的地方基本都是历史遗留，新的模块没人主动用它。那到底是谁在用？还是说大家嘴上说看场景，手上一律数组加哈希表完事。
感觉「链表已死」更像个行业偷懒的说法，把复杂问题一句话糊过去了。