2026年了还在纠结链表用不用？做跨境后台系统的兄弟，你们都拿它干啥，真的一无是处吗

你这个"几万条 SKU 全挂一个结构"的设计靠谱吗？我第一反应不是链表死没死，是这个结构本身就该拆。
我踩过的雷跟这个有点像。2024 年我做过一个多平台库存同步，一开始也是把所有平台的 SKU 塞一个双向链表里维护，删一个变体要扫半天，还老出脏数据。后来拆成"主 SKU 表 + 平台映射表"，按访问频率分开存，问题一下就没了。这个改动比纠结链表还是数组实在多了。
结构选型是小事，数据怎么分层、哪个字段高频查、哪个字段高频改，这才是大头。

讲个具体 case。去年帮朋友看一个跨境 ERP 的库存模块，SKU 记录用双向链表维护，五万多条，每次批量更新价格要卡三四秒。我让他把链表换成数组加哈希索引，批量更新直接降到几百毫秒。
但反过来，他那个物流轨迹节点，一条订单几十个状态来回插，链表版本一直很稳，没动。
所以别一刀切。数据结构这东西，看场景，不看口号。

楼主你想反了。真正"死"的不是链表，是那种拿链表当默认答案、不考虑缓存的习惯。我去年做过一个订单处理模块，核心结构就是链表，跑一批十几秒。我当时也以为是结构选错了，折腾两天换数组，性能就涨了百分之十几，绷不住。
后来才发现瓶颈根本不在链表本身，是我每次遍历都要跳内存，节点散得一塌糊涂，CPU 缓存全打空。把节点改成块状分配、遍历改成顺序扫，链表版本照样快。
所以别一听"链表已死"就全换，先 profile 一下，看看你到底是结构问题还是内存布局问题。

楼上说链表已死的说法对一半。面试里"链表已死"是句偷懒的总结，放到真实业务里根本不是这么回事。
我们后台订单聚合那块，每个订单挂的子商品、物流节点、操作日志，量级差别极大，有的订单 3 条，有的 800 条。这种"节点数不确定、频繁增删、很少随机访问"的场景，一开始我也全换成数组，结果每次插入都要整体挪位，反而更慢，最后乖乖换回链表。
关键看你的访问模式。库存和价格这种高频查表、要按 SKU 索引批量扫的，用数组加哈希肯定对。但变体关系、物流轨迹这种一路往下走的，链表天然合适。技术负责人说那句话没错，但他说的是"教科书当唯一答案"的链表，不是"业务里能用上"的链表。

我两年前也信"链表已死"，把一个客服工单系统的队列全改成数组，结果上线第一周插入延迟反而涨了，回滚回来被 leader 说了一顿。后来学乖了，凡是增删频繁、顺序访问为主的地方，链表该用就用，别管网上喊什么。现在再让我重构，我先看监控再动手，不瞎改。