C++容器适配器stack与queue：从底层原理到实战应用

不知道你在刷题或者做工程的时候有没有过这种感觉——需要临时存一批数据，后进先出；需要排队处理任务，先进先出。大部分人第一反应是去数组或者链表里自己维护一个结构，写一半才发现边界条件一堆，bug藏得深。其实C++标准库早就把这两种常用结构包装好了，就是stack和queue。我见过不少写了两年代码的同学，提到stack就只知道push和pop，提到queue就只会在BFS里用一下，遇到稍微复杂的场景就绕回原生数组。这篇文章就按我自己的学习路径和实战经验来拆解这两个容器适配器，从接口语义到底层机制再到高频应用场景，尽量让新手少走弯路，也让有基础的朋友能补上平时忽略的细节。

1. 栈与队列的本质区别：容器适配器到底适配了什么

1.1 先从数据结构角度看明白它们的“性格”

栈和队列在数据结构课里就是两种线性表，限制不同：栈只允许在一端插入和删除，队列只允许在一端插入另一端删除。十个人里有九个能背出“LIFO”和“FIFO”，但真正到代码层，容易忽略的是C++里stack和queue并不是从零实现的数据结构，而是建立在已有容器之上的一层“策略外壳”。官方术语叫container adapter，也就是容器适配器。这句话信息量很大——它们不负责管理内存，不提供迭代器，也不开放底层存储的访问方式，只暴露一组严格受限的操作，至于数据到底放在哪、怎么放，交由底层容器去解决。

这个设计带来的第一个好处就是使用门槛极低，你不需要关心扩容逻辑、指针维护或者内存对齐，把元素丢进去就行。第二个好处是灵活，如果你对当前底层容器的性能不满意，可以随时换成另一个满足要求的容器，接口完全不用改。第三个好处我认为最容易被忽视——它把数据结构本身的语义固化下来，写代码的人不容易犯错。比如你在函数调用或者表达式求值的时候，如果直接用一个vector然后自己控制头部和尾部，很容易在某次逻辑调整中忘记维护索引，而stack的操作边界清晰，误用概率大大降低。

1.2 默认底层容器deque：为什么不是vector也不是list

stack和queue的默认底层容器都是deque（双端队列），新手经常会问：为什么不是vector？又是为什么不是list？这背后有很实际的性能考量。

先看vector。vector的特点是从尾部插入和删除是O(1)均摊，但从头部插入或删除是O(n)，因为所有元素都要移动。队列的需求是两端操作，一头进另一头出，vector显然满足不了头部高效操作的需求。再看list。list的头尾操作都是O(1)，似乎很适合队列。但list的节点是分散在堆上的，每个节点有额外的指针开销，缓存局部性差。遍历或者频繁访问元素的时候，cache miss会吃掉不少性能，而且单个节点的内存占用也比连续存储大不少。

deque则是个折中方案：逻辑上是连续的，实际由一段段定长缓冲区块拼接而成，类似“分段连续”。头部和尾部都能以O(1)时间插入删除，中间插入慢，但栈和队列本来就不需要中间插入。同时deque的内存访问对缓存还算友好，虽然没有vector那种绝对连续带来的极致缓存性能，但比list强得多。所以标准库选择deque作为stack和queue的默认底层容器，是综合了操作复杂度和缓存友好度的结果，不是随便选的。

如果让你自己造一个栈或者队列，比如写算法题图方便，直接用vector也能模拟栈，自己维护一个栈顶指针即可，但queue用vector模拟队头操作就会很别扭。这个细节我放在后面“自定义底层容器”那一节详细讲。

1.3 stack与queue的接口对比：一次看全

很多人对stack和queue的接口记忆是混乱的，尤其容易把front、back、top搞串。我整理了一个常用接口对比表，按stack和queue分开列，看完这个表再去写代码会清爽很多。

需要注意stack只有top一个口子，queue有front和back两个口子。stack的top返回的是栈顶元素的引用，queue的front返回队头元素引用，back返回队尾元素引用。引用类型保证不会复制元素，这也是C++里操作容器元素的高效方式。

另外一个常见疑问是：为什么pop不返回被删除的元素？这是很多刚从其他语言转过来的朋友会问的。原因是返回值和删除操作放在同一个函数里，一旦返回值构造失败，元素已经从容器里删掉了，数据就丢失了。C++的容器设计理念是把不变量尽量做安全。所以标准做法是先用top或者front取到元素，再调用pop删除。如果你只需要“扔掉栈顶元素”，那就直接pop。

