c++oding="utf-8" ?>
std::vector扩容性能骤降、异常后状态损坏，是因为std::is_nothrow_move_constructible_v为false：此时vector退化为拷贝+析构路径，开销翻倍且强异常安全失效；关键在于移动构造函数必须显式声明noexcept，且所有成员与基类也需满足该约束。
std::vector 扩容性能骤降、异常后状态损坏，八成是因为 std::is_nothrow_move_constructible_v 为 false —— 这不是“有没有移动构造函数”的问题，而是它是否被显式声明为 noexcept。
为什么 vector 扩容时会退化成拷贝路径
当 push_back 触发扩容，std::vector 必须把旧元素迁移到新内存。它只看一个编译期条件：std::is_nothrow_move_constructible_v<t></t> 是否为 true。
- 若为
true：直接调用T(std::move(old_elem))，移动后析构旧对象，全程无异常风险，且避免深拷贝 - 若为
false：退回到“先拷贝构造所有新元素 → 全部成功后再析构旧元素”路径，开销翻倍，且中途失败会导致新旧数据共存、状态不一致 - 即使你写了移动构造函数，只要没加
noexcept，编译器就默认它可能抛异常，trait 就是false -
reserve()无法绕过这个判断——它只预分配内存，真正触发迁移的是扩容那一刻的reallocate步骤
如何验证你的类型是否满足 nothrow 移动构造
别靠猜，用 static_assert 在编译期卡住问题：
static_assert(std::is_nothrow_move_constructible_v<myclass>, "MyClass must be nothrow move constructible");</myclass>
- 如果断言失败，说明该类型在 vector 扩容中必然走拷贝路径
- 常见误判点：成员变量含
std::mutex、std::thread或未标记noexcept的自定义类；基类移动构造没加noexcept；用了= default但没写noexcept = default - 注意：
std::string自 C++17 起移动构造默认noexcept，但若使用自定义分配器（如std::pmr::string），可能因分配器抛异常而失效
修复自定义类型的三个硬性要求
要让 std::is_nothrow_move_constructible_v<t></t> 为 true，必须同时满足：
- 移动构造函数声明末尾带
noexcept（不能只靠函数体空或无throw） - 所有非静态数据成员的移动构造函数也必须是
noexcept（包括std::vector、std::unique_ptr等标准类型，它们通常满足；但你自己写的资源管理类必须自查） - 所有基类的移动构造函数同样需声明为
noexcept（派生类无法覆盖基类的异常规范）
漏掉任意一层，trait 就短路为 false，vector 就不会信任你的移动操作。
位拷贝优化（memmove）的隐藏门槛
某些 STL 实现（如 libstdc++）在满足更严苛条件时，会跳过逐个调用移动构造，直接 memmove 整块内存。但这需要：
-
std::is_nothrow_move_constructible_v<t></t>为true -
std::is_trivially_destructible_v<t></t>也为true - 移动赋值也需
noexcept（部分实现还要求类型非final）
也就是说，仅加 noexcept 不够，还要确保析构函数是平凡的——这对含 std::string 或虚函数的类基本不可行，但对纯 POD 结构体效果极明显。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
