都说链表在现代计算机体系里已死，搞跨境电商的程序员还要学这个吗？

家人们，这个其实没那么复杂。搞跨境业务的服务器端，99% 的场景用不着自己琢磨链表。
你就想想你那套订单系统：几百万订单？MySQL B+ 树帮你索引了，你写个 ORM 就完事。Redis list 实现底层还是双端链表，但你调的是 lpush/rpop 方法，谁管它怎么存的？
我进组第一个项目，Senior 扔给我一个链表实现的双向订单队列，说"性能差你去重构"。我看完代码，直接把所有链表操作改成 Redis list 调用，上线后延迟从 200ms 降到了 12ms。链表高手在嵌入式和底层库里混，你搞业务服务端的真别给自己加戏。真的会谢，浪费时间学这些不如去搞懂为什么你的 Redis 集群总断连。

楼上说得对一半。链表在现代业务系统里确实快被数组和哈希表挤死了，但你说"已死"那太绝对。
我 2025 年在公司的库存实时更新模块就硬扛了一回。业务场景是 SKU 维度库存变更，LRU 缓存策略需要频繁删除尾部、插入头部。当时用数组 + 哈希表 + 双指针做了个变体，结果数据量到 300 万 SKU 时 tail 删除要 O(n) 扫描，直接拖垮查询。
最后回退到双向链表 + 哈希表做 LRU，插入删除 O(1)，命中率直接从 77% 升到 91%。内存碎片化确实严重，但那台 64GB 的机器多吃了 4GB，代价能接受。
所以结论：纯高性能计算里链表确实退场了，但业务系统的局部优化场景，尤其是 LRU、LRU-K 这类缓存淘汰、或者订单状态机里的 next/prev 遍历，链表比数组香得多。别听网上人云亦云。

2026 年我给东南亚海外仓做一个包裹分拣流程，数据流要按时间序插入 8 个分拣站。用数组实现的话，中间插入一个包裹就要 O(n) 移动后面几千条记录，分拣延迟直接崩。
二话不说上了单向链表+尾指针，插入 O(1)，缓存命中率 95% 往上。内存多吃了 1.5GB 但分拣吞吐从 300 件/小时冲到 2400 件/小时。
链表死了？那是我这 5 年省下的最大一笔服务器钱。别被理论派忽悠。

这事我也想问呢。大学数据结构老师把链表吹上天，说什么"动态扩容灵活"，结果工作第一年我写了个订单去重模块，用链表存待合并的订单 ID，跑个 50 万行级数据，CPU 缓存命中率掉了 30%，内存带宽被 random access 吃光，被运维拉去喝茶。
后来翻了 Intel 的手册才明白，现代 x86 的 L1 缓存 64 字节 cache line，链表 next 指针分散导致每次访问都要去主存捞数据，而数组连续内存一次 cache line 能预取 4-8 个元素。那什么 O(1) 都是骗鬼的。
但说"链表已死"也不对。我 2026 年在做跨境支付的风控规则引擎，规则链要用到尾部频繁追加、头部删除的匹配链表，哈希表做不了这种顺序遍历。只要你的数据在 10 万量级以内，链表用起来没毛病。别拿大数据场景吓新手。