std::exchange在移动赋值中用于原子性交接资源，确保自赋值安全和逻辑清晰；典型用法是用它将右值成员置空并取回旧值，再赋给左值成员。
std::exchange 在移动赋值中起什么作用
std::exchange 的核心价值是「原子性地取出旧值、写入新值，并返回旧值」。在移动赋值运算符里，它能帮你绕过手动保存右值成员、再逐个移动的繁琐步骤，尤其适合资源指针（如 std::unique_ptr、裸指针、std::vector）的交接。它不是为“性能优化”而生，而是为“逻辑清晰 + 避免自赋值问题”服务——因为 std::exchange 本身对自赋值安全（内部用 std::move 和赋值组合实现，不依赖源对象状态是否有效）。
怎么用 std::exchange 写移动赋值运算符
典型模式是：把当前对象的资源用 std::exchange 换成空/默认状态，同时拿到原值；再把右值的资源移过来。关键点在于——你必须确保被交换的左值成员支持移动赋值，且交换后左值处于可析构状态。
常见写法如下：
class Widget {
std::unique_ptr<int> data_;
std::vector<char> buffer_;
public:
Widget& operator=(Widget&& other) noexcept {
if (this == &other) return *this;
data_ = std::exchange(other.data_, nullptr);
buffer_ = std::exchange(other.buffer_, {});
return *this;
}
};</char></int>
注意：std::exchange(other.data_, nullptr) 等价于「取走 other.data_ 的值，把它设成 nullptr，然后返回原来的智能指针」；后续赋值给 data_ 就完成移动。同理，{} 是 std::vector 的默认构造值，交换后 other.buffer_ 变为空容器。
- 必须加
noexcept—— 因为std::exchange本身不抛异常，但如果你交换的成员移动赋值可能抛异常（比如自定义类型），就不能加 - 自赋值检查不能省：虽然
std::exchange安全，但other是右值引用，this == &other在某些场景（如foo = std::move(foo)）仍可能发生 - 不要对非移动语义类型滥用：比如
int成员用std::exchange没意义，普通赋值更直白
和手写移动赋值比，容易踩哪些坑
表面上看 std::exchange 让代码变短了，但隐含约束更强。最容易忽略的是资源生命周期管理责任转移是否完整。
- 如果成员类型没有移动赋值运算符（只有拷贝），
std::exchange会退化为拷贝——编译器不会报错，但语义已错 - 裸指针场景下，仅用
std::exchange(p_, nullptr)不足以保证异常安全：若后续某成员移动失败，p_已经被置空，原资源泄露 - 和
std::swap混淆：有人误以为std::exchange(a, b)等价于交换，其实它是「a ← b, 返回旧 a」，不是双向交换 - 移动后
other的状态依赖被交换类型的移动后状态规范：比如std::unique_ptr移动后必为nullptr，但自定义类型若未明确定义移动后状态，std::exchange无法保证其可用性
什么时候不该用 std::exchange
当移动逻辑涉及条件分支、资源清理联动或需要精确控制移动顺序时，硬套 std::exchange 反而增加理解成本。
- 需要在移动前释放当前资源（比如 close fd、unlock mutex）——此时必须显式写
cleanup(); data_ = std::move(other.data_); - 多个成员存在依赖关系：比如先移动
buffer_，再根据其大小调整data_分配策略——std::exchange破坏这种时序 - 类有虚函数或继承关系，且移动赋值需调用基类版本：直接用
Base::operator=(std::move(other));更稳妥，而非对基类子对象用std::exchange
真正省事的前提是：成员都是标准可移动类型，且移动即“完全接管+清空源”，没有副作用和前置条件。否则，多敲几行字换来的可维护性，远比一行 std::exchange 更可靠。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
