c++oding="utf-8" ?>
vector扩容时自动选移动而非拷贝，前提是元素类型的移动构造函数被显式标记为noexcept；否则标准强制退化为拷贝以保证强异常安全。
vector扩容时自动选移动还是拷贝，取决于元素类型是否支持移动且不抛异常
vector在扩容时不会“猜测”你想要什么，它有一套明确的规则：只要元素类型提供了noexcept移动构造函数，且该函数被标记为noexcept，vector就优先用移动；否则退回到拷贝。这不是编译器优化选项，而是标准强制要求的行为。
常见错误现象是：写了移动构造函数，但没加noexcept，结果扩容时仍然深拷贝——因为标准库认为“可能抛异常”的移动不安全，宁可慢一点也要保证强异常安全。
- 检查方式：用
std::is_nothrow_move_constructible_v<t></t>在编译期确认 - 自定义类必须显式声明：
T(T&&) noexcept { /* 资源转移 */ }，不能只写T(T&&) -
std::string、std::vector等标准类型默认满足，但std::shared_ptr的移动不noexcept（因引用计数操作可能抛bad_alloc），所以某些实现里它在扩容时仍可能走拷贝路径
push_back传右值时触发移动，但扩容过程中的“搬移”是另一回事
很多人混淆了两个阶段：单次push_back插入时的构造，和后续扩容时对已有元素的重新安置。前者看传入的是左值还是右值；后者完全由vector内部决定，且只看元素类型的移动能力是否noexcept。
例如这段代码：
std::vector<:string> v;
v.reserve(2);
v.push_back("hello"); // 临时对象 → 移动构造
v.push_back("world"); // 再次移动构造
v.push_back("third"); // 此时capacity=2，触发扩容 → 把前两个string从旧内存“搬”到新内存</:string>
最后一行的扩容动作中，前两个std::string对象会被移动（因std::string移动构造是noexcept），不是重新构造，也不是拷贝。
- 如果元素类型只有拷贝构造、没有移动构造，扩容必然全量拷贝
- 如果元素有移动构造但没标
noexcept，vector会保守地选择拷贝（除非你用std::vector::swap或std::move整体转移） - 即使你对每个
push_back都加std::move，也不能改变扩容时对已有元素的处理逻辑
reserve()能绕过扩容判断，但无法绕过元素类型的限制
调用reserve(n)提前分配足够内存，确实能避免多次扩容，但它不改变“搬移行为本身”。如果预留空间后仍要insert或resize导致重排，vector依然会按前述规则选择移动或拷贝。
真正起效的是：让元素类型本身具备noexcept移动构造。否则reserve只是减少了次数，没降低单次成本。
- 基本类型（
int、double）和POD结构体天然满足，无需额外操作 - 含
std::unique_ptr、std::string等成员的类，需确保其移动构造函数被正确委托并标记noexcept - 用
std::vector::data()获取原始指针做memcpy？不行。vector内部对象不一定trivially copyable，且未构造的“备用空间”里没有有效对象，直接memcpy会跳过构造函数调用，导致未定义行为
调试时怎么确认某次扩容到底走了移动还是拷贝
最直接的办法是给元素类型加上带输出的构造/移动/析构函数，然后观察日志。但生产环境不能这么干。更实用的方式是结合编译器诊断和类型特征检查：
- 用
static_assert(std::is_nothrow_move_constructible_v<mytype>, "MyType must be nothrow move constructible");</mytype>在编译期卡住 - 在GCC/Clang下加
-D_GLIBCXX_DEBUG（libstdc++）或-D_LIBCPP_DEBUG（libc++）可让容器在运行时检测移动是否被选用 - 注意：MSVC的
std::vector在Debug模式下默认禁用移动优化，Release才启用，别被Debug构建误导
最容易被忽略的一点是：移动语义生效的前提不是“写了std::move”，而是“类型本身被设计成可安全移动”。很多性能问题最终都回溯到自定义类型的移动构造函数漏掉了noexcept。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
