做跨境 ERP 的，为什么都说现代计算机里“链表已死”？我该学吗

我懂你这种慌，工作第一年我也问过一模一样的问题，当时还专门买了几本书补链表，结果发现老大根本不用。
跨境电商业务场景其实挺“数组友好”的。
你看订单列表、库存快照、广告报表，都是批量加载+遍历，接口设计也鼓励一次拉 1000 条，然后你在内存里排序筛选。数组一行搞定，CPU 缓存命中率还高。链表呢？插删确实 O(1)，但你得先找到那个节点，那又是 O(n)。你算算，1000 条订单里找第 500 条，链表 vs 数组，哪个快？
而且，链表每个节点还要额外存前后指针，内存占用直接翻倍。做过海量 SKU 迭代的都知道，内存是宝贵的，特别是你本地跑不过，还得租阿里云。
但也别完全放弃它。像我们做 BOM（物料清单）模块的时候，父子件关系天然是个多叉树，用链表实现的栈来做深度遍历，贼顺手。只不过这种场景在 ERP 里就 5% 不到。

我也亏过，刚毕业那会写个库存预警模块，用双向链表存待补货的 SKU，觉得漂亮。
结果 QPS 一上来，内存碎了，GC 频繁，线上老报 OOM。Leader 让我改成数组+位图，直接稳了。
后来看了一些解释，说链表在 2026 年的 CPU 体系里，已经是被抛弃的姿势了。现在都是多级缓存，数组有序存储，预加载到 L1 缓存，链表跳来跳去的，CPU 还要等内存，亏死。
所以你的选择很简单：做业务系统，数组/哈希表/slice 足够了。只有等你做到实时竞价系统、高频交易这种，才可能回头捡链表。

楼主你这问题，让我想起刚学数据结构那会的“链表信仰”。
实际做跨境 ERP 开发，你处理一个月的订单量，根本不需要链表。我朋友写了个 SKU 选择器，用数组存商品，访问时间 0.01ms。他非要改链表，结果用户选品页面加载慢了 8ms，直接被 Qa 打回来。
所以我建议你，直接跟老大核对：当前项目里的核心数据结构（比如订单池、缓存池），有没有用链表？十有八九没有。没有的话，你就专注于数组和 hashmap，把这两个用得滚瓜烂熟，比啃《算法导论》更实际。
至于链表是不是已死，那得看是哪个“计算机体系”。做嵌入式、操作系统，还得学。做 web 开发、ERP 数据流，确实边缘了。

我 2023 年在供应链团队，有个同事写了个 BOM 拆解模块。
功能是：上传一个产品物料清单，系统自动递归拆解出所有子件。他用递归+数组，结果层级一深（比如一个成品拆 8 层），栈溢出。后来改成链表实现栈，手动管理入栈出栈，代码丑是丑点，但稳定运行一年多没崩。
后来我跟一个做 TMS 的兄弟聊，他说他们处理物流路由，也用链表，一个车队派送路径，天然是双向链表呀，你前后加个站点，插入删除不要太爽。
但你要是问日常订单管理、店铺数据、广告报表，那确实用不上。理解一下原理就行，别在这上面死磕。

其实你想反了，链表在现代计算机里不是“技术上的死亡”，而是“工程上的退场”。
我 2024 年开始写 Golang，里面就没原生链表，得自己用 container/list 包。但你看 Rust 的 Vec 和 C++ 的 std::vector，哪个不是数组变种？大家默认了，处理批量数据就用连续内存。
但你要说完全死了，那也不准确。Redis 的列表底层就是双向链表（ziplist 之后又改成了 quicklist）。数据库里的 B+ 树节点内部，也用了链表做叶子页。你真去做内核开发、中间件开发，链表还是得会。只不过做跨境 ERP 这种业务层，确实用不上。
别担心“学链表没用”，那是在锻炼你的指针思维。真正要警惕的是，为了用链表而用链表，把简单问题复杂化。

这个其实没那么复杂，看业务场景定。
我做跨境电商系统开发八年了，从 PHP 写到 Java 再写到 Go。2020 年那会，我们的“实时库存预占”模块，内部用了 ConcurrentLinkedQueue（无锁链表），支撑日均 300 万次扣减，稳得一批。
但那时候我们用链表，是因为业务特性：订单进来，立即预占库存，如果超时未支付就释放，节点不断插入删除。用数组的话，扩容+移动元素开销太大。链表天然支持频繁的头部尾部操作。
不过这几年，随着 Redis 和内存网格的普及，瓶颈不再在数据结构上。我们内部直接用 Redisson 的 RQueue 搞定了，不用自己维护链表。
所以“链表已死”这个说法，更多是业务层被中间件替代了。真要学，不如学 Redisson、Redis 这一套。但链表作为底层原理，还是要懂，不然你调优的时候连缓存行都说是啥都不知道。