应优先选std::vector；仅当需频繁非首尾增删、必须保持其他迭代器有效且不敏感缓存与内存时才考虑std::list。
选 std::vector 还是 std::list，不看教科书那句“中间删插用 list、随机访问用 vector”——这句话在真实项目里经常害人。真正决定性的因素就三个：你是否需要频繁在**非首尾位置增删元素**、是否**必须保留其他迭代器有效性**、以及**内存和缓存是否敏感**。其余都是衍生问题。
随机访问时 vector[i] 和 std::next(it, n) 性能差百倍
哪怕只是读取第 1000 个元素，vector 是一次指针加法，list 得从头节点开始调用 999 次 operator++。实测 10 万个 int 下随机访问耗时：vector 约 3500μs，list 超过 520000μs（148 倍）。这不是理论差异，是 CPU 缓存行（64 字节）预取失效导致的硬伤。
- 如果你写的是日志遍历、消息分发、UI 列表渲染等需要按索引查值的逻辑，直接排除
list -
list的size()在 C++11 后是 O(1)，但std::distance(begin(), it)仍是 O(n) —— 别指望靠它反推下标 - 想“模拟随机访问”？别写
std::advance(it, pos)，它不会变快；真要索引语义，换vector或用deque
insert() 和 erase() 看清前提：你有没有现成的迭代器
list::insert(it, val) 是 O(1)，但前提是 it 已存在。如果你为了插入第 5 个位置，先写 auto it = std::next(lst.begin(), 4)，那前面这句就是 O(n) —— 整体还是 O(n)。而 vector::insert(v.begin() + 4, val) 也是 O(n)，但它后续移动数据可能触发 memcpy，实际延迟更不可控。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 高频中间插入？确认操作是否集中在固定几个位置（比如 LRU 缓存淘汰），否则链表优势被查找抵消
-
list::splice()是真正的 O(1) 搬家，能把另一个list的整段节点“剪切粘贴”过来，不拷贝、不分配——这是vector根本做不到的 -
vector::erase()删除后，所有位于删除点之后的迭代器、引用、指针全部失效；list::erase()只让被删节点的迭代器失效，其他全活
内存开销和缓存行为比时间复杂度更致命
存 100 万个 int：vector 占约 4MB；list 在 64 位系统下至少 12MB（每个节点 8 字节 data + 8 字节 prev + 8 字节 next，再加内存对齐）。更糟的是，这些节点散落在堆各处，一次遍历可能触发上百次缺页和缓存未命中。
- 嵌入式或内存受限场景（如车载 ECU、传感器固件），
list的额外指针开销可能直接超标 -
vector扩容策略（GCC 用 2 倍，MSVC 用 1.5 倍）会导致短暂内存浪费，但可用reserve()预控；list每次push_back都是一次堆分配，小对象下 malloc/free 开销占比极高 - 现代 CPU 对连续访存有深度优化（prefetcher），
list的随机跳转会让这些硬件加速完全失效
迭代器失效规则决定了你敢不敢在循环里删元素
这是最易踩坑的点。vector 在循环中边遍历边 erase，不 careful 就用到已失效迭代器，结果未定义行为（常见表现是 crash 或漏删）。list 则宽松得多：删掉一个节点，其他迭代器照常工作。
- 写类似 “遍历容器，遇到满足条件的元素就删” 的逻辑，
list可以放心用it = lst.erase(it)；vector必须改用 remove-erase 惯用法或反向遍历 -
vector的迭代器本质是指针，list的迭代器是封装类——这意味着vector支持it + 5，list连it + 1都编译不过 - 跨线程共享容器？
list的迭代器稳定性不是线程安全的代名词——增删仍需外部同步，别被“不失效”误导
真正难决策的场景，往往卡在“既要中间插入，又逃不开随机访问”。这时候别硬选，deque、rope（SGI 扩展）、甚至带索引的 vector<pair size_t>></pair> 都比强行用 list 更实际。性能瓶颈从来不在容器接口，而在你对内存访问模式的理解深度。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
