有人说现代计算机体系里链表已经死了，做跨境电商后台系统和选品工具的我该信吗

扯这么多，最后还不是看场景。我那个订单同步脚本,一开始全数组，结果中间要频繁插新单，挪元素挪得我头疼，改回链表世界清净了。
也没啥高深道理，能跑就行。

楼上说对一半，但也别把链表说得那么不堪。我在电子厂管过几年产线系统，那种嵌入式的小控制器，内存就那么点，栈和堆都紧张，链表反而是最稳的选择。你没法预分配一个大数组，只能靠节点一个个接上去，边跑边申请。
真正决定用不用链表的不是"现代不现代"，是你手头资源够不够、数据规模稳不稳。选品后台那种数据量可预期的，数组确实爽；但产线那种随时增减设备的场景，硬上数组就是给自己找麻烦。
工程师要的是解决问题，不是站队。哪种结构对当前场景最优就用哪个，没必要非得给链表判死刑。

前年我们组优化一个报表导出模块，就是活生生的例子。原来那哥们全用链表存订单行，跑一万条要十二秒。后来改成数组，直接在内存里连续排，同样的逻辑两秒不到跑完。
不是链表本身慢，是 CPU 压根不按你想的方式读内存。链表每个节点散在堆里,缓存预取一个都对不上，指针跳一次就是一次 cache miss。你要说插入删除 O(1)，那是理论，前提是你手上已经有那个节点的指针。可你遍历一遍找节点，照样是 O(n)。
但你要说它彻底死了也不对。老哥我去年写一个 LRU 缓存，还是得靠双向链表加哈希表配合，那场景数组真干不了。关键是你得知道啥时候该用啥，别拿链表当万能钥匙到处套，最后自己给自己挖坑。
大多数业务代码里，动态数组能覆盖九成需求。真到了要频繁中间插入删除、又不需要随机访问的场景，链表还是那根救命稻草。

这个其实没那么复杂。链表没死，它只是被挤到了角落干活。
家人们想啊,现在 CPU 的主频和内存带宽差得越来越离谱，缓存命中率才是性能命门。链表天生不连续，你让它怎么跟人家数组拼缓存？所以在热路径、高频遍历的场景，链表基本没戏。
但换个地方它又活了。你要做那种对象池、任务队列、图的邻接表，不要求随机访问，就图个增删方便、内存不用整块挪，链表还是省心。我上周写一个轻量调度器，就是靠链表串任务，跑得挺好。
所以别被"已死"这词吓到。真死的不是链表，是"啥都用链表"这种偷懒写法。选结构之前先问自己：我是要遍历多，还是要改得多？问清楚答案就出来了。
我也是边写边踩，说错了别喷我。