std::promise的set_value/set_exception必须在对应future::get()调用后、返回前完成，否则get阻塞；promise不可拷贝只能移动，子线程需通过值捕获移动后的promise并调用set方法，且仅允许单次设置。
std::promise 的 set_value 和 set_exception 必须在持有 std::future 的线程调用前完成
不是“跨线程任意调用就生效”，而是 std::promise::set_value() 或 std::promise::set_exception() 必须在对应 std::future::get() 被调用**之后、阻塞返回之前**完成；否则调用 get() 会永远阻塞（或抛出 std::future_error，取决于状态）。关键点是：promise 和 future 是一对协作对象，不是消息队列。
常见错误现象：
- 主线程创建
std::promise和std::future，立刻调用future.get()→ 阻塞，且子线程还没来得及调用set_value→ 死锁 - 子线程中调用
set_value后立即退出，但主线程还没开始get→ 没问题；但如果主线程已调用get且 promise 尚未设置，则阻塞直到设置 - 对同一个
std::promise多次调用set_value或set_exception→ 抛出std::future_error（错误码为std::future_errc::promise_already_satisfied）
正确跨线程传递结果：用 std::thread + std::move 传递 promise
std::promise 不可拷贝，只能移动。若要在子线程里设置结果，必须把 promise 移动进去——不能传引用或指针后由子线程直接调用（除非你手动同步，但没必要）。
实操建议：
- 用
std::thread构造时，将std::promise以std::move(p)形式传入 lambda 或函数 - lambda 捕获方式必须是值捕获（
[p = std::move(p)]），不能是引用捕获（[&p]） - 子线程内调用
p.set_value(...)或p.set_exception(...)即可，无需额外同步
示例：
std::promise<int> p;
std::future<int> f = p.get_future();
std::thread t([p = std::move(p)]() mutable {
try {
// 模拟耗时计算
std::this_thread::sleep_for(100ms);
p.set_value(42); // ✅ 正确：移动后在子线程设值
} catch (...) {
p.set_exception(std::current_exception()); // ✅ 正确：传播异常
}
});
t.detach(); // 或 t.join()
// 主线程稍后取值（确保 t 已启动）
int result = f.get(); // 阻塞直到 set_value/set_exception 被调用
</int></int>
set_exception 的两种常用写法及陷阱
不能直接 throw 异常，必须用 set_exception 显式传递一个 std::exception_ptr。常见写法有两种，行为一致，但容易漏掉 std::current_exception()。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
实操建议：
- 在 catch 块中，必须用
std::current_exception()获取当前异常的指针，再传给set_exception - 不要手动 new 异常对象并转成 exception_ptr ——
std::make_exception_ptr可用于非当前上下文，但多数场景用std::current_exception()更安全 - 如果子线程未 catch 异常而直接退出，
std::promise不会自动捕获它，也不会通知 future → future 会永远阻塞
错误示范（不会触发 future 返回）：
std::thread t([p = std::move(p)]() mutable {
throw std::runtime_error("oops"); // ❌ 未捕获，promise 无感知
});
正确写法：
std::thread t([p = std::move(p)]() mutable {
try {
risky_operation();
p.set_value(0);
} catch (...) {
p.set_exception(std::current_exception()); // ✅ 必须这样
}
});
std::promise 生命周期比 future 长？不，必须确保 promise 在 set 之后才析构
promise 对象本身不需要长期存活，但它必须在调用 set_value 或 set_exception **完成之后**才能被析构。如果 promise 在子线程中是局部变量，且 set 调用后函数立即返回，那没问题；但如果 set 是异步触发（比如绑定到回调里），而 promise 已经离开作用域，就会导致未定义行为。
容易踩的坑：
- 把
std::promise存在栈上，又把它 move 进 lambda，但 lambda 是延迟执行的 —— 只要 move 后 promise 不再被使用，就安全；栈上原始对象 move 后处于有效但未指定状态，不影响子线程里的副本 - 误以为需要把 promise 放在堆上（
new std::promise）并手动管理 —— 完全没必要，move 语义已足够 - 多个线程竞争调用同一个 promise 的 set 方法 —— 不安全，promise 不是线程安全的 set 接口；应确保只有一个线程负责 set
真正要注意的，是 set 调用本身的原子性和单次性：一旦 set 成功，promise 内部状态就固定了，后续任何 set 都会抛异常。这个约束比生命周期更关键。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
