为什么都 2026 年了，还有人死磕链表做跨境数据处理？性能真的差到离谱

楼上说得对一半，但我觉得链表的锅不能全让计算机背。我补充一点：很多跨境系统里用链表，是因为业务逻辑天然适合啊。
比如订单状态机，经常要插入新状态、删除旧状态，链表在理论层面确实是最直观的。但问题在于，咱们国内搞技术的，喜欢把链表当成"数据结构模板"直接用，根本不考虑现代 CPU 的缓存和预取机制。链表节点的内存分配默认是缝缝补补的，从不连续，所以性能拉胯是命中注定的。
家人们呐，我那会儿在优化一个库存批次处理，原代码用了链表做 FIFO 队列，每次插入都要 new 新节点，跑一次全量更新就崩了。后来我换成 ring buffer（环形数组），就一数组 + 两个头尾指针，性能提升了至少四倍，代码还更短。
真的会谢，那些说链表无敌的教程，应该自己跑个压测再说话。

这事我也想问。链表在跨境场景里真的被用烂了，特别是一些老项目。
我自己 2023 年开始搞备货预测模型，数据流转部分全是自建链表做事件队列。当时觉得链表能快速插入删除，nice。结果数据量从一万到十万的时候，系统直接卡住，因为每次查找都要 O(n)，更关键的是，跨内存页访问导致页错误，操作系统都快被整疯了。
后来我去读 A 家那本《系统性能》的书，才明白为什么现代推荐用数组和 vector。链表在虚拟内存体系里，每个节点可能分布在不同的物理页上，TLB 和 page table 都扛不住。一个简单的遍历，TLB miss 率能到 30%-40%，CPU 白费这么多时钟周期在那查页表。
所以别纠结链表本身了，除非你做的数据量极小（几千级别），否则真不推荐。

我刚看到这个话题想的是，其实你想反了。链表在现代计算机体系里，不是理论活不了，是工程上真的不听话。
我自己的经验，2025 年接了一个订单流转的项目，数据量大概每天三十万单，原有结构就是双链表。当时想着链表插入删除 O(1) 很爽，结果一压测，处理时间从 2 秒直接飙到 90 秒。原因很简单，链表的内存访问模式贼差，每次遍历都是跳来跳去，CPU 缓存完全失效。链表每个节点的 next 指针都是随机地址，这就相当于你每次读完一个节点，CPU 预读的下一段缓存全部是错的，全得重加载。
我当时换成了数组 + 预分配内存的方案，同一批数据，处理时间降到 8 秒以内。从 90 秒到 8 秒，哪个更香你品。
所以不是链表理论不行，是 CPU 缓存这层物理现实不给面子。