2. 手写核心用法：构造、入栈出栈与数据访问的实用细节

2.1 构造方式的几种选择与底层容器切换

stack和queue的构造方式很简单，默认构造就是空容器，底层容器为deque。但如果你明确知道应用场景需要不同的底层结构，可以在构造时传入一个已有的容器对象作为参数。比如你手头有一个vector已经存了一批数据，想让它变成栈，不复制一份的话，可以像这样初始化：

#include <stack> #include <vector> #include <queue> #include <list> std::vector<int> vec = {1, 2, 3, 4, 5}; std::stack<int, std::vector<int>> stk(vec); // 此时栈顶是5，底层是vector，栈的大小是5 std::list<double> lst = {1.0, 2.0, 3.0}; std::queue<double, std::list<double>> que(lst); // 此时队头是1.0，队尾是3.0

这里第二模板参数就是底层容器的类型。stack要求底层容器支持back()、push_back()、pop_back()；queue要求支持front()、back()、push_back()、pop_front()。因此并不是所有容器都能作为这两个适配器的底层。比如vector可以作为stack的底层容器，因为支持back操作和尾插尾删；但vector不能作为queue的底层容器，因为它没有pop_front()。list两者都可以。deque两者都可以。

构造时如果什么都不传，默认就创建一个空适配器。C++11开始支持直接从另一个stack或queue拷贝构造、移动构造，日常用默认构造然后push的场景最多，特殊需求再考虑从容器或从另一个适配器构造。

2.2 push、pop与top/front/back的正确打开方式

先写一段最小示例，感受一下两个容器的操作手感。

#include <iostream> #include <stack> #include <queue> int main() { std::stack<int> stk; stk.push(10); stk.push(20); stk.push(30); std::cout << "栈顶: " << stk.top() << std::endl; // 30 stk.pop(); std::cout << "弹出后栈顶: " << stk.top() << std::endl; // 20 std::cout << "栈大小: " << stk.size() << std::endl; // 2 std::queue<int> que; que.push(100); que.push(200); que.push(300); std::cout << "队头: " << que.front() << std::endl; // 100 std::cout << "队尾: " << que.back() << std::endl; // 300 que.pop(); std::cout << "弹出后队头: " << que.front() << std::endl; // 200 return 0; }

这段代码信息量不大，但操作范式是固定的：修改数据用push/pop，查看数据用top/front/back。这里要特别提醒新手，top和front返回的是引用，不是拷贝。这句话意味着你可以通过top直接修改栈顶元素，比如：

stk.top() = 99; // 栈顶值直接从30变成99，不需要先pop再push

同理，que.front() = 55;可以修改队头元素。这在某些场景下很实用，比如在BFS里需要修改队头顶点状态后再决定是否扩展。不过你要小心，引用在pop之后就会失效，不能再使用。

另外，pop()不会返回任何值，而且调用pop()之前必须确认容器非空，否则是未定义行为。你在刷LeetCode或者写工程代码时一定要养成好习惯：先empty()判断，再top()或front()访问，最后pop()。如果刻意省掉判断，一旦容器是空的，崩溃和随机数据都有可能出现，而且非常难排查。

2.3 emplace与push：构造效率差异背后的原理

C++11引入了emplace，stack和queue都支持emplace，与push的区别在于参数传递方式。push接收的是一个已经构造好的元素对象，形参类型就是元素类型本身；而emplace接收的是元素构造函数的参数包，直接在容器内部完成构造，省去了临时对象的创建和移动或拷贝。

举个例子，如果你的栈元素是一个自定义结构体：

struct Task { int id; std::string name; Task(int i, std::string n) : id(i), name(std::move(n)) {} }; std::stack<Task> taskStack; taskStack.push(Task(1, "write report")); // 构造临时对象，再移动进栈 taskStack.emplace(1, "write report"); // 直接原位构造，少一次移动

第一种写法先构造了一个临时Task，然后移动进容器，临时对象析构；第二种写法直接在栈内部的存储空间上调用构造函数。虽然移动构造通常开销不大，但对于容器频繁入栈的场景，效率差别会被放大。我一般在元素类型是自定义类时优先用emplace，如果是int、double这些基础类型或简单的pair，二者差别可以忽略。

