c++oding="utf-8" ?>
vector扩容时若元素类型满足std::is_nothrow_move_constructible_v为true则直接移动，否则退化为拷贝+析构；关键在于移动构造函数必须显式声明noexcept，否则即使不抛异常也会导致性能下降2–3倍。
std::is_nothrow_move_constructible 影响 vector 扩容时的异常安全策略
当 std::vector 需要扩容（比如调用 push_back 时容量不足），它必须把旧元素搬进新内存。如果元素类型支持无异常移动构造（即 std::is_nothrow_move_constructible_v<t></t> 为 true），vector 就直接移动；否则，它会退回到「先拷贝、再析构旧对象」的保守路径——哪怕你的移动构造函数实际上不会抛异常，只要没显式标记 noexcept，标准库就无法信任它。
不加 noexcept 的移动构造函数，会被 vector 当作「可能抛异常」处理
这是最常踩的坑：写了移动构造函数，但忘了加 noexcept。编译器默认它可能抛异常，导致 std::is_nothrow_move_constructible_v<t></t> 返回 false，进而让 vector 放弃移动优化。
- 正确写法：
T(T&&) noexcept（或在类内声明为T(T&&) noexcept;） - 错误写法：
T(T&&)（隐式非noexcept）或T(T&&) noexcept(false) - 验证方式：
static_assert(std::is_nothrow_move_constructible_v<mytype>);</mytype> - 注意：即使移动构造函数体内没 throw，也必须显式声明
noexcept，否则类型特质不生效
自定义类型 + vector 扩容性能差异实测明显
以一个含 1KB 堆内存的类为例，在频繁 push_back 场景下：
- 带
noexcept移动构造：扩容仅触发移动，O(1) 平摊成本，无额外堆分配 - 不带
noexcept：vector 改用拷贝+析构，每次扩容都要 new 新对象、逐个拷贝内容、再 delete 旧对象——多一倍内存操作和构造开销 - 实测差异可达 2–3 倍，尤其在小对象高频插入、或容器生命周期长需多次扩容时更显著
示例关键片段：
T(T&& other) noexcept : ptr(other.ptr), size(other.size) { other.ptr = nullptr; }
第三方类型或 std 类型也要检查是否 nothrow 可移动
别默认 std::string 或 std::vector 在所有 STL 实现中都满足该条件。虽然主流实现（libstdc++、libc++、MSVC STL）已对它们标记了 noexcept 移动构造，但：
- 某些嵌入式或裁剪版 STL 可能未完全实现
-
std::variant、std::optional等依赖其内部类型的noexcept属性，若你存的是自定义类型，整个链路仍可能断裂 - 跨平台构建时，建议用
static_assert显式约束，而非靠文档假设
真正决定 vector 行为的不是「你写了移动构造」，而是「std::is_nothrow_move_constructible_v<t></t> 是否为 true」——这个值由编译器静态判断，且不可绕过。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
