应仅在需频繁任意位置插入/删除且不需随机访问或缓存友好时用std::list；vector在绝大多数场景更优，因其尾插均摊O(1)、局部性好、内存紧凑。
什么时候该用 std::list 而不是 std::vector
绝大多数情况下，优先选 std::vector；std::list 仅在明确需要频繁在**任意位置插入/删除中间元素**，且**不关心随机访问、内存连续性或缓存友好性**时才考虑。
常见误用场景：以为“链表插入快”就盲目替换 vector——但实际中，90% 的插入发生在尾部（push_back），而 vector 的尾插均摊 O(1)，且局部性极好；list 的每个节点单独分配，遍历慢 3–5 倍以上。
- 适合
list：实现 LRU 缓存（需splice快速移至头部）、任务队列中频繁按条件摘除中间任务、数据结构教学演示指针操作 - 不适合
list：日志缓冲、配置项列表、UI 元素集合、任何需要operator[]或二分查找的场景 -
list迭代器失效规则宽松（只有被删节点的迭代器失效），但vector在插入/删除中间元素时，其后所有迭代器、引用、指针全部失效——这点常被高估，实际只要避免保存长期迭代器，影响可控
vector 的扩容机制如何影响性能
vector 在 push_back 触发扩容时，会分配新内存、拷贝/移动旧元素、释放旧内存——这是唯一真正的“昂贵操作”。但标准要求扩容因子 ≥1.5（常见实现为 2），保证均摊时间复杂度仍是 O(1)。
真正的问题在于：未预留空间时，小对象反复扩容会产生大量冗余拷贝；大对象（如含堆内存的类）移动成本高，且可能触发多次内存分配。
立即学习“C++免费学习笔记（深入）”；
- 写法上务必用
reserve()预估容量（如读取 N 行配置前调用v.reserve(N)） - 若元素类型不可移动（无移动构造函数），扩容时只能拷贝，性能雪上加霜
-
shrink_to_fit()不强制释放多余内存，只是请求，实现可忽略；别依赖它“精确控内存”
list 的真实开销在哪
人们只记得“插入 O(1)”，却忽略：list 每个节点至少额外占用 16–24 字节（前后指针 + 对齐），且每次 push_front 或 insert 都是一次堆分配——在高频短生命周期场景下，这比 vector 的偶发扩容更伤性能。
调试时容易踩的坑：用 std::list::size() 认为它是 O(1) ——C++11 起确实是，但某些老编译器或自定义分配器下可能退化为 O(n)；更隐蔽的是，list 不支持数据段内存映射（mmap）、无法用 SIMD、不能直接传给 C 接口（没裸指针数组）。
- 不要用
list存储 trivial 类型（如int），浪费严重；此时vector内存利用率接近 100% -
list::merge()和splice()是少数真正优势操作，但前提是已有两个已排序 list 或需转移子区间 - 用
valgrind --tool=massif或perf record -e mem-loads实测，常发现list的 cache miss rate 是vector的 4 倍以上
架构决策时怎么快速判断
抛开“理论复杂度”，直接问三个问题：
- 是否需要通过下标或指针直接访问第 k 个元素？→ 必须用
vector - 是否 95% 的修改操作集中在容器首尾？→
vector+reserve+ 尾插/尾删足够 - 是否必须保证迭代器/引用在插入/删除其他元素时不失效？→ 若是，
list或std::deque（注意 deque 的中间操作仍是 O(n)）
现实中，很多所谓“中间插入频繁”的业务逻辑，其实可通过延迟标记（soft delete）+ 定期重建 vector 来规避链表开销。真正绕不开 list 的场景，往往早就在接口契约里暴露了——比如你正在封装一个支持 erase(iterator) 并保持其他迭代器有效的容器适配器。