queue同理，que.emplace(...)可以原位构造队尾元素。这个细节属于“技能升级”性质，不会改变代码逻辑，但在高吞吐的服务端代码里，积少成多还是很可观的。

3. 高频实战场景拆解：从括号匹配到广度优先搜索

3.1 用stack完成括号匹配和逆波兰表达式求值

括号匹配是教材里讲栈的经典案例，但很多人只记住了解法，没有理解“为什么栈正好合适”。括号匹配的核心逻辑是：遇到左括号时，你不知道它对应的右括号什么时候出现，但你知道后出现的左括号要先被匹配。这正好是后进先出。

实现思路非常清晰：

bool isValid(const std::string& s) { std::stack<char> stk; for (char c : s) { if (c == '(' || c == '[' || c == '{') { stk.push(c); } else { if (stk.empty()) return false; char top = stk.top(); if ((c == ')' && top == '(') || (c == ']' && top == '[') || (c == '}' && top == '{')) { stk.pop(); } else { return false; } } } return stk.empty(); }

最后判断stk.empty()这一步很关键，它保证左括号不会多于右括号。很多人写这个函数时只检查到循环结束，忘记最后栈应该为空，导致"(("这样的字符串被错误判定为合法。这不是算法难，是边界意识不够。

逆波兰表达式求值也是同样的道理。表达式由操作数和操作符组成，扫描时遇到数字就入栈，遇到操作符就弹出两个操作数做运算，再把结果压回栈。这里要注意一个细节：弹出时先出栈的是右操作数，后出栈的是左操作数。如果你做减法或除法，把顺序搞反了，结果就会错误。我实习的时候亲手交过一次这样的bug，后来学乖了，弹出两个变量后一定是left = first; right = second;，再left - right。

3.2 用queue实现BFS的层序控制

图的广度优先遍历、树的按层遍历，这是queue最经典的战场。BFS的核心特征是“先发现的节点先扩展”，这与队列先进先出的性质完全匹配。大多数教材里BFS伪代码是这样：

std::queue<Node> que; que.push(startNode); while (!que.empty()) { Node cur = que.front(); que.pop(); for (auto& next : cur.neighbors()) { if (!visited(next)) { visited(next) = true; que.push(next); } } }

但工程里经常需要区分“当前层”和“下一层”，比如统计二叉树每一层的节点数、求二叉树的宽度、处理按层爬楼梯的问题。这个时候queue就体现出比vector手动模拟更好的可读性，你可以在while循环内部用for循环控制当前层：

