链表到底死没死？我写了个高并发模块被链表坑惨了，这东西现代计算机里真没用了吗？

这个其实没那么复杂。你的数据量如果不超过几百个，用什么都无所谓，链表也没问题。一旦上到万级、十万级，而且你大部分操作是遍历或按索引查，链表就是自杀。我见过有人把购物车商品用链表存，说是增删方便，结果每次查总价都要 O(n) 遍历一遍，订单流程直接卡住。最后拆成数组，一行代码都没改逻辑，快了三倍。真别神话链表了，现代计算机里它就是上个时代的遗留物，偶尔拿来解面试题还行。

我也亏过。2023 年做个内存池管理，图省事用了双向链表，想着增删爽。结果上线后吞吐就是上不去，查了俩星期，最后发现是链表的随机访问让 CPU 缓存全失效了，每次查都得从内存里拽，慢得一批。后来改成数组 + 位图，直接快了三倍。现代 CPU 快就快在缓存和预取，链表那破内存布局把这两点全废了。我现在写代码，能不用链表的绝对不用，除非数量极小。

楼上说得对一半。链表在嵌入式或者实时内核里还是活着的，因为那些环境内存大小固定、没有虚拟内存，更怕数组的动态扩容和碎片。比如我搞过的一个 RTOS 的任务控制块就用的链表，总节点数不超过 256，没必要用数组多占空间。但放到咱们写业务应用的环境里，内存带宽和缓存延迟才是瓶颈，那链表就真不如数组好用了。所以不是链表已死，是你得选对战场。到了应用层，你选它就是在给自己挖坑。

我上一个团队写游戏的实体组件系统，最开始全用双向链表管理组件列表，因为每帧要动态增删组件，理论上链表最合适。结果跑 profile 的时候发现，Update 函数的 60% 时间都花在链表节点的内存分配和遍历上。后来改成内存池分配 + 连续数组存储，帧率从 30 涨到 50。项目快两年了，代码里再也找不到链表的影子。除了 ring buffer 那种特例，普通业务场景真没必要碰它。数据量大一点，性能就崩。

其实你想反了，链表的 O(1) 插入删除是建立在已经拿到节点指针的前提上。但在大多数工作负载里，你找到那个节点本身就花了 O(n) 的时间，这才是真正的瓶颈。我写过一个订单状态机的图结构，节点两三百个，用链表哈希表组合实现。前置条件是你必须保证查找成本极低，比如配合了哈希索引，那增删上的优势才能兑现。但日常业务逻辑里，很少有人能把这种前置条件做好了。反正我现在默认用动态数组或 B 树，省心。