有人说现代计算机体系里链表已经死了，我写代码还在到处用链表，是不是真的落伍了

宝子们这个其实想反了，不是链表死了，是链表被赶到角落去了。我做个推荐系统的实时去重队列，节点随时增删、还要 O(1) 摘掉中间某个元素，用数组根本没法搞，挪一次全挪。用双向链表配哈希表，稳得一批。所以宝藏场景还是有，踩雷的是那种拿链表当默认容器、数据量又大又要连续遍历的写法。现在硬件缓存当道，连续内存就是香，这点认。但你要是那种内存碎片多、节点生命周期各不相同的活儿，链表反而省心。别被标题党带跑了。

我也不是没走过弯路，早几年写个订单队列，用链表存待处理任务，觉得增删多方便啊，结果压测一上来直接破防。几千条一跑，CPU 缓存全打满，遍历的时候指针到处跳，那个耗时跟数组比差了一个量级。后来换成数组加一个空闲位复用，速度肉眼可见。楼主说的那种"插入删除 O(1) 所以快"，理论上没错，但理论没把缓存算进去，现实里指针满内存乱窜，cache miss 一多，O(1) 也白搭。不过说链表彻底死了也不对，像 LRU 缓存那种节点要频繁摘挂的，链表配哈希表还是很好使。所以别急着全改，看你干啥活。

楼上说得对一半。链表不是死了，是被 benchmark 误导了。真正的问题不是 O(1) 对 O(n)，是常数和内存局部性。我实测过遍历 100 万个 int，vector 大概几毫秒，list 要几十毫秒，差十几倍，因为每个节点单独 malloc，缓存全 miss。但你要说链表一无是处，那 intrusive list 在 Linux 内核里用得到处都是，因为节点嵌在对象里，不用额外分配。所以结论是默认容器别用 list，特定场景照用不误。另外补充一句，vector 插入删除也不是都 O(n)，尾部 push 是摊还 O(1) 的，很多人连这个都搞混。