南瑾i1. 内容整体设计与思路拆解
1.1 为什么这块内容是C/C++的“地基”
先说一个我自己的观察。很多人学C/C++，语法背得滚瓜烂熟，指针、引用、内存分配张口就来，但是一到写实际项目就露馅了——不是数据结构选型不对导致性能拉胯，就是直接用STL容器却不知道底层原理，出了诡异的内存问题无从排查。说白了，基础数据结构加STL这套组合拳，才是C/C++真正拉开和Java、Python差距的地方。
基础数据结构，说白了就是数组、链表、栈、队列、树、图、哈希表这些东西。它是计算机科学里最核心的抽象，不管你以后做音视频开发、嵌入式、游戏引擎、后端服务还是算法竞赛，天天都在跟它们打交道。而STL，也就是Standard Template Library标准模板库，是C++标准库中最重要的一部分，它把这些数据结构封装成了开箱即用的容器，配合迭代器和算法，能让你在几行代码里完成以前要写一百行才能实现的功能。
这套东西解决了什么问题？举个最简单的场景：你在写一个网络请求处理模块，需要按顺序缓存一批任务，还要能快速从中间删除一项。用数组你得维护一个额外的头部和尾部指针，还得处理扩容；但如果你知道环形队列这个数据结构，或者直接用STL里的deque，三行代码搞定，而且效率不输手写。这就是数据结构加STL的威力——数据结构给你提供思路，STL给你提供工程化的实现。
适合谁来读？我觉得有三类人：第一，正在准备校招或者跳槽面试的，C/C++岗位的八股题和手撕代码题有一半都出自这里；第二，刚入门C++不久，想把基础打牢的学习者；第三，做了几年业务开发但没系统理过这块知识，想查漏补缺的老兵。这篇文章会把原理、选型、实操和踩坑一次性讲透。
1.2 STL的六大组件架构与设计哲学
很多人用STL就只会用vector和map，遇到复杂需求就不知道怎么组织了。理解STL的架构其实有捷径——它由六大组件组成，搞明白它们之间的关系，你就能像搭积木一样自由组合。
六大组件分别是：容器、算法、迭代器、仿函数、适配器、分配器。我习惯用一个生活类比来解释：容器是货架，算法是搬运工的操作手册，迭代器是货架上的扫码枪——搬运工不直接碰货架，而是通过扫码枪来定位和存取货物。这样设计的好处是，一套搬运工（算法）可以适配所有货架（容器），只要扫码枪（迭代器）接口统一就行。仿函数就是带有特殊技巧的搬运小工具，适配器是把一个货架改装成另一个功能形态，分配器则是决定货架用什么材料做的——比如内存池还是直接new。
这个设计哲学的本质是泛型编程和关注点分离。容器只负责存储和内存管理，算法只负责逻辑处理，迭代器作为中间层解耦了两者。正因为这个架构，你写了一个自定义的链表数据结构，只要为它实现对应的迭代器，就可以直接复用STL里几十个现成算法（排序、查找、累加等），这比自己手搓所有函数痛快太多了。
我建议学习的时候不要只停留在“会用容器”这一层，而是从六大组件的视角去看STL，你会发现它根本不是什么玄学，而是一套非常优雅的设计。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心数据结构逐个拆解
2.1 数组与字符串：最朴素的连续内存
数组是所有数据结构里最基础、最暴力的一个。它对应到内存上就是一段连续空间，按下标访问的时间复杂度是O(1)，因为编译器可以直接通过“起始地址 + 下标 × 元素大小”算出目标地址。
数组的优势是缓存友好。CPU读数据的时候按缓存行来，连续内存意味着加载一个元素的时候相邻元素大概率也会被加载，所以遍历数组的速度通常要比遍历链表快得多。比如你要处理一个音视频解码后的像素缓冲，本质上就是个unsigned char数组，用数组能最大程度发挥CPU缓存的作用。
但数组有两个天然缺陷：一是容量固定，越界访问是未定义行为，不报错但可能踩坏内存；二是插入删除代价高，因为要移动后面所有元素，平均O(n)。字符串说白了就是字符数组加一个长度信息，C语言里以\0结尾，C++里则有std::string帮我们管理内存。
实操建议：能用连续内存存储就用连续内存，别一上来就new链表。很多新手觉得链表高级，其实大部分场景数组的性能表现都更好。如果担心容量不够，直接用std::vector，它内部就是动态数组，自动扩容，而且扩容策略是倍增——每次新容量是旧的1.5到2倍，均摊下来插入时间复杂度仍然是O(1)。
2.2 链表：指针操作的试炼场
链表是理解指针和动态内存分配的经典教材。每个节点包含数据和一个指向下一个节点的指针，单链表只能往后走，双向链表还能往回走。
链表的优点是插入删除快，只要知道目标位置的前驱节点，修改指针指向就是O(1)的事。但代价是随机访问是O(n)，你得从头一个个找。另外一个隐藏成本是每个节点都有额外的指针开销，而且节点在内存里通常是不连续的，缓存命中率差，遍历起来比数组慢得多。
在工程实践中，真正需要手写链表的场景并不多，因为STL的std::list已经是标准答案。但面试官喜欢让你手写，考察的就是你对指针操作和边界条件的敏感度。我面试过不少人，写单链表反转十个人有八个在边界条件上栽跟头——空链表、只有一个节点、两个节点，这些情况都要心里有数。
还有一类容易出问题的操作是链表排序。虽然std::list自带sort成员函数，但如果你自己实现了链表又想用STL的std::sort，那就等着编译报错吧——因为std::sort要求随机访问迭代器，而链表的迭代器是双向的，不支持。这就是我刚才说的，理解迭代器类型跟理解数据结构本身同样重要。
2.3 栈与队列：受限线性表的工程价值
栈和队列本质上是加了访问限制的数组或链表。栈是后进先出（LIFO），队列是先进先出（FIFO）。限制反而是一种保护——它们把操作边界划死了，调用方不容易出错，而且语义清晰，代码可读性大幅提升。
栈最经典的应用是函数调用栈，每次函数调用会把参数、局部变量、返回地址压入栈中，函数返回时再弹出。编译器解析表达式、浏览器的前进后退功能、深度优先搜索（DFS）也都是栈的思路。队列呢，消息队列、任务调度、广度优先搜索（BFS），全是它的天下。
在C/C++里实现栈和队列有两种主流方式：数组实现和链表实现。数组实现需要预先分配空间或者动态扩容，好处是内存连续、效率高；链表实现没有容量限制，但每个节点有指针开销。STL直接提供了std::stack和std::queue，注意它们其实是容器适配器——默认基于deque实现，你也可以指定底层容器为vector或list。
我实操中踩过一个坑：用std::stack做深度优先遍历图，结果图太大栈溢出，程序直接崩溃。排查半天发现是递归调用太深了，改成显式的std::stack后问题解决——递归本质上也是用栈，但系统栈空间有限，而堆上的std::stack空间容量大得多。这个经验在写涉及大量节点遍历的功能时特别值得注意。
2.4 树与图：非线性结构的复杂度之美
树是一种非线性结构，有根节点、父子关系、层级结构。最常见的二叉树，每个节点最多有两个子节点。二叉搜索树（BST）有个重要性质：左子树的所有节点值都小于根节点，右子树都大于根节点，所以查找、插入、删除的平均时间复杂度是O(logn)。
但是普通的BST可能退化成链表，极端情况下时间复杂度O(n)。为了解决这个问题，出现了平衡二叉树，比如红黑树。STL里的std::map和std::set底层用的就是红黑树，它能保证树的高度近似logn，所以所有操作都稳定在O(logn)。这个细节面试常考——为什么map的查找是O(logn)而不是O(1)，就是因为底层结构。
图的工程应用更广了。社交网络里的好友关系、地图导航的路径规划、物流网络的最短路径，本质都是图论问题。图的存储方式主要有两种：邻接矩阵和邻接表。矩阵适合稠密图，查询边是否存在是O(1)；邻接表适合稀疏图，遍历所有邻居的总代价是O(V+E)，大多数实际场景连的边远少于满连接，所以邻接表更常用。在C++里，邻接表可以用vector<vector<int>>表示——外层index是起点，内层数组存所有终点。
最近看到GESP七级有一道“物流网络”的题目，就是个典型的图论问题：求两点间的最短路径或者网络容量。这类题用邻接表建图加上Dijkstra或BFS就能解，STL的priority_queue配合自定义排序，写起来比手搓堆要省太多事。这种考级题目的意义就在于考察你有没有把数据结构跟实际问题挂钩的能力。
2.5 哈希表：空间换时间的典型实践
哈希表（散列表）大概是工程上用得最频繁的数据结构。它的原理是把关键码值通过哈希函数映射到数组的某个位置，理论上的查找、插入、删除都是O(1)。这也是std::unordered_map和std::unordered_set的底层实现方式。
哈希表最核心的是两件事：哈希函数设计和冲突处理。哈希函数的质量决定数据散不散得开，冲突处理则决定哈希表退化的速度。常见的冲突处理有链地址法和开放寻址法，C++标准库用的是链地址法——每个桶挂一个链表，冲突的元素都放到链表里。最坏情况下所有元素都被塞到同一个桶里，哈希表退化成O(n)的链表，所以好的哈希函数至关重要。
工程上使用哈希表最需要注意的，是自定义类型做键时必须自己提供哈希函数和相等比较函数。很多人拿unordered_map存自定义结构体时报错一头雾水，其实就是没提供这两个东西。哈希表的缺点是内存使用不连续，遍历顺序不稳定，对缓存不友好。所以如果不需要快速查找而只是顺序遍历，用vector反而更快。
3. STL容器实操要点与避坑指南
3.1 vector、list、deque怎么选
很多人问：这三兄弟到底怎么选？我给出一个可以快速决断的思路，来自我多年的实践经验。
优先考虑vector，尤其是需要随机访问或者频繁遍历的场景。vector在绝大部分情况下都是最优选择，它内存连续、缓存友好、push_back均摊O(1)。即使你需要频繁在末尾插入，vector也足够快，reserve预分配空间可以避免重复扩容造成的数据拷贝。如果你需要频繁在两头插入删除，考虑deque，它在两端操作都是O(1)，而且支持随机访问。底部实现是一系列分段连续的内存块，结合了数组和链表的优点。如果只在头部操作多且不需要随机访问，list才是唯一正选——它维护前后指针，任意位置的插入删除只要找到位置就O(1)。
我做过一个实验：向三个容器中各插入100万个元素，vector在未reserve的情况下因为反复扩容需要大量拷贝，耗时最长；但reserve之后，vector反而是最快的，因为内存分配次数少，数据紧凑。所以别迷信“链表插入快”的说法——在末尾插入，vector根本不虚。
3.2 set/map与unordered系列的关系
set和map底层是红黑树，元素默认有序，迭代结果从小到大排列；unordered_set和unordered_map基于哈希表，元素无序，查找更快。一句话总结：需要有序就选set/map，只需要纯粹快速查找就选unordered系列。
我在一次实际项目中碰到过性能瓶颈：一张映射表有几十万个键值对，频繁查询，用map跑了30秒，换成unordered_map后优化到8秒。原因是哈希查找的O(1)常数太小了，而树的O(logn)在数据量大时差距就体现出来了。但如果你的业务需要范围查找，比如找到所有价格在100到200之间的商品，那哈希就无能为力了，只能靠map的lower_bound/upper_bound或者std::equal_range，这是树结构特有的能力。
这里提醒一下面试容易考的点：C++标准并没有规定unordered_map的桶数策略，但库实现通常会在元素个数超过桶数时rehash重新分配桶，这个过程比较耗时。如果你提前知道大概会有多少元素，可以在构建时通过reserve指定桶数，避免频繁rehash。实测下来，这种优化有时能省下20%以上的插入时间。
3.3 priority_queue与自定义排序
std::priority_queue本质上是一个堆，默认是大顶堆——每次取出的是最大元素。很多人不知道它其实是个容器适配器，底层默认容器是vector，通过std::make_heap、push_heap、pop_heap这些算法来维护堆结构。
自定义排序是使用priority_queue最大的坑。默认是大顶堆，想要小顶堆得传入std::greater比较器。一个容易遗漏的点是：std::sort默认升序用less，priority_queue默认大顶堆也用less，但堆顶取的是最大元素，所以对堆来说less反而等效于降序输出，正好跟sort相反。这个细节经常让人绕晕。
另外一个实际场景：你想存自定义结构体并按某个字段排序，两个选择，一个是给结构体重载operator<，另一个是写一个仿函数作为第三个模板参数。我更推荐仿函数，因为你可能需要针对同一个结构体做多种排序方式，写死重载就锁死了。关于仿函数，本质上它就是一个提供了operator()的类，可以像函数一样调用，但在编译期内联优化比普通函数指针更强，性能更好。
3.4 迭代器失效与内存管理
迭代器失效是STL初学者最容易踩的坑，也是面试必问的送命题之一。简单说：如果你在对vector进行push_back时持有一个iterator，扩容发生之后这个迭代器就失效了——因为它指向的内存地址已经变了。同理，删除元素时，从删除位置到尾部的所有迭代器也都会失效。
我来分享一段真实的bug经验：项目里用for循环遍历vector，里面发现某个条件就调用erase删除当前元素，结果程序在各种诡异的地方崩溃。原因就是erase会让当前迭代器失效，而循环还在继续用它。解决方法是利用erase返回下一个有效迭代器的特性，写循环的时候让迭代器等于erase的返回值：
cpp复制std::vector<int> vec = {1, 2, 3, 4, 5};
for (auto it = vec.begin(); it != vec.end();) {
if (*it % 2 == 0) {
it = vec.erase(it);
} else {
++it;
}
}
另一个更稳妥的选择是用erase-remove惯用法，先用std::remove_if把所有要删的移动到末尾，再统一erase，这种方式代码更清晰，性能也更好。
内存管理方面还有一个常见的陷阱：vector的shrink_to_fit不一定能真正释放内存，它只是一个非绑定的请求，由库实现决定是否执行。真正想立刻释放，可以用一个空vector和当前vector做swap，这是我一直用的老办法。
3.5 各容器的性能与适用场景速查表
我把几个常用容器的时间复杂度和适用偏好整理成一张表，方便你在方案选型时快速对照。
| 容器 | 随机访问 | 插入/删除（头部） | 插入/删除（尾部） | 中间插入/删除 | 底层结构 | 适用场景 |
|---|---|---|---|---|---|---|
| vector | O(1) | O(n) | 均摊O(1) | O(n) | 动态数组 | 高频访问与遍历 |
| deque | O(1) | O(1) | O(1) | O(n) | 分段连续数组 | 双端队列、任务缓冲 |
| list | O(n) | O(1)（需迭代器） | O(1) | O(1)（需迭代器） | 双向链表 | 频繁插入删除、内存分散 |
| set/map | O(logn) | O(logn) | O(logn) | O(logn) | 红黑树 | 有序键值存储 |
| unordered_set/map | 平均O(1) | 平均O(1) | 平均O(1) | 平均O(1) | 哈希表 | 高速查找、无序遍历 |
这个表是我做方案评审时必看的一页。有一次我在评审一个同事的设计，他要在内存里维护一个按分数排序的学生列表，频繁查找、频繁插入。他选了vector，然后用sort排序——插入虽然O(1)，但每插入一次就要整体排序一次，整体复杂度是O(nlogn)。我建议改用set，插入自动排序，查找O(logn)，代码量少一半，性能还提升了几个数量级。选对容器，比你优化一百行代码都管用。
4. 开发环境搭建与跨语言调用实录
4.1 vscode配置C/C++环境的完整步骤
说完了容器，来点更加落地的实操内容。很多新手项目已经写了不少，开发环境还一团糟。我刚入行那年用vscode配C/C++环境也是踩了不少坑，尤其是tasks.json和launch.json里的各种配置项，不知道什么意思就照着网上的抄，最后编译报错调试器起不来。这里给出一套我自己长期在用的配置流程，照着走不会出错。
第一步，安装编译器。Windows上推荐MinGW-w64，把它解压到某个目录，然后把bin目录加入系统PATH。macOS装Xcode Command Line Tools，Linux装g++或clang。验证方式是终端输入g++ --version能正常输出版本号。
第二步，装vscode插件。C/C++扩展是微软官方的，这是必装的，它提供IntelliSense、调试和编译功能。装好后打开一个C++文件，右下角的编译器路径如果显示不知道哪里选择，就手动在设置里配一下C_Cpp.default.compilerPath，指向你g++的完整路径。
第三步，写编译配置。按F5创建launch.json，然后按照官方提示创建tasks.json。一个最小可用的tasks.json长这样：
json复制{
"version": "2.0.0",
"tasks": [
{
"label": "build",
"type": "cppbuild",
"command": "g++",
"args": [
"-fdiagnostics-color=always",
"-g",
"${file}",
"-o",
"${fileDirname}/${fileBasenameNoExtension}.exe"
],
"group": {
"kind": "build",
"isDefault": true
},
"problemMatcher": ["$gcc"]
}
]
}
核心就是command指定编译器，args指定编译参数，-g生成调试信息，${file}表示当前打开的文件。这样做有个局限——只能单文件编译，真实项目还是得靠CMake。
第四步，配置调试器。launch.json里配好program指向生成的exe路径，preLaunchTask自动执行build任务，这样按F5就能直接编译加调试。我最开始用vscode调试总是卡在这里，各种“无法找到xxx.exe”或者“pipe failed”，后来明白了，其实就是程序路径没写对，用了${fileDirname}当前文件所在目录后一切正常。
4.2 编译器与构建工具链选型
编译器选择这事，看起来小事一桩，实际影响巨大。Windows下常见的组合是MSVC（Visual Studio的编译器）、MinGW-w64（GCC的Windows移植版）、Clang。三种编译器对C++标准的支持程度不同，而且ABI也不完全兼容——用MinGW编译的静态库，尝试在MSVC项目里链接通常会直接报一大堆未定义符号错误。
Linux下gcc/g++是主流，Clang在一些特定场景下更激进（比如编译更快、错误信息更友好）。如果做跨平台开发，建议以CMake作为构建系统，它可以屏蔽平台差异，自动检测当前环境使用的编译器。我个人在项目里会写CMakeLists.txt，设置CMAKE_CXX_STANDARD为17，这样不管在Windows还是Linux上，构建行为都基本一致。
有一个老生常谈的配置是需要区分Debug和Release版本。Debug版带-g调试符号，没有优化，方便断点排查；Release版开-O2甚至-O3优化，生成体积小、运行快。很多新人不知道这点，直接把-O3编译的库拿去调试，结果变量被优化掉根本看不了值，或者全开-g不优化就发给用户，性能惨不忍睹。
4.3 C#调用C/C++ DLL的经典报错与排查
C/C++写的核心算法库经常要被上层语言调用，比如C#通过P/Invoke调用原生DLL。这种跨语言调用的坑非常多，最常见的就是System.AccessViolationException，直译过来就是“尝试读取或写入受保护的内存，这通常指示其他内存已损坏”。这不是C#的问题，是原生代码或者声明不匹配导致的。
我自己的排查顺序是这样的：第一步，确认DLL导出函数没有被名字修饰。C++编译器会把函数名做mangling，C#那边按函数名去查找是完全找不到的。解法是在C++侧用extern "C"包裹函数声明，这样导出名就符合C语言规则了。第二步，检查参数类型是否严格匹配。C#的int对应C++的int，但C#的string默认是BSTR或者说UNICODE字符串，对应C++的char*就不对，要显式声明[MarshalAs(UnmanagedType.LPStr)]。
第三步，检查调用约定。C++默认是cdecl，而C#默认是stdcall，如果不一致，堆栈指针就会被破坏，程序在函数返回时崩溃，表现就是AccessViolationException。解决办法是在DllImport里显式指定CallingConvention = CallingConvention.Cdecl，或者反过来在C++侧用__stdcall。
这类问题排查起来特别费时间，但从崩溃类型和函数签名入手，就能一步步缩小范围。我的经验是，写跨语言互操作之前一定先把函数签名对照表写好，双方各自负责人盯着签名核对一遍，能省下后面数不清的调试时间。
4.4 一个容易混淆的“STL”：3D打印文件格式
说到STL，我必须提一个很多人踩过的坑：C++程序员眼里的STL是Standard Template Library，但3D建模和3D打印圈子里，STL是STereoLithography文件格式——一种描述三维模型表面的三角面片数据格式。很多人在网上搜“STL工具”，搜出来的全是转模型格式的在线工具，跟容器和算法八竿子打不着。
我记得有一次同事让我帮忙处理“STL报错，number of faces should be between 1 and 200000”，他以为是我写的C++程序出了bug，我一查才知道是他在用3D打印软件加载模型文件时，发现面片数量超了软件上限。这是两个完全不同的技术体系，但缩写撞车就很容易产生这种乌龙。
这个点放在这提一下，是想提醒大家：在技术圈里缩写的语义依赖上下文，遇到问题先确认语境再动手。如果做的是C++开发，咱说的STL是指标准模板库；如果你同事搞硬件或设计，他说的STL文件可能是要送去做3D打印的立体模型。这种“看起来相关、实际没关系”的混淆在开发协作中太常见了。
5. 从数据结构到实战应用
5.1 题目训练中的STL使用策略
现在很多编程能力等级考试，比如GESP，对数据结构与STL的考查越来越多。我看了七级物流网络那道题，时间限制C/C++是1000ms、其他语言2000ms，这种硬性时间要求逼着你必须用高效的数据结构——暴力穷举肯定超时，得用优先队列优化Dijkstra或者类似的算法。这种实战场景完美诠释了为什么数据结构与STL不只是理论，而是直接影响你能不能通过评测的关键。
我建议刷这类题目时，先别急着动手写代码，先把数据范围读清楚。数据量在10^5级别，你就要考虑O(nlogn)甚至O(n)的算法，用map、priority_queue这种对数级操作的容器；数据量只有100，暴力都能过，就不必花心思优化。很多人做算法题卡住，不是不会算法，而是数据结构选错了。比如需要快速判断某个元素是否存在，你非要用vector去线性查找，那复杂度就是O(n)，用unordered_set就是O(1)，差距极其明显。
STL在竞赛和考试里最大的价值是省去手搓基础结构的时间，能把精力聚焦在算法核心逻辑上。手写平衡树或者堆，笔试面试里还好说，真实竞赛场景基本是浪费时间。可以这么说：STL就是算法竞赛的安全带，系好它不一定能让你超车，但至少不会因为低级错误翻车。
实践中的策略，我总结为三优先：超大数据量优先用unordered系列，需要有序输出优先用set/map，需要取最值优先用priority_queue。配合这样一个习惯：读题后先写下数据范围和数据结构的对应关系，再动笔写代码。
5.2 面试与八股中常见的坑
C/C++面试题里，数据结构与STL是重灾区，不少经典八股题看起来简单，实际上藏着不少细节。我每次面人的时候也喜欢问这些，能通过它们快速识别对方是真懂还是背过答案。
第一个经典问题是：vector扩容为什么是1.5倍或者2倍，而不是固定增加100个？答案是均摊分析。假设每次扩容加倍，那么N次push_back操作中，大约只需要logN次扩容，每次扩容的拷贝成本跟当前容量成正比，加起来均摊下来每个元素只有常数成本。如果固定增加100，那每次扩容后能做100次push_back就又要扩容，总成本是O(n²)。所以倍增是一种经典的分摊折中策略。
第二个陷阱是数组和指针的关系。int arr[10]和int* p = arr看起来一样，但arr类型是int[10]，sizeof(arr)跟sizeof(p)完全不同。声明宏参数里传数组，其实都退化成指针。这在写代码时经常出问题，面试官也爱问。你得能讲清楚数组名在表达式里会隐式转换为指针，但在sizeof里不会。
第三个常考的是map和unordered_map的适用场景。答“map内部有序、底层红黑树、O(logn)、支持范围查找；unordered_map无序、哈希表、O(1)查找、不保证顺序”这只是入门。深一点的追问是：为什么unordered_map的迭代器在rehash时可能会失效？因为rehash可能会导致所有元素移动位置，所以迭代器失效，这也是和多线程并发读写的冲突来源之一。
八股不是让你死记硬背，而是检验你有没有真正通过工程实践理解这些机制。我自己的经验是：把每个STL容器的底层原理和复杂度背诵，不如亲手写一个百万级数据的测试程序，观察不同容器在不同操作下的真实表现。数据不会骗人，跑几遍你就彻底明白了。
5.3 性能调优与内存优化建议
最后聊点实战中经常用到的调优技巧。我在做音视频处理和网络服务的C++模块时，每天就是跟性能较劲，一些细节是真的能反直觉地带来巨大提升。
第一条是尽量预分配内存。vector有个reserve方法，可以提前把容量开好。如果你知道大概会有多少元素，就先reserve，避免扩容时反复分配和拷贝。比如你要从文件里读100万条日志塞进vector，先reserve个100万，比边读边push_back快好几倍。unordered_map也有reserve，可以预留桶数量，减少rehash次数。
第二条是遍历容器时注意迭代器类型。对vector这种连续存储，C++11之后基于范围的for循环和标准for循环性能差不多，编译器都能优化。但如果对list用基于范围的for，每次迭代都是一次指针跳转，缓存不命中严重，性能自然差。如果能用索引就用索引，能直接访问就直访问，别过度封装。
第三条是减少不必要的拷贝。函数传参尽量用const引用，返回大对象时可以依赖返回值优化或者移动语义，C++11之后用std::move转移资源量。一个典型的反模式是写函数时return一个局部vector，如果没有移动语义或RVO，就等于把整个数组复制一遍。我见过有人写代码把几MB的结构体按值传来传去，性能直接被拖垮，这种问题用现代C++的移动语义就能轻松化解。
还有一条关于内存对齐的建议：结构体字段顺序会影响它占用的内存大小。编译器会在字段之间插入padding，你如果按从小到大排列int和char这些字段，能减少padding浪费。几条看起来不起眼的小调整，积少成多，对内存敏感的系统非常有效果。
说到内存，顺便提一句：C/C++的程序员必须对自己的内存使用有意识。Java、Python都有垃圾回收兜底，但C++没有。STL容器销毁时会自动释放内部的内存，但如果你手动new了对象放进容器，千万别忘记在适当的时候delete，否则就是内存泄漏。除非你用的是智能指针std::shared_ptr、std::unique_ptr，我现在写代码基本标配智能指针——现代C++早就该告别裸指针管理生命周期了。
最后说点实在的
写了这么多，其实我最大的感受是：数据结构与STL这块内容，看着枯燥，但它是C/C++开发者真正的底气所在。一个只会语法把代码跑通的人，和一个能准确说出“这个场景用deque比list好，因为要双端操作而不用频繁随机访问”的人，他们写出来的系统在天壤之别。
我个人踩了无数次坑，才逐渐形成了一套自己的容器选择习惯：默认用vector，需要排序去重就用set，需要快速查找就用unordered_map，任务调度用priority_queue，双端缓冲用deque。每做一个项目，都下意识先从数据结构的角度去拆解问题，而不是拿到需求就开写代码。这套思维方式，说实话比记住任何容器的API都管用。
如果你刚学完语法，我强烈建议你找几道考察数据结构与STL的题目练一练，GESP的题目就是不错的方向，比如物流网络那类图论题。不用追求多难，关键是逼着自己思考“为什么用这个容器”“为什么这个复杂度可以过”。当你习惯了用数据结构的视角去解构问题，再回头看那些曾经让你头疼的项目，会发现思路清晰了太多。
最后再分享一个小技巧：调试STL容器内容的时候，别硬打印一大坨数据，利用vscode的监视窗口直接查看，或者写个小工具函数统一格式化成字符串输出。这个习惯能帮你省下大量的排查时间。
希望这篇长文对你有用。如果有什么不同的实战经验，也欢迎在评论区聊，踩过的坑多了，才能一起把路走顺。