std::shared_future不能直接从std::future移动构造，因为std::future独占所有权且不可拷贝，必须通过future::share()转移共享状态；share()使原future失效，返回的shared_future支持多线程并发get/wait，但仅保证操作本身线程安全，不保证结果值的线程安全。
std::shared_future 为什么不能直接从 std::future 移动构造？
因为 std::future 是独占所有权的——一旦你调用 get() 或把它 move 出去，原对象就变成 valid == false 状态。而 std::shared_future 的设计目标是允许多个对象同时等待、读取同一个异步结果，这就要求底层状态必须能被共享，不能被单次消费销毁。
所以你不能写 std::shared_future<int> sf = std::move(fut)</int>（编译失败），也不能用拷贝构造（std::future 不可拷贝）。
- 正确做法只有一种：调用
std::future::share()成员函数，它返回一个std::shared_future -
share()会把原std::future置为无效（valid == false），并把内部状态转交给返回的std::shared_future - 这个操作是转移语义，不是拷贝；底层 shared state 引用计数 +1，但原 future 不再持有所有权
如何安全地把 shared_future 传给多个线程？
std::shared_future 是线程安全的：多个线程可同时调用 get()、wait()、valid()，无需额外同步。但注意——它只保证对同一对象的并发调用安全，不保证你传进去的值本身线程安全。
- 所有线程拿到的是同一个
std::shared_future对象的拷贝（拷贝构造合法），每个拷贝都持有一个指向共享状态的引用 - 任意线程调用
get()都会阻塞直到结果就绪，且所有线程拿到的值是相同的（对基本类型或 const 对象没问题；若返回的是非 const 右值引用，首次get()后其他调用会抛std::future_errorwithno_state） - 如果异步任务返回的是大对象（如
std::vector<int></int>），建议用std::move搬移语义避免复制；但注意：只有第一个get()能拿到右值，后续调用会失败
shared_future 和 promise 配合时容易踩什么坑？
你不能直接从 std::promise 构造 std::shared_future，必须先获取其 std::future，再调用 share()。
- 错误写法：
std::shared_future<int> sf(promise.get_future())</int>—— 编译不过，shared_future没有接受future的构造函数 - 正确顺序：
auto fut = promise.get_future(); auto sf = fut.share(); - 更常见的是配合
std::async：用std::async(...).share()直接得到shared_future，比如auto sf = std::async([]{ return 42; }).share(); - 别在 promise.set_value() 之后才 share ——
share()必须在 future 还有效时调用；一旦 future 已被 get 过或已失效，share() 会抛异常
什么时候该用 shared_future 而不是多次 async？
核心判断点：是否需要多个消费者等待**同一个计算结果**。不是“多个任务”，而是“一个结果被多方使用”。
- 典型场景：一次耗时 IO 或计算，后续多个模块都要基于该结果做不同处理（比如解析 JSON 后，UI 线程、日志线程、校验线程各自读取）
- 反例：你想并发执行三个独立 HTTP 请求——该用三个
std::async+ 三个独立std::future，而不是一个shared_future - 性能上，
shared_future几乎无额外开销（只是多一个引用计数），但滥用会导致逻辑耦合：所有消费者被绑在同一个生命周期上，一旦某处提前get()并移动了资源，其余线程可能失败
真正麻烦的不是语法，而是共享语义的理解——shared_future 共享的是“等待能力”和“结果读取权”，不是“重新触发计算”的能力。它不解决重复执行问题，也不解决结果修改问题。这点容易在业务逻辑里悄悄埋雷。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
