乐悠厨房上一章我们把算法的基础招式过了一遍，从时间复杂度到递归思想，算是给编程内功打了个地基。但每次聊到算法，总绕不开一个前置话题：数据到底用什么结构来组织。这就像你学做菜，刀工火候是招式，但食材怎么切、怎么摆盘，直接决定这道菜能不能成。很多读者跑来问我说，数组、链表、栈、队列、树、图这些东西单独拎出来都认识，一放到实际项目里就懵了，不知道谁该在什么时候出场。这一章，我就把数据结构这件事摊开来讲，做一次彻底的"大比拼"——不光是比概念，更要比它们的脾气秉性、适用场景，以及在真实工程里的取舍逻辑。
先说清楚这篇文章适合谁。如果你正在准备考研、期末复习数据结构，刷题时被"这题用栈还是队列"卡住，或者工作写业务代码时隐约觉得某个结构能优化性能却说不清怎么选，那这章就是给你写的。我会拿真实项目里的案例来拆，而不是只念教科书上的定义。整章读完，你至少能回答三个问题：每种数据结构到底擅长什么、不擅长什么；现实中遇到具体需求时该用什么标准去选；以及大厂面试和考研题目背后真正想考察的那层东西是什么。
1. 数组与链表：最基础的一对冤家，底层逻辑完全不同
每次讲数据结构，我都愿意从数组和链表这对冤家开场。不是因为它们简单，而是因为几乎所有的复杂结构到最后都建立在它们之上——树可以用链式节点实现，哈希表可以用数组加链表实现，图可以用邻接表实现。所以把这对关系吃透，后面全是顺水推舟。
1.1 连续内存和离散节点：CPU缓存泄露的真相
数组最大的特点就一句话：一片连续内存，下标即地址。你在数组里访问第三个元素，本质上是拿着起始地址加偏移量直接去内存里取，所以不管数组多大，访问任意一个下标的时间都是 O(1)。这个特性在面试里很少有人会追问到硬件层，但实际性能差异恰恰藏在这里。
现代 CPU 读取内存不是一次取一个字节，而是按缓存行（通常 64 字节）批量加载到高速缓存里。数组是连续的，遍历时前几个元素已经被加载进缓存了，后面几个几乎是白送的速度。链表呢？每个节点可能散落在内存的各个角落，一个节点存的是数据加指针，你访问下一个节点时大概率要重新走一遍内存寻址，缓存命中率天然吃亏。我见过不少性能调优案例，单纯的顺序遍历场景下，数组比链表快五倍到十倍一点都不稀奇，这个差距和语言无关，C++、Java、Go 表现都一样。
链表的核心优势是插入和删除的灵活性。只要你已经拿到了目标节点的位置，修改前后两个节点的指针就能完成操作，不需要像数组一样搬动后面所有元素。注意我刚才说的前置条件——"已经拿到节点位置"。这是个巨大的前提，因为链表想拿到某个节点，得从头一个个找，这是 O(n) 的开销。所以很多时候，链表的"插入快"只是片面的说法，得看整体场景。
1.2 时间复杂度只是表象，实际工程里的取舍更复杂
教科书上通常给这样一张对比表：
| 操作 | 数组 | 链表 |
|---|---|---|
| 随机访问 | O(1) | O(n) |
| 头部插入 | O(n) | O(1) |
| 尾部插入 | O(1)（可能触发扩容） | O(1) |
| 中间插入 | O(n) | O(1)（已知位置） |
| 查找 | O(n) | O(n) |
但这张表容易让人产生一个误解，觉得数组一无是处、链表很全能。实际工程里根本不是这么回事。举两个例子。
第一个例子是 Java 的 ArrayList 和 LinkedList。很多人凭直觉认为 LinkedList 插入性能好，所以在"频繁插入"的场景选它。但实测下来，元素量在一万到十万这个量级时，ArrayList 的综合表现往往优于 LinkedList——因为 ArrayList 虽然插入可能要搬元素，但搬的是连续内存，memcpy 这种底层操作极其快；而 LinkedList 每个节点都是独立 new 出来的对象，内存碎片化、缓存不友好、GC 压力大，这些开销肉眼看不见，跑起来却是实打实的慢。所以 Java 官方和社区的主流意见都是：99% 的列表场景直接用 ArrayList。
第二个例子是 Redis 的列表（List）。Redis 的老版本用的是双向链表，后来换成了 quicklist——一种以压缩列表为节点、再用双向链表串起来的混合结构。为什么要这么干？因为纯链表节点太多，每个节点都背着前后指针，内存浪费大；而压缩列表能在连续内存里压一堆元素，省空间、缓存又好。Redis 团队的选择说明了一个道理：真正常用的方案往往是多种结构的组合，而不是非此即彼。
1.3 数组和链表的选型心法
我自己的选型标准可以总结成几句大白话：
- 如果你要频繁按下标访问元素，或者数据量不大但遍历是主操作，无脑数组。
- 如果你要在头部、尾部分别频繁操作，或者根本不知道数据总量有多少，才考虑链表及其变体。
- 如果元素本身是小对象能塞进缓存行，数组优势更大；如果元素是复杂对象，链表反而少一点搬移开销。
另外补充一个很实用的小技巧：在 JavaScript 里 shift() 操作数组头部节点会导致全部元素前移，O(n) 的复杂度，如果你在写高频头部操作的代码，别硬用数组，用链表或者倒序存储都行。这就是教科书概念落到真实代码里的意义。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 栈与队列：规则最简单的结构，应用场景却无处不在
很多新手不理解，为什么栈和队列这种"限制一堆"的结构反而被单拎出来讲。我打个比方：数组和链表像是一个开放的仓库，什么都能存、存取方式随意；而栈和队列是你给仓库装上了门禁，只留下一个入口或者两个固定的进出口。表面上看自由被剥夺了，但恰恰是这个限制，让它们能承担某些特定场景的职责，还能把复杂度牢牢锁住。
2.1 栈：后进先出的世界，比你想象的更底层
栈的规则只有一句话：先进后出。就像一摞盘子，你先放的会被压在最下面，后放的反而最先被拿走。别小看这个规则，整个程序运行都离不开它。
函数调用就是最经典的栈应用。你写一个递归函数，每一层调用的局部变量、返回地址都会被压入调用栈，返回时再逐层弹出。一旦递归层数太深，栈空间耗尽，就出现"爆栈"——你看到的 Stack Overflow 报错其实是字面意义上的栈溢出。理解这一点，你就能明白为什么有些递归可以改循环、有些很难改，也能明白为什么很多语言的默认调用栈大小设置了上限。
除了函数调用，栈还活跃在以下场景：
- 编译器和解释器的表达式求值：
1 + 2 * 3中运算符优先级的处理，就是两个栈（操作数栈、运算符栈）配合的结果。 - 括号匹配校验：编辑器检查你写的代码括号是否成对，用的就是栈，遇到左括号压栈，遇到右括号弹栈，最后栈空则合法。
- 浏览器的前进后退、编辑器的撤销历史：每次新页面入栈，后退就是出栈，前进则是另一个栈来配合，这就是双栈实现。
算法题里栈也几乎是万能工具。比如单调栈，专门用来求"下一个更大元素"这类问题，力扣上有分量的题都用它；再比如最小栈，用两个栈维护，一个存数据、一个存当前最小值，就能 O(1) 拿到栈内最小值。刷题多的同学应该对这些不陌生。
2.2 队列：先进先出，后端系统的心脏
队列的规则是先进先出，就像排队买奶茶，先来的先服务。队列在后端系统里的地位，怎么强调都不过分。
就拿消息队列来说，它在系统设计中承担的是"削峰填谷"的角色。突发流量瞬间到访时，查询请求写进队列，后面由 worker 慢慢消费，而不是直接打到数据库上把数据库打死。这种模式你天天都在用，只是不一定意识到底层数据结构就是队列。
再一个例子是线程池。线程池里等待执行的任务放在队列里，线程空闲了就从队头取任务执行。Java 的 ThreadPoolExecutor 里，如果核心线程满载、队列未满，新任务会先入队等待；如果队列也满了，才会触发拒绝策略。这个队列选型直接影响系统的行为：LinkedBlockingQueue 默认无限长度，适合不在乎排队延迟的场景；ArrayBlockingQueue 有界，适合希望快速降级或拒绝的场景。
队列还有个近亲叫优先队列，底层通常不是普通队列，而是堆（后面详细讲）。它的规则是"谁优先级高谁先出"，而不是先进先出。这在任务调度里太常见了——操作系统的进程调度、网络包队列的优先级处理，都是优先队列的天下。
2.3 双端队列和单调队列：两个实用的变体
双端队列（Deque）就是两端都能插入和删除，它融合了栈和队列的能力。Java 官方也建议，如果你要当栈用，优先用 Deque 而不是 Stack 类——Stack 继承自 Vector，老且线程同步开销大，实际性能不及 ArrayDeque。这是一个很小的细节，但面试和实际编码中都可能会用到。
单调队列则是算法刷题中的强兵。典型场景是滑动窗口最大值问题：给你一个数组和一个窗口大小，要求窗口每次右移时输出窗口内的最大值。暴力解法每次扫描窗口 O(nk)，数据一大就废了；而用单调递减队列，维护窗口内的候选最大值序列，可以把整体优化到 O(n)。这类题的思路是：队列里不必要保留后进来的小值，因为它们永远不可能成为当前或未来窗口的最大值。这种"排除永远不可能的元素"的思维，在算法优化里是绕不开的一招。
3. 树：从一维思维切换到二维思维，查找效率质的飞跃
如果说数组、链表、栈、队列都是线性结构，那从树开始你就进入了非线性结构的世界。树包含的形态太多了：二叉树、二叉搜索树、平衡树、红黑树、B 树、堆、并查集……如果逐个展开，写一本书都不够。这一节我只把最常见、最可能出现在面试和工程里的几种摆上台面，做一个横向比较。
3.1 二叉树和二叉搜索树：为什么树能这么快
先回答一个基础问题：为什么要用树？最直接的原因是查找效率。线性结构哪怕用二分查找，前提也是数组有序，而且插入删除都要搬移元素。树则把"二分"的思想直接变成了结构本身：一棵二叉搜索树（BST），左子树所有节点都小于根节点，右子树所有节点都大于根节点，查找时每次比较后直接丢掉一半的搜索空间，复杂度 O(log n)。
但这个复杂度有个大前提：树是平衡的。如果你按 1、2、3、4、5 的顺序往 BST 里插入节点，你会得到一棵斜树，退化成链表，查找又变回 O(n)。这就是为什么工程里很少直接用裸的 BST，而是用带自平衡机制的变体。
3.2 AVL、红黑树和 B 树：平衡策略如何进化
AVL 树是最早的自平衡二叉搜索树，它的规则是任何节点的左右子树高度差不能超过 1，一旦超过就通过旋转（左旋、右旋、左右旋、右左旋）来纠正。AVL 的优点是严格平衡，查询性能极其稳定；缺点是调整太频繁，插入删除时旋转次数多，写操作场景下开销大。
红黑树是另一种平衡策略，它不追求严格的高度平衡，而是用颜色标记和几条固定规则维持"最长路径不超过最短路径的两倍"这个近似平衡。红黑树的查询略慢于 AVL，但插入删除的旋转次数少很多，综合读写性能更均衡。所以你看 Java 8 的 HashMap，在单个桶里元素超过 8 个时，链表会转成红黑树——就是为了防止哈希冲突极端情况下链表过长导致的性能劣化。还有 Linux 内核的 CFS 调度器、C++ 的 std::map，底层都是红黑树。
B 树和 B+ 树是树结构在磁盘场景下的主力。它们的核心思想是"一个节点存多个键值"，把树的高度压得很低，这样一次磁盘 IO 能读出更多有效数据。数据库索引九成以上用 B+ 树，原因在于 B+ 树的叶子节点串成了有序链表，范围查询（比如 WHERE age BETWEEN 20 AND 30）只要找到起点后沿链表顺序读就行，这对数据扫描类操作是致命的优势。MySQL 的 InnoDB 引擎索引结构就是这个套路，面试官只要问索引原理，大概率会扯到 B+ 树，你一定要明白它和 B 树的区别在哪儿。
3.3 堆：一种特殊的完全二叉树，却是优先队列的基石
堆在日常生活中不怎么出现在讨论里，但只要你用过优先队列，就是在用堆。堆是一棵完全二叉树，并且满足堆序性：大顶堆任意节点的值不小于其子节点，小顶堆则相反。它不是用链表结构存的，而是直接放在数组里，通过下标关系找父子节点——节点 i 的左孩子是 2i+1，右孩子是 2i+2，父节点是 (i-1)/2。这种存储方式让堆兼具了树的查找效率和数组的紧凑布局。
堆的典型操作复杂度：
| 操作 | 时间复杂度 |
|---|---|
| 获取最大/最小值 | O(1) |
| 插入元素 | O(log n) |
| 删除最大/最小值 | O(log n) |
| 建堆 | O(n) |
堆排序就是基于这个结构设计的：建堆 O(n)，每次取出堆顶 O(log n)，n 次取完，整体 O(n log n)，且不需要额外的大量辅助空间。后面讲排序算法时我会再展开，这里先记住堆的定位：当你需要频繁拿"当前最大或最小"并且数据还会不断更新时，堆是你的第一选择。比如排行榜、Top K 问题、定时任务调度，都是堆的用武之地。
3.4 树的对比表与选型清单
我把常用的树结构拉一张对比表，方便你复习和面试前突击：
| 结构 | 平衡方式 | 查询复杂度 | 插入复杂度 | 典型应用 |
|---|---|---|---|---|
| BST | 无 | 平均 O(log n)，最差 O(n) | 平均 O(log n)，最差 O(n) | 教材、入门练习 |
| AVL | 严格平衡 | O(log n) | O(log n) | 读多写少、追求查询稳定 |
| 红黑树 | 近似平衡 | O(log n) | O(log n) | HashMap、std::map、调度器 |
| B+ 树 | 多路平衡 | O(log_m n) | O(log_m n) | 数据库索引、文件系统 |
| 堆 | 完全二叉树 | 仅最大/小值 O(1) | O(log n) | 优先队列、TopK |
选型心法也很简单：追求稳定查询用 AVL；读写均衡、工程落地选红黑树；数据量大到放硬盘或数据库索引，B+ 树；要动态求最大最小值，堆。
4. 哈希表：用空间换时间的极致，以及它的两个经典变种
哈希表是数据结构里最能体现"空间换时间"思想的家伙。它借助一个哈希函数，把任意长度的输入映射到固定长度的索引，从而实现 O(1) 级别的查找、插入、删除。但哈希表不是毫无代价的，哈希冲突、扩容、负载因子这些问题，都是它绕不开的坎。
4.1 哈希冲突处理方式：链地址法和开放寻址法
哈希函数再精巧，也不可能让所有输入都映射到不同索引上——因为输出空间通常小于输入空间。当两个 key 映射到同一个槽位，就发生了哈希冲突。处理冲突的主流方式有两种。
链地址法：每个槽位挂一个链表，冲突的元素挂到同一个链表后面。这是 Java HashMap 的做法，简单直观，但在冲突严重时链表过长会拖慢查询，所以 Java 8 引入了树化逻辑——链表长度超过 8 且数组容量大于 64 时转红黑树。工程里这个阈值不是随便定的，它综合了链表节点和树节点的内存占用、查找平均长度等因素，是大量实测后得出的折中值。
开放寻址法：冲突时按某种规则探测下一个空闲槽位，比如线性探测、二次探测、双重哈希。它的好处是没有额外的链表结构，内存紧凑、缓存友好；缺点是负载因子变高时探测次数急剧增加，性能像雪崩一样下滑。Redis 的字典用的就是开放寻址法的变种，配合渐进式 rehash，把扩容的耗时打散到多次操作中，避免了一次性大迁移造成的卡顿。
4.2 负载因子和扩容：哈希表性能的隐形开关
负载因子（load factor） = 已存储元素数量 / 槽位总数。负载因子越高，冲突概率越大，查找性能越差。Java HashMap 的默认负载因子是 0.75，超过这个值就触发扩容，容量扩大为原来的两倍，并重新哈希所有元素。0.75 这个值的来历，跟链地址法下"桶中节点数量服从泊松分布"的数学推导有关——在 0.75 的阈值下，单个桶里挂 8 个节点的概率已经极低，所以树化的阈值选 8 是有理论依据的。
这里我要特意提醒一句：如果面试官问你为什么是 0.75，别只会背数字，能讲讲泊松分布的推论会更有说服力。如果你能顺手提一句"负载因子调小一点能降低冲突但浪费内存，调大一点省内存但可能拖慢查询"，说明你是真的理解了哈希表的取舍。
4.3 哈希表与树形结构的选型之争
哈希表查询是 O(1)，红黑树查询是 O(log n)，表面看哈希表完胜，但实际选型根本没这么简单。
哈希表最大的短板是无序。你想查某个区间内的所有元素，哈希表只能把所有元素遍历一遍；而红黑树（或 B+ 树）天然有序，可以走中序遍历或者范围查询。另外，哈希表需要预分配桶数组，内存开销在数据量小的时候比红黑树明显；哈希函数的计算也有成本，数据量很小的时候这个固定成本可能让哈希表反而比树慢。
所以我的经验是：只需要按键存取、不关心顺序，数据量中等偏大，选哈希表；需要范围查询、排序输出、或者稳定的最坏情况复杂度，选平衡树。语言内置的集合结构也体现了这个思路——Java 的 HashSet 和 TreeSet、Python 的 set/dict 和 bisect 模块、Go 的 map（哈希实现）和没有内置的树集合，每个语言都给你留了选择的余地。
5. 图：关系数据的终极建模方式，不在话下
图可能是线性结构和树结构之外最难的一类，但只要你处理的是"多对多"关系的数据，图就绕不开。社交网络的好友关系、地图导航的路网、推荐系统的用户和商品关联，本质都是图。
5.1 邻接矩阵与邻接表：存储结构的取舍
图的存储主要有两种方式。邻接矩阵用一个 n×n 的二维数组表示节点间是否有边，判断两点是否相邻是 O(1)，但空间占用是 O(n²)——当节点数上万时，这个矩阵基本就是天文数字，而且大多数图是稀疏的（边远少于 n²），矩阵里大量空间被浪费。
邻接表则给每个节点挂一个链表（或用数组实现），存储它直接相连的邻居。空间占用是 O(V+E)，V 是节点数，E 是边数。遍历一个节点的邻居平均代价是 O(度)，非常适合稀疏图。代价是判断两个节点是否直接相连时，需要去链表里找，平均 O(度)。现实中绝大多数图都是稀疏的，所以工程里邻接表远远比邻接矩阵常用。
5.2 深度优先和广度优先：两种扫图思维
DFS 和 BFS 是图遍历的两把刷子，它们的应用场景完全不同。
DFS 顺着一条路走到黑，碰壁再回头。适合做连通性检测、拓扑排序、回溯法解迷宫、检测图中是否有环。它的实现既可以用递归（隐式栈），也可以用显式栈来模拟，避免递归层数过深。
BFS 一层一层向外扩散，天然具备"最短路径"的性质——在无权图中，从起点出发第一次到达目标节点的路径就是最短路径。经典应用包括网络爬虫的逐层抓取、朋友圈中"共同好友"的找法、迷宫问题中的最短步数。BFS 用队列实现，这也是我在前面讲队列时提到的应用场景之一。
需要注意的一点是：LeetCode 上很多"最短路径"问题默认是无权图，用 BFS 就能解；一旦图加了权重，就要升级成 Dijkstra 算法（基于优先队列的贪心）或者 A* 搜索。很多初学者会在这几个算法之间迷路，我建议你按"无权 BFS → 带权 Dijkstra → 启发式 A* → 动态规划"这条线循序渐进地学。
6. 大比拼总决选：一份能直接抄作业的数据结构选型指南
前面的内容可以说是"选手介绍"，这一节才到"裁判环节"。实际项目中，要在一堆结构里选出最合适的那个，不能靠感觉，而应该问自己四个问题。
第一个问题：核心操作是读还是写？ 读多写少优先考虑数组、AVL、有序数组二分；写多读少优先考虑链表、跳表、哈希表。读多写少和写多读少，对结构的要求完全不同，很多选型在第一步就能定位。
第二个问题：需不需要保持顺序？ 需要按某种规则排序输出，优先二叉树、跳表、B+ 树；只需要按键存取，哈希表就够了；只需要维护最大最小值，堆。
第三个问题：数据量有多大？ 数据量小到几千时，任何高级结构的优化都体现不出来，反而简单结构更省心；数据量到百万千万级，你才会真正感受到 O(log n) 和 O(n) 的天壤之别。数据量大到放不下内存，必须考虑磁盘友好型结构，数据库索引方向就该往 B+ 树上靠。
第四个问题：是否存在特殊的访问模式？ 后进先出用栈，先进先出用队列，全局取最值用堆，找关系路径用图。这一条看起来简单，但它能帮你把问题定性。
我直接给一份决策表：
| 需求场景 | 推荐结构 | 原因 |
|---|---|---|
| 按下标随机访问、遍历 | 数组 | O(1) 访问，缓存友好 |
| 频繁头部/中间插入删除 | 链表 | O(1) 改指针 |
| 函数调用、表达式求值、括号匹配 | 栈 | 后进先出语义 |
| 任务排队、消息缓冲、BFS | 队列 | 先进先出语义 |
| 动态取最大/最小值、TopK | 堆 | O(1) 取极值，O(log n) 更新 |
| 键值存取、去重判断 | 哈希表 | 平均 O(1) |
| 范围查询、有序输出 | 二叉搜索树/B+树 | 天然有序 |
| 社交关系、路径规划 | 图 | 多对多关系 |
6.1 两个经典的组合拳案例，帮你建立"结构组合"的直觉
真实系统很少只靠一种数据结构打天下，更多是组合出招。我挑两个最经典的案例来说。
案例一：LRU 缓存淘汰算法。 LRU 要求每次访问一个 key 后，这个 key 变成"最近使用"，淘汰时把最久没用的删掉。如果只用哈希表，可以 O(1) 找到但不知道访问顺序；如果只用链表，可以维护顺序却无法 O(1) 定位。标准解法是哈希表 + 双向链表：哈希表的 key 指向链表节点，链表按访问时间排序。访问一个 key 时，通过哈希表找到节点，把它移到链表头部；淘汰时直接删除链表尾部节点。这样查询、插入、删除全部 O(1)。这个设计在 Redis 的缓存淘汰、操作系统页面置换里都能见到，面试现场手写过的人都知道它的精巧。
案例二：Redis 的有序集合。 Redis 的 ZSET 需要同时支持按键取分值、按分值排序、范围查询，单靠哈希表做不到有序，单靠跳表又做不到 O(1) 直接定位成员。Redis 的解法是哈希表 + 跳表双结构配合：哈希表负责按成员名取分值，跳表负责按分值排序和范围查找。所以你在 Redis 文档里会看到一句提示，ZSET 的底层数据结构是 skip list 和 hash table 的组合。这种"一个数据结构不够，就两个叠加"的思路，是工程里极其重要的心法。
6.2 考研和面试最爱考的那几个坑，我一次帮你填平
既然是"数据结构大比拼"的章节，我最后把面试里最常见的几个考点也串一遍，这些点每年都能难倒大批人。
第一，数组和链表的区别。别只说"数组访问快、链表插入快"。加上缓存局部性、内存碎片、扩容开销、是否已知插入位置这些因素，你的答案立刻和其他人拉开差距。
第二，栈和队列的区别，以及各自至少三个应用场景。这个如果只说"一个后进先出、一个先进先出"就太单薄了。函数调用、浏览器后退、括号匹配、消息队列、线程池、BFS，这些是面试官想听到的内容。
第三，哈希表中为什么链表长度超过 8 要转红黑树。这个问题的完整答案是：链表查询 O(n) 太慢，树化后 O(log n)，同时超过 8 表示冲突已经极端严重，树化是必要的兜底；而 0.75 负载因子下 8 个节点出现的概率极低，所以这个阈值设置合理。
第四，B+ 树和 B 树的区别。B+ 树非叶子节点不存数据，只做索引，所以单节点能容纳更多键，树更矮；叶子节点用链表串成有序序列，范围查询效率高。背下这两条，数据库索引的题基本稳了。
第五，手写一个链表反转或者用两个栈实现队列。这类题考的不是你背没背过，而是你是否真正理解了指针和结构之间的交互。我建议你合上文章，自己先在纸上画一遍过程，再动手写代码，写完再画一遍，反复三轮，比看十遍答案都管用。
数据结构这个东西，说到底就是一套"取舍"的学问——没有绝对的好坏，只有合不合适的场景。数组放弃灵活性换来访问速度，链表放弃连续性换来插入自由，哈希放弃顺序性换来平均 O(1)，树则用平衡操作的代价换来稳定的对数级别查询。你在任何一个项目里做的数据结构选型，本质上都是在回答"我到底更在意哪一项性能指标"。把这些底层逻辑吃透了，刷题、面试、写工程代码，都会顺畅很多。
最后分享一个个人的教学体会：我见过太多人背了一堆数据结构定义，遇到具体题目还是不会用。原因很简单，他们从来没有亲手画过一棵树插入时的旋转过程，也从来没有在项目里观察过 ArrayList 扩容带来的停顿。所以我特别建议你，学到这里别急着往下走，打开 IDE 或者几张白纸，把数组、链表、栈、队列、哈希表、堆、树、图这八种结构各写一个最小可运行的例子，再试着把 6.1 里的 LRU 和 ZSET 组合方案自己实现一遍。写不出来就看答案，看完再写，写到能默写为止。数据结构这一关过了，后面的排序、查找、动态规划学起来都是降维打击。这一章到这里，下一章我们正式进入排序算法的地盘。