楼上说得对一半。链表"死"指的是在传统高性能场景里，比如内核开发、高频交易这种，内存局部性太差，被数组、向量、哈希表按在地上摩擦。但做跨境运营写脚本处理 Excel、数据库里几千条订单，这玩意儿压根跟你没关系。
我 2016 年那会儿接手过一个性能问题，也是链表做的，改了个循环就快了。主要卡在别处。你说链表已死，是死在大厂核心系统里，不是死在小团队 Python 脚本里。你该担心的是 Pandas 处理十万行数据会不会爆内存。

2026 年我优化一个批量发货脚本，处理一万个订单，每次插入链表要两秒多。后来改成列表，一秒不到。当时我也觉得链表是不是该进棺材了。
后来发现，是我 Python 写得太烂。链表在 Python 里是 list 的底层实现之一，你用它写业务就是图个明白，真要性能还不如用 numpy 向量化。所以"已死"这个说法太绝对，但在我们应用层，确实很少用。你懂它思路就行，不用真写。

姐妹们，其实你想反了。做跨境运营，链表这个概念更像是一个"认知税"。
咋说呢，你问这个问题就说明，你遇到瓶颈不是技术问题，是信息筛选问题。我 2022 年刚入行时也追过这个，看了三天"链表 vs 数组"的博客，感觉自己能去写操作系统了。结果呢？后来优化订单处理，发现瓶颈在 API 调用次数限制，关了并发重试就好了。
宝藏认知就是：技术圈的话题，跟你的实际工作隔着两层皮。踩雷就是：别为了追赶技术前沿去学不用学的东西。链表已死，但这个问题对你来说，压根儿不用纠结。

这事我也想问呢。链表就像一个老江湖，江湖地位还在，但新人干活时发现他手里没刀。
我链表就像你去市场买菜，理论上"随时可以插队"（O(1)插入），但实际你买菜得排队付钱（CPU 缓存命中率低）。跨境运营的场景里，数据更多是读、批量处理，不是频繁增删。所以你就当是了解一个历史概念，就跟知道"以前寄国际快递要填很多单子"一样，不用真去手填。
前提是：如果你将来要做高并发系统，比如自建仓储 WMS 的调度模块，那链表还是有用的。但现在嘛，用不着焦虑。

这个其实没那么复杂。链表没死，只是退居幕后了。
你做跨境运营，跟链表最近的一个场景可能是：用链表做订单队列。比如 FIFO（先进先出），实现起来写个 deque 就完事。但问题是，现在 Redis 里有 list，消息队列有 RabbitMQ，谁还手写链表？
要说趋势，2026 年大家更关注的是"数据结构和业务场景的匹配度"。链表在某些场景（比如 LRU 缓存）还是最优解，但对你一个运营来说，你更应该关注的是：你的数据读写模式是什么？是批量还是点查？是追加还是随机？这个问题比"链表死没死"实际一百倍。

你这个数据靠谱吗？"链表已死"这个说法哪儿看的，是十年前的帖子吧？
我 2019 年刚开始做，也刷到过这种技术焦虑文，后来发现直接忽略：你做跨境运营，数据结构深入不了那个级别。你只要知道，Python 里 list 是动态数组，大部分场景够用，想更高效就用 deque 做队列。别被"链表的删除插入 O(1)"这种理论给唬住了，在业务代码里实现起来全是坑。