unifex::async_scope是异步任务生命周期管理的核心，自动等待所有子任务完成，避免悬空；必须用spawn()而非直接co_await顶层sender，join()用于测试，生产环境宜用cleanup()+co_await+when_all。
unifex::async_scope 是异步任务生命周期管理的核心
不手动管理协程对象的生命周期，unifex::async_scope 就是唯一靠谱的选择。它自动等待所有挂起子任务完成，避免悬空或提前析构。
常见错误现象：std::terminate 或内存访问违规，往往因为 unifex::just() 启动的任务没被 async_scope 持有，而外层作用域已退出。
- 必须用
scope.spawn()而非直接co_await顶层 sender（否则任务脱离管理） -
scope.join()是阻塞等待，适合测试或主函数末尾；生产环境建议用scope.cleanup()+co_await配合unifex::when_all - 不要在
async_scope析构后调用spawn()—— 它不负责线程安全，多线程并发 spawn 需额外同步
unifex::schedule() + unifex::then() 构建基础异步链
Facebook unifex 不提供类似 std::future 的“取值即阻塞”接口，所有计算必须通过 sender/receiver 组合子编排。最常用的是调度 + 变换模式。
使用场景：从线程池派发 IO、转换结果类型、错误映射。
立即学习“C++免费学习笔记（深入）”；
-
unifex::schedule()返回的是一个 sender，不是 executor 对象本身；传入的是 scheduler（如unifex::inline_scheduler或自定义线程池 scheduler） -
unifex::then()的 lambda 参数必须返回可转为 sender 的东西，不能直接 return 值（会编译失败：no matching function for call to ‘then’） - 若需传递异常，用
unifex::upon_error()，别依赖 lambda 内 try/catch —— receiver 的错误路径是独立通道
示例：
auto work = unifex::then(
unifex::schedule(my_thread_pool),
[]() -> int { return 42; }
);
// 注意：此时 work 还没执行，只是定义了计算图
unifex::task 和 unifex::lazy just 的语义差异极易混淆
二者都生成 sender，但触发时机和资源占用完全不同：unifex::task 是 lazy 的（仅 co_await 时才启动），unifex::just 是 eager 的（构造即准备就绪）。
容易踩的坑：用 unifex::just(std::move(obj)) 传右值，在 sender 被拷贝多次的组合过程中，obj 可能被 move 多次，导致未定义行为。
-
unifex::task<T>应该用于封装可能含 suspend/resume 的逻辑（比如带co_await的函数），本质是 coroutine wrapper -
unifex::just()适合纯数据转发或 trivial 计算，它的值在 sender 构造时就被复制/移动一次，之后只读 - 如果要延迟求值又不想写 coroutine，用
unifex::lazy_transform包一层unifex::just，比裸写task更轻量
Windows 下链接 libunifex 需显式启用 C++20 协程支持
MSVC 默认不开启协程，即使你用了 /std:c++20，也得加 /await 才能编译 co_await 表达式 —— 否则报错 error C7555: use of 'co_await' requires /await。
Clang 和 GCC 相对友好，但 GCC 12+ 仍需 -fcoroutines，且 libunifex 的 CMakeLists.txt 默认不设该 flag。
- CMake 中务必设置
set(CMAKE_CXX_STANDARD 20)并追加target_compile_options(your_target PRIVATE /await)（MSVC）或-fcoroutines（GCC/Clang） - libunifex 是 header-only，但部分工具链（如 MSVC 17.4+）对 template-heavy 协程代码有 ODR 问题，建议统一用
/permissive-编译 - 别把 unifex 和 boost::asio 混用 scheduler —— unifex 的
io_scheduler不兼容 asio 的io_context::get_executor()，强行 cast 会导致运行时崩溃
async_scope 接管而不是自己 co_await。这些边界没理清，调试时连栈都看不到。 
