resize修改size和元素内容，扩大时默认构造新元素，缩小时析构末尾元素；reserve仅调整capacity，不改变size或元素。
resize 会改变 vector 的 size 和元素内容
resize 是真正修改容器逻辑长度的操作：它要么在末尾添加默认构造的元素（扩大时），要么直接截断（缩小时）。调用后 vec.size() 一定等于你传入的参数，且访问新增索引位置是安全的（有定义行为）。
常见误用场景：想“预分配空间”却写了 vec.resize(1000)，结果意外构造了 1000 个默认对象（比如 std::string 或自定义类），带来不必要开销。
- 扩大时：新元素调用默认构造函数（对
int是零初始化，对类类型是完整构造） - 缩小时：末尾元素被析构，
size()和capacity()都可能变小（后者不一定） - 不保证保留原有 capacity；某些实现缩容时会释放内存，但标准不强制
reserve 只影响 capacity，不碰 size 和已有元素
reserve 唯一目标是确保后续插入（如 push_back）时不频繁重新分配内存。它只调整底层缓冲区大小，size() 完全不变，也不会构造/析构任何元素。
典型错误：调用 reserve 后直接用 vec[i] = x 访问未初始化的索引 —— 这是越界未定义行为，因为 size() 还是 0。
立即学习“C++免费学习笔记（深入）”；
- 如果新容量 ≤ 当前
capacity()，通常无操作（不保证释放内存） - 如果新容量 > 当前
capacity()，会分配新内存、移动旧元素、释放旧内存 - 调用后
capacity() >= 新值，但size()不变
什么时候该用 resize，什么时候该用 reserve
核心判断依据：你是否需要“立刻拥有 N 个可用元素”？
- 需要填满数据且知道最终数量 → 用
resize（如读取固定行数的配置） - 只是预估要 push 大量元素，避免多次 realloc → 用
reserve（如解析未知长度的日志流） - 先
reserve再循环push_back，比反复push_back快得多（尤其元素构造代价高） - 混合使用合理：
reserve(N)后用resize(N)初始化所有位置，再逐个赋值
一个易忽略的性能陷阱：reserve 后 clear 不释放内存
clear() 只销毁元素、设 size() 为 0，但 capacity() 保持不变 —— 这正是 reserve 分配的内存还在。下次再用这个 vector 时，只要不超过原 capacity()，就不会 realloc。
但这也意味着：如果你 reserve(10000) 后只用了几百个元素，又 clear()，这块大内存依然占着。真要释放，得用 vector<int>().swap(vec)</int> 或 C++11 起的 shrink_to_fit()（注意：后者是建议，不保证成功）。
std::vector<std::string> vec; vec.reserve(10000); // 分配足够存 10000 个 string 指针+控制块的内存 vec.clear(); // size=0，capacity 仍≈10000 vec.shrink_to_fit(); // 尝试归还内存，但可能无效（取决于实现和当前 size）实际写代码时，别光看
capacity() 数值漂亮，重点检查你是否真的需要那么多预留空间 —— 特别是 vector 生命周期长、反复复用的场景。 
