c++oding="utf-8" ?>
vector扩容变慢、内存翻倍、异常后状态损坏，大概率因std::is_nothrow_move_constructible_v为false导致降级为拷贝构造；标准库仅在移动构造标记noexcept时才启用move路径，否则为保异常安全强制回退拷贝。
vector 扩容变慢、内存翻倍、异常后状态损坏——大概率是 std::is_nothrow_move_constructible_v 为 false 导致的降级行为，不是你的算法或硬件问题。
为什么 vector 扩容时没走 move 路径
std::vector 在 push_back 或 reserve 触发扩容时，并不“自动优先 move”。它查的是 std::is_nothrow_move_constructible_v<t></t> 编译期常量：只有为 true，才调用 T(T&&) 移动构造；否则强制 fallback 到 T(const T&) 拷贝构造。
- 这不是性能优化开关，而是异常安全契约：move 构造若可能抛异常，旧对象可能已处于无效状态，无法安全析构，所以标准库宁可多花时间拷贝，也要保强异常安全
- 即使你写了
T(T&&)，只要没加noexcept，std::is_nothrow_move_constructible_v<t></t>就是false - 某些 STL 实现在 debug 模式下会忽略该 trait（比如 libstdc++），但 release 下严格按标准执行，别被调试环境误导
哪些写法会让 std::is_nothrow_move_constructible_v 失效
它不是只看你的类有没有移动构造函数，而是对整个移动链路做静态推导：成员、基类、分配器，任一环节不满足，结果就是 false。
- 移动构造函数声明漏了
noexcept（写成T(T&&)不行，必须是T(T&&) noexcept） - 成员含
std::mutex、std::ofstream或自定义类型NonNothrowResource，其移动构造未标记noexcept - 继承了基类，而基类移动构造没
noexcept，哪怕派生类写了= default，编译器也会推导出非 nothrow - 用了带状态的分配器（如
std::pmr::polymorphic_allocator），其construct()可能抛std::bad_alloc
怎么验证和修复
别等上线后用 perf 看到 cache miss 翻倍才怀疑——在头文件末尾加一条 static_assert，编译期就能卡住问题。
- 验证写法：
static_assert(std::is_nothrow_move_constructible_v<myclass>, "MyClass must be nothrow move constructible");</myclass> - 修复核心动作：给移动构造函数补上
noexcept，并逐层检查所有成员变量和基类是否也满足（重点盯std::vector、std::string的实际版本行为，老 libstdc++ 中std::vector<:string></:string>可能不满足） - 注意：不要写
noexcept(true)或空括号noexcept()，直接写noexcept即可；函数体内也不能调用可能抛异常的操作（如new、std::mutex::lock()）
最容易被忽略的一点：这个 trait 的判断完全静态，不依赖运行时行为。哪怕你 100% 确认移动构造“实际上不会抛异常”，只要签名没 noexcept，标准库就当它会抛——这不是 bug，是设计契约。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
