为什么现在搞电商系统的人都说别用链表了？真那么坑吗

我懂你这种慌，刚做技术的时候我也觉得链表牛啊，插入删除O(1)多nb。结果呢？
家人们，我优化过一个订单聚合模块，原始代码全用链表存数据，就一普通订单列表，数据量两三千条。当时我改了两周，把链表换成数组加索引，运行时间从8秒掉到1.2秒。真的会谢。
核心不是链表慢，是现在的CPU缓存太吃数据连续性了。链表每个节点地址乱飞，cache miss一次就是几十纳秒的惩罚，你循环读一遍数据等于在内存里跳来跳去。数组是一块连续内存，读前三个就把一整块缓存塞满了。
电商系统里订单、商品、库存，哪个不是批量遍历和聚合？链表等于自己给自己挖坑。别纠结理论上的O(1)了，实际跑起来数组加vector就是比链表快一个量级。
反正我现在写新模块，链表基本只用来做LRU缓存，别的场合真不敢用了。自己打了自己脸。

楼上说得对一半，但补充一个我遇到的真实情况。
做跨境WMS系统的时候，库存变动记录这种需要高频插入中间位置的数据，链表真没法完全替代。我当时试过用跳表优化，比纯数组好很多。不过2026年了，大部分场景直接上Rust或者Go的slice就够了，谁还用C++手写链表啊。
所以我态度是：不要妖魔化链表，但新人学数据结构当玩具可以，放线上系统慎重。

楼主你这问题就有点题文不符了，搞跨境系统的谁特么天天写链表啊？
一个事：现代电商系统瓶颈根本不在数据结构选链表还是数组，在IO、在数据库、在分布式锁。你订单处理用链表存数据，换成数组也就省了几百毫秒，有啥意义？真优化得看Redis缓存、MQ削峰、分库分表这些。
不过你要说纯技术讨论，链表确实在大部分场景被按着打。内存不连续导致遍历慢，这不用争。但别被程序员圈带节奏，某些场景链表还是有用的，比如消息队列的内存队列实现、内核里的进程调度。正常业务代码谁用这玩意儿啊，真用上了就该反思架构设计是不是有问题了。
绷不住的是我见过有人把订单状态流转写成循环链表，结果bug修了三天。就这。