std::queue<TreeNode*> que; que.push(root); int level = 0; while (!que.empty()) { int levelSize = que.size(); for (int i = 0; i < levelSize; ++i) { TreeNode* cur = que.front(); que.pop(); // 处理当前节点，打印或统计 if (cur->left) que.push(cur->left); if (cur->right) que.push(cur->right); } ++level; }

这里的levelSize必须先存下来，因为你在for循环里不断push新节点，que.size()会一直变，直接用que.size()作为循环边界会导致层序错乱。这个坑我见不少同学踩过，其实只要想明白“队列里混着不同层的节点，必须先把当前层数量快照下来”就不会犯错。

3.3 双栈模拟队列与双队列模拟栈

如果说前面是直接用容器，那双栈模拟队列、双队列模拟栈就是“间接思考”的典型题，面试和笔试都爱考。双栈模拟队列的思路是：用两个栈，一个专门接收元素，一个专门吐出元素。接收栈用来push，吐出栈用来pop，当吐出栈为空时，把接收栈全部元素倒过去，顺序自然反转，就得到了队头在顶部的结构。

class MyQueue { private: std::stack<int> inStk; std::stack<int> outStk; public: void push(int x) { inStk.push(x); } int pop() { if (outStk.empty()) { while (!inStk.empty()) { outStk.push(inStk.top()); inStk.pop(); } } int res = outStk.top(); outStk.pop(); return res; } int peek() { if (outStk.empty()) { while (!inStk.empty()) { outStk.push(inStk.top()); inStk.pop(); } } return outStk.top(); } bool empty() { return inStk.empty() && outStk.empty(); } };

这个结构在LeetCode上属于基础题，但实际价值在于理解“反转顺序”和“分摊复杂度”。每次pop时，出现的“一次性搬运全部元素”操作，均摊到每个元素上其实是O(1)，不是O(n)。所以双栈模拟队列的整体均摊复杂度依然是线性的，并非想象中那么低效。

双队列模拟栈稍微绕一点，核心是：队列的尾部是最后进来的，但栈顶也是最后进来的，两者位置一致，问题是栈要求在队尾删除，队列只能在队头删除。所以每当你需要pop栈顶时，得把队里的元素全部转移到另一个队列，只留下最后一个，然后把那个最后一个元素删除，然后再把剩余元素搬回来，或者在之后的操作中交替使用两个队列保持“非空队列里最后一个元素就是栈顶”的状态。这个思路本质是“用队列的尾部当栈顶，用另一个队列当临时缓冲区”。能把这个题的思路说清楚，说明你对stack和queue的受限操作理解是到位的。

3.4 工程中的任务调度与异步缓冲

写工程代码时stack和queue用得极其频繁，只是很多人不觉得。函数调用栈本身就是栈结构，每次函数调用压一帧，返回时弹一帧；撤销操作在编辑器里就是个栈，文本编辑器Ctrl+Z每一步操作压栈，需要撤销就弹栈。队列则出现在消息队列、任务调度、生产者消费者模型里。比如一个后台网络服务收到大量请求，先把请求塞进一个线程安全的队列，再由工作线程逐个取出处理，这就是queue最常见的工程应用。

有一个容易被忽视的细节：标准库的queue和stack都不是线程安全的，多线程环境下需要自己加锁，或者配合第三方的无锁队列。我在某个内部项目里见过有人直接拿std::queue给多线程任务分配用，结果数据竞争修了一整天才定位到。所以写工程代码时，先问自己：这个容器是否会被多个线程同时访问？如果是，就一定得做同步。

4. 进阶玩法：自定义底层容器与性能优化路径

4.1 底层容器选型对比：vector、deque与list

既然stack和queue的底层容器可以替换，那就需要了解不同容器的操作代价，才能在实际场景中做出正确选择。我整理了一张对比表，从栈和队列关心的角度分析。

这里需要解释一下为什么vector对栈依然是不错的选择。vector的top操作就是back()，O(1)且连续内存中访问速度极快。push_back均摊O(1)，因为扩容时虽然要搬运，但扩容是按倍数增长的，平均每次插入仍接近常数。如果你对栈的读取频率远高于写入，或者元素量很大且对缓存敏感，vector做栈底容器可能性能优于默认的deque。不过要小心一个问题，vector没有pop_front，所以不能用于queue。

list虽然两端操作都是O(1)，但每个节点需要额外的prev和next指针，通常至少两个指针占16字节，加上节点分配可能在堆上不连续，实际性能往往不如deque。我在一个需要频繁创建和销毁任务节点的项目里对比过，list作为queue底层的吞吐量比deque低大概百分之十到百分之二十，内存碎片也更严重。所以换成list前一定先压测，不要凭感觉。

4.2 自定义类型作为元素时的注意事项

元素是int或者string时，用stack和queue没什么好操心的。一旦换成自定义类型，就有几个注意点。

第一是元素的可拷贝性与可移动性。stack和queue在push时可能触发拷贝构造或移动构造，如果类型是只可移动不可拷贝的，比如std::unique_ptr，那push就必须传右值：

std::stack<std::unique_ptr<Task>> stk; stk.push(std::make_unique<Task>(1, "job")); // 或者 stk.emplace(new Task(1, "job")); // 谨慎使用裸指针

第二是自定义类型需要定义比较运算符才能使用stack和queue的==、<这些比较操作，否则编译器会报错。标准库对容器适配器的比较默认是逐元素调用==和<，没有自定义类型就实现不了。第三，如果自定义类型持有指针或者外部资源，记得自己管理好拷贝和析构，容器只负责存储和释放元素对象本身，不会帮你处理资源语义。

我一般建议在自定义类型中显式定义移动构造函数和移动赋值运算符，标成noexcept，这样vector扩容时才能走移动而不是拷贝，性能差距在大量元素场景下非常明显。比如vector中装了一个包含大量字符串的对象，拷贝每个要复制整个字符串堆内存，移动则只需要交换内部指针。

4.3 priority_queue：队列家族的必知补充

虽然标题只写了stack和queue，但queue这个家族里还有一个很重要成员——priority_queue，优先级队列。它同样是一个容器适配器，默认底层容器是vector，内部维护一个堆结构。用法与queue很像，出队顺序却按优先级而不是入队顺序。

#include <queue> #include <vector> std::priority_queue<int, std::vector<int>, std::greater<int>> minHeap; minHeap.push(5); minHeap.push(1); minHeap.push(9); // top() 返回的是1，因为用了greater，小根堆

priority_queue解决的是“每次取最大或最小元素”的问题，比如任务调度中每次取优先级最高的任务执行、TopK问题、哈夫曼编码等。第三模板参数默认是std::less<int>，对应大根堆，想要小根堆就传std::greater<int>。对自定义类型，需要提供比较仿函数或重载operator<。虽然它是queue家族的一员，但原理更接近堆排序，我在这里提一句是想说明：C++的适配器家族不是只有栈和队列，理解适配器这个概念后，再见到priority_queue之类的新适配器就能很快上手。

4.4 move语义在入栈入队中的性能红利

出栈入栈的性能优化还有一个隐藏点：把左值转成右值再push。比如你已经有一个局部对象，后续不再使用它，完全可以std::move进去，触发移动构造而不是拷贝构造。

std::string bigData = generateData(); taskStack.push(std::move(bigData)); // 大字符串内容被移动而不是深拷贝

移动之后，bigData内部指针变为空，后续不能再访问，除非重新赋值。这个细节我经常建议团队里的初级开发注意：凡是看到push(obj)且obj生命周期即将结束，都考虑一下能不能用std::move。emplace更是直接省去构造临时对象的步骤，从构造源头优化。移动构造的成本基本就是几个指针的搬运，对比字符串大对象的深拷贝，优化效果是非常可感知的。当然，如果是int、double等基础类型，move和拷贝一样，没必要多写。

5. 最容易踩的坑：迭代器、空容器与底层容器错配

5.1 空栈/空队列调用top或front：典型的未定义行为

stack和queue的top、front、back都没有做空容器检查，这是设计就是如此，为了性能不做多余判断。所以空栈上调用top()，或者空队列上调用front()，属于未定义行为——可能是返回一个垃圾值，也可能是直接段错误，取决于实现和运行环境。这个问题的恐怖之处在于，它在debug模式下可能能正常工作，release模式才崩溃，或者反过来。

我在写项目时总结出的习惯是：凡是从栈或队列中取元素，肯定先empty()检查。即使你觉得逻辑上一定有元素，也要在防御性检查上多写一行，出过事故的人才会懂这个习惯有多重要。比如在BFS中，你进入while循环之前已经push了起点节点，所以循环内que.front()理论上是安全的，但在代码评审时，我仍然喜欢看到显式的空判断，因为这能把潜在问题扼杀在早期。

5.2 迭代器缺失带来的使用局限与绕过方案

stack和queue不提供迭代器，这是容器适配器与完整容器的一个重要区别。你不能直接对他们调用std::sort、std::find，也不能用范围for循环遍历。原因很简单，适配器的设计目的就是限制访问方式，只允许按照栈或者队列的规则操作，如果允许任意顺序遍历，栈的LIFO语义就被破坏了。

那如果确实需要遍历栈里的全部元素怎么办？有两种思路。第一种是自己保存底层容器的引用，通过受保护成员对象的方式访问。严格来说stack的底层容器是protected成员，直接继承就可以访问它：

class PrintableStack : public std::stack<int> { public: void print() { for (const auto& v : c) { std::cout << v << " "; } std::cout << std::endl; } };

这里的c就是底层容器的标准名字。通过继承基类的受保护成员，可以看到所有元素。但我不推荐在正式项目里这样做，因为这相当于破坏了适配器的封装约束，而且stack的析构函数不是虚的，继承要小心多态删除问题。更稳妥的方案是，把元素全部弹出来访问后再放回去，虽然性能差一些，但语义安全：

std::stack<int> temp; while (!stk.empty()) { int cur = stk.top(); stk.pop(); // 访问cur temp.push(cur); } while (!temp.empty()) { stk.push(temp.top()); temp.pop(); }

如果你的遍历需求非常频繁，可能要想一想：是不是数据结构选错了？可能用vector自己做栈管理反而更合适。

5.3 底层容器错配与迭代器失效的经验教训

stack和queue本身不提供迭代器，但它们底层的容器可能提供迭代器。如果你通过继承或者某些手段获取到底层容器引用，就要面对底层容器本身的迭代器失效规则。比如vector扩容会让所有迭代器失效，deque的迭代器在中间插入时可能失效，list在插入删除时迭代器相对稳定。这些规则和容器本身一样，不会因为外面套了适配器就改变。

一个真实项目里我遇到过的坑是这样的：我在一个回调函数里保存了底部容器的迭代器，之后往栈里push新元素，导致vector扩容，迭代器指向的位置失效，再访问时读到损坏数据。排查了很久才发现问题不是业务逻辑，而是迭代器失效。后来我的原则很简单：不要在持有迭代器或引用期间修改适配器，更不要跨函数保存这些凭证。需要长期访问的元素，存副本或者存索引位置。

5.4 性能误区：什么时候不该用stack和queue

stack和queue虽然方便，但不是万能的。有一种场景是：你需要频繁判断栈里是否存在某个元素。比如持续接收数据并需要快速检查某个值是否在栈中，这时候stack就不太合适，因为没有随机查找能力。如果你硬要用stack加辅助map去维护“元素是否在栈内”的信息，逻辑会变得很复杂。此时应该考虑用set、unordered_set或者自己用vector加栈顶指针来管理。

另一种不太合适的场景是：你需要在栈的中间位置插入或者删除元素。stack和queue的接口根本不提供这个能力，强行实现只能把中间元素全部弹出、插入、再倒回去，时间复杂度是O(n)，代码也非常难看。这种情况说明你对数据结构的需求不是严格的后进先出或先进先出，而是更通用的线性表，直接用vector或list会更合适。

最后一个性能误区是误以为stack的push分配内存一定很慢。其实deque分段存储的扩容机制比vector更平滑，不会频繁整体搬移，所以多数场景下默认适配器性能完全够用。你先别急着优化成手写数组或者list，先用默认配置跑性能剖析，确定瓶颈真的在容器数据结构上，再考虑替换底层容器。过早优化往往是浪费时间的最大源头。

6. 我的几个使用习惯与扩展思路

最后补几个我平时在项目里沉淀下来的习惯，算不上教科书内容，但对实际开发有帮助。

第一，配置容器适配器的底层容器之前，先用性能剖析工具确认瓶颈。不要想当然认为自定义底层容器一定更快。我曾经在一段处理大批量日志的任务里把queue的底层从deque换成list，结果由于list的节点分散分配，cpu cache利用率下降，反而慢了近百分之十五。后来切回deque并做了批量缓存，性能才恢复正常。

第二，利用swap来清空容器。stack和queue没有clear方法，这是很多人第一次用会觉得别扭的点。想清空全部元素，可以和一个刚构造的空容器做swap：

std::stack<int> emptyStk; stk.swap(emptyStk); // 或者 std::stack<int>().swap(stk);

这样操作是O(1)的，比循环pop在元素很多时效率高出非常多。如果你还在循环pop直到empty，看到这段代码可以优化一下。

第三，在做算法题或者工程组件时，如果只要后进先出语义，可以用vector自己维护栈顶指针，省去标准库的模板包袱，性能可能更好。某图像处理模块里我就用过定长数组配合栈顶索引来实现固定容量的栈，避免了动态扩容的不确定性和堆分配，实时性提升了。但需要你自行管理边界，维护成本也高，不值得对所有场景都重造轮子。

第四，稍微展望一个使用场景：如果你正在做递归改迭代，第一个能想到的辅助结构就应该是stack。递归本质上就是系统为你维护了一个函数栈，你改成自己压栈维护现场状态，就能避免爆栈。树的前序、中序、后序遍历的迭代写法，就是靠stack维护节点的访问顺序；图的拓扑排序可以用queue配合入度统计；这两类问题掌握好，能覆盖大量算法面试和生产需求。

C++的stack和queue看似简单，但底层机制和工程细节比教科书上讲的要丰富得多。搞清楚容器适配器的本质，理解deque为何成为默认选择，知道什么时候更换底层容器，明白接口设计背后的安全考量，这些加起来才叫真正“玩转”这两个容器。不敢说我这套经验覆盖了所有场景，但按照这个思路去学习和使用，踩坑的次数一定会少很多。