为什么有人说在现代计算机体系里「链表已死」？我实测了下有点懵，到底该信谁

我懂你这种懵，第一次看到这说法我也觉得是标题党。
但你换个角度想，链表的 O(1) 只是理论账。CPU 现在不是按字节读的，是按 cache line 一抓一大把。链表节点散在内存各处，你访下一个节点大概率 cache miss，主存那边等一两百个时钟周期。数组哪怕是 O(n)，人家顺着 cache line 一路跑，实际快得多。打个比方，链表像你每次找下一本书都要跑去另一个书架，数组是把书摞成堆手边随便翻。
前提是你的数据量够大、遍历够频繁。小数据量链表照样香，别被忽悠着全改成数组。
我 2022 年改过一个消息队列的缓冲区，从链表换成环形数组，吞吐直接翻倍，但我另一个只存几百个元素的配置表，换了反而没感觉，白折腾。

这事我也想问。我印象里链表的优势是插删不挪动其他元素,那这优势到底在什么场景才成立？
我自己试的时候发现,除非你手上已经握着要删那个节点的指针,否则你光是找到它就 O(n) 了,插删那点省下的全赔进去。很多教材举的例子太理想化,默认你已经定位好了。
所以我的理解是,链表厉害在"频繁在已知位置插删",一旦涉及查找,优势就没了。真做工程谁会没事在已知节点上插来插去,多的是先查后改。

以前我也觉得链表香,直到有次压测打脸。
那会儿做一个日志聚合,每来一条就挂个链表节点,想着插删多快啊。结果数据一上到几十万,内存全是碎片,遍历一遍慢得离谱,GC 也遭殃,一个个小对象到处飘。后来改成预分配的大数组,内存一下就整齐了,速度也稳了。
那次之后我才明白,链表在纸面上优雅,到了真实内存布局这一关就容易吃亏。也不是说彻底不用,就是心里得有个数:连续内存才是现代硬件的朋友。
现在再让我拍脑袋拍个链表上去,我得先掂量掂量。

楼上说得对一半。
链表没死,是"用错地方"的说法被夸大了。老哥你想,STL 里 list 一直还在,没人删,说明它有自己的用处。问题在于面试和教材把链表吹成万能,小白一上来就 list,那当然处处碰壁。
真打代码我一般数组为主,链表留给需要稳定迭代器、频繁中间插删的场合。这俩不是谁取代谁,是工具配场景。
非要说死,死的是"不分场景乱用"那股劲。

这个其实没那么复杂。
链表的问题就俩字,缓存。节点东一个西一个,CPU 预取都帮不上忙。数组是连续内存,预取器一猜一个准。
家人们写业务代码真不用纠结这个,你那个每秒几千请求的量级,链表数组都感知不到差异。真到较劲的时候,瓶颈十有八九在别处,不在数据结构。我见过有人花一周把链表换数组提速 5%,回头一看慢查询占了 80% 时间,真的会笑。
别本末倒置。

其实你想反了。
说"链表已死"的人,大多是在讲一个特定语境:高频遍历、大内存、现代 x86。这跟说"关系型数据库已死"一个味儿。链表在插入删除频繁、又不需要随机访问的地方还好好活着,很多嵌入式、内核代码天天用。
真正的情况是"不该无脑用链表",不是"不能用链表"。你要是听风就是雨,把项目里所有 list 都换成 vector,等着承受频繁扩容的拷贝开销吧。
别被一句口号带着跑。