扩容必须分配新内存并逐个移动/拷贝构造，因vector底层为连续原始缓冲区，new[]无法就地延展，realloc不适用于非平凡类型；直接memcpy会导致string等类型双释放或悬垂指针。
扩容时为什么必须用 malloc + memcpy 或 new + 手动拷贝？
因为 std::vector 的底层内存是连续的原始缓冲区，没有“就地扩容”这回事。C++ 的 new[] 分配的是固定大小的堆块，无法像 realloc 那样尝试原地延展（且 realloc 也不适用于含非平凡构造函数的对象）。所以扩容唯一安全的做法是：分配新内存 → 逐个调用移动/拷贝构造 → 析构旧对象 → 释放旧内存。
常见错误是直接 memcpy 原始字节——对 int 没问题，但对 std::string 这类含指针、引用计数的对象会双释放或悬垂指针。
- 正确做法：对每个旧元素调用
T(std::move(old[i]))或T(old[i])构造到新地址 - 必须用
std::allocator_traits<t>::construct</t>或手动调用构造函数，不能跳过 - 旧元素析构前，必须确保新位置已构造完成，否则异常安全难保证
push_back 触发扩容时，如何避免重复计算容量？
每次 push_back 都检查 size_ == capacity_ 是必须的，但扩容倍数策略直接影响性能。用固定加法（如 +1）会导致 O(n²) 复杂度；用乘性增长（如 ×1.5 或 ×2）才能摊还为 O(1)。
注意：×2 简单但可能浪费内存；×1.5 更省空间但需浮点运算或整数技巧（如 new_cap = size_ + size_ / 2）。实际中 std::vector 通常用 ×2。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 扩容前先算好
new_capacity，不要在循环里反复计算 - 首次分配建议设为 1 或 2，避免空 vector 也 malloc 一次
- 如果传入初始
n，直接分配n容量，别先分配 0 再 push n 次
怎么安全处理 T 是 move-only 类型（如 std::unique_ptr）？
手写 vector 必须区分 T 是否支持移动。若只用 copy，对 unique_ptr 编译不过；若盲目用 move，对 int 虽无害但冗余。标准做法是优先 move，fallback 到 copy。
核心是用 std::is_nothrow_move_constructible_v<t></t> 和 std::is_copy_constructible_v<t></t> 做 trait 判断，再配合 std::move 或 static_cast<const t></const>。
- 构造新元素时：用
new (ptr) T(std::move(old_elem))，不是new (ptr) T(old_elem) - 旧元素析构前，必须先完成所有新元素构造，否则异常发生时状态不一致
- 别忘了在析构函数里对 [0, size_) 区间内每个元素显式调用
obj.~T()
为什么不能直接继承 std::allocator 来管理内存？
可以继承，但没必要，且容易误用。std::allocator 只负责 raw 内存分配/释放（allocate/deallocate），不负责对象构造/析构。真正要复用的是它的接口约定，而不是继承它。
更轻量、更可控的做法是封装一个 allocator_type 类型别名，默认用 std::allocator<t></t>，并在内部调用 alloc_.allocate(n) 和 alloc_.deallocate(ptr, n)。
- 自己 new/delete 容易漏掉对齐要求（尤其 C++17 后
operator new支持对齐参数） - 用
std::allocator可无缝对接自定义 allocator（比如 arena allocator） - 别在类里硬编码
sizeof(T)—— 让 allocator 自己算
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
