std::vector扩容时若元素类型不满足std::is_nothrow_move_constructible_v，会退回到拷贝构造路径以保证异常安全；因移动构造非noexcept时无法安全迁移旧元素，标准强制改用拷贝。
如果 std::vector 扩容时底层元素类型不满足 std::is_nothrow_move_constructible_v，它就不得不退回到拷贝构造路径——哪怕你写了移动构造函数，也白写。
std::vector::reserve 和 resize 为什么会悄悄变慢
当 T 的移动构造函数不是 noexcept，std::vector 在 realloc 内存时无法安全地“搬”旧元素：万一移动中途抛异常，原容器状态已破坏（指针失效、旧内存被释放），无法回滚。标准要求此时必须改用拷贝构造来保安全。
实操建议：
- 检查你的类是否显式声明了
noexcept移动构造函数：T(T&&) noexcept，而非默认生成的（编译器只在所有成员都noexcept时才给默认移动构造加noexcept） - 用
static_assert(std::is_nothrow_move_constructible_v在编译期拦截问题, "T must be nothrow move constructible"); - 特别注意含
std::string、std::vector成员的类：C++11 中它们的移动构造不保证noexcept，C++17 起才强制为noexcept；若目标平台是 C++11/14，需手动验证
std::is_nothrow_move_constructible_v 的实际判断逻辑
它不是看有没有移动构造函数，而是看「调用该移动构造函数是否可能抛异常」。即使你写了 T(T&&)，只要没加 noexcept，或其内部调用了可能抛异常的函数（如未标记 noexcept 的成员移动构造），结果就是 false。
常见错误现象：
- 自定义类中移动构造函数遗漏
noexcept，但所有成员都支持无抛移动 → 实际可安全移动，却被判为不可 - 成员含
std::mutex或自定义资源句柄（且其移动构造未标noexcept）→ 整个类判为false，即使你从不抛异常 - 使用
std::unique_ptr时误传自定义 deleter（非函数对象或含异常逻辑）→ 破坏noexcept保证
性能差异到底有多大
在大量元素（比如 10⁵+）的 vector 扩容场景下，拷贝 vs 无抛移动的实际开销差距常达 2–5 倍：前者要分配新内存 + 拷贝每个对象（含深拷贝字段），后者只是位移指针 + 调用 trivial 移动（甚至被优化掉）。
实操建议：
- 用
clang++ -std=c++17 -fsanitize=undefined配合运行时观察 reallocation 行为，比纯静态断言更早暴露隐性问题 - 对性能敏感容器（如帧数据缓存、粒子系统数组），把
static_assert放进模板头文件最顶部，避免下游误用 - 不要依赖「编译器优化能绕过这个检查」——这是标准强制行为，不是优化开关
最容易被忽略的是：即使你 100% 控制类定义，第三方库中某个模板特化（比如 boost::optional）也可能因内部实现未标 noexcept，导致整个链路失效。得一层层查 is_nothrow_move_constructible_v 的真值来源，不能只盯自己写的类。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
