编译错误的核心原因是：exec.execute() 内部实现要求传入的函数对象可拷贝（例如 MSVC 的 std::function 底层实现会尝试拷贝），但你的 lambda 通过移动捕获了 move‑only 的 handler（以及可能 move‑only 的 func），导致 lambda 的拷贝构造函数被隐式删除。

[shijinghai]

[ 57%]: cache compiling.release build.gens\hikyuu\windows\unity_build\unity_group_strategy.cpp
error: C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.42.34433\include\functional(851,51): error: call to implicitly-deleted copy constructor of '(lambda at hikyuu_cpp/hikyuu/utilities/thread/algorithm.h:763:17)'
851 | explicit _Func_impl_no_alloc(_Other&& _Val) : _Callee(_STD forward<_Other>(_Val)) {}
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.42.34433\include\functional(839,28): note: in instantiation of function template specialization 'std::_Func_impl_no_alloc<(lambda at hikyuu_cpp/hikyuu/utilities/thread/algorithm.h:763:17), void>::_Func_impl_no_alloc<const (lambda at hikyuu_cpp/hikyuu/utilities/thread/algorithm.h:763:17) &, 0>' requested here
839 | ::new (_Guard._Result) _Ty(_STD forward<_Types>(_Args)...);
| ^
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.42.34433\include\functional(858,25): note: in instantiation of function template specialization 'std::_Global_new<std::_Func_impl_no_alloc<(lambda at hikyuu_cpp/hikyuu/utilities/thread/algorithm.h:763:17), void>, const (lambda at hikyuu_cpp/hikyuu/utilities/thread/algorithm.h:763:17) &>' requested here
858 | return _STD _Global_new<_Func_impl_no_alloc>(_Callee);
| ^
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.42.34433\include\functional(851,14): note: in instantiation of member function 'std::_Func_impl_no_alloc<(lambda at hikyuu_cpp/hikyuu/utilities/thread/algorithm.h:763:17), void>::_Copy' requested here
851 | explicit _Func_impl_no_alloc(_Other&& _Val) : _Callee(_STD forward<_Other>(_Val)) {}
| ^
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.42.34433\include\functional(839,28): note: in instantiation of function template specialization 'std::_Func_impl_no_alloc<(lambda at hikyuu_cpp/hikyuu/utilities/thread/algorithm.h:763:17), void>::_Func_impl_no_alloc<(lambda at hikyuu_cpp/hikyuu/utilities/thread/algorithm.h:763:17), 0>' requested here
839 | ::new (_Guard._Result) _Ty(_STD forward<_Types>(_Args)...);
| ^
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.42.34433\include\functional(964,23): note: in instantiation of function template specialization 'std::_Global_new<std::_Func_impl_no_alloc<(lambda at hikyuu_cpp/hikyuu/utilities/thread/algorithm.h:763:17), void>, (lambda at hikyuu_cpp/hikyuu/utilities/thread/algorithm.h:763:17)>' requested here
964 | _Set(_STD _Global_new<_Impl>(_STD forward<_Fx>(_Val)));

[shijinghai]

修复思路
将 move‑only 的对象用 std::shared_ptr 管理，让 lambda 只捕获可拷贝的 shared_ptr。因为 exec.execute 保证只会调用一次函数对象，我们可以在执行时安全地从 shared_ptr 中移动走 handler 和 func。

修复后的代码
对 void 返回类型和非 void 返回类型两个分支都做如下修改：

cpp
template <typename Executor, typename Func>
auto co_run(Executor exec, Func&& func)
-> asio::awaitable<typename std::invoke_result_t> {
using ResultType = typename std::invoke_result_t;

if constexpr (std::is_void_v<ResultType>) {
    // void 返回类型
    return asio::async_initiate<decltype(asio::use_awaitable), void(std::exception_ptr)>(
      [exec, func = std::forward<Func>(func)](auto handler) mutable {
          auto io_exec = asio::get_associated_executor(handler);

          // 将 move-only 的对象装入 shared_ptr，使 lambda 可拷贝
          auto state = std::make_shared<
            std::pair<std::decay_t<Func>, decltype(handler)>
          >(std::move(func), std::move(handler));

          exec.execute(
            [state, io_exec]() mutable {   // 现在这个 lambda 是可拷贝的
                std::exception_ptr e_ptr = nullptr;
                try {
                    state->first();   // 调用 func
                } catch (...) {
                    e_ptr = std::current_exception();
                }

                asio::post(io_exec,
                  [handler = std::move(state->second),
                   e_ptr = std::move(e_ptr)]() mutable {
                      handler(e_ptr);
                  });
            });
      },
      asio::use_awaitable);
} else {
    // 非 void 返回类型
    return asio::async_initiate<decltype(asio::use_awaitable),
                                void(std::exception_ptr, ResultType)>(
      [exec, func = std::forward<Func>(func)](auto handler) mutable {
          auto io_exec = asio::get_associated_executor(handler);

          auto state = std::make_shared<
            std::pair<std::decay_t<Func>, decltype(handler)>
          >(std::move(func), std::move(handler));

          exec.execute(
            [state, io_exec]() mutable {
                std::exception_ptr e_ptr = nullptr;
                ResultType result{};
                try {
                    result = state->first();
                } catch (...) {
                    e_ptr = std::current_exception();
                }

                asio::post(io_exec,
                  [handler = std::move(state->second),
                   e_ptr = std::move(e_ptr),
                   result = std::move(result)]() mutable {
                      handler(e_ptr, std::move(result));
                  });
            });
      },
      asio::use_awaitable);
}

}
补充说明
std::decay_t 确保 func 被值捕获，避免外部 lambda 引用悬空（原代码通过移动捕获也是安全的，但这里统一用 decay_t 更清晰）。

std::pair 或 std::tuple 按需选用，只要能同时存储 func 和 handler 即可。

移动后 state->first / state->second 会变成空壳，但 exec.execute 保证只调用一次 lambda，不会产生二次移动，因此安全。

这样修改后，传给 exec.execute 的 lambda 只捕获了可拷贝的 shared_ptr 和 io_exec，完全满足可拷贝要求，MSVC 的编译错误就会消失。

[woleigegg]

确认这个问题真实存在。我对调用链做了完整验证，分享一些发现供参考。

1. 根因与 C++ 标准合规性

这其实是旧版 MSVC 标准库的一个已知缺陷，Hikyuu 现有的写法在 C++ 标准下是完全合法的。

调用链为：co_run -> ExecutorWrapper::execute -> ThreadPool::submit。在 ThreadPool::submit（ThreadPool.h:92）中，传入的函数对象被构造进 std::packaged_task：

std::packaged_task<result_type()> task(std::forward<FunctionType>(f));

按 C++ 标准（[futures.task.members]），std::packaged_task 只要求 Callable 是 MoveConstructible 的，从未要求 CopyConstructible。但 MSVC 由于历史 ABI 限制，packaged_task 内部用 std::function 做类型擦除存储（见其 <future> 源码 _Packaged_state::_Fn，注释标注 // TRANSITION, ABI, should not use std::function）。std::function 强制要求目标 CopyConstructible，导致 MSVC 的 packaged_task 违背标准，错误拒绝了 move-only lambda。issue 错误栈中 functional(839) 实例化 _Func_impl_no_alloc<const lambda&, 0>、functional(858) 调 _Global_new<..., const lambda&>，正是 std::function 的拷贝构造路径。GCC(libstdc++) / Clang(libc++) 的 packaged_task 不存在此问题。

2. MSVC 版本差异

MSVC 14.44（VS 2022 17.14+）已修复此缺陷：在 <functional> 新增内部标签 _Secret_copyability_ignoring_tag，为 std::function 增加一个跳过 is_copy_constructible 静态断言的构造重载，专供 packaged_task 使用。因此 14.44 下无需改动代码即可编译通过；14.42（issue 报告环境）及更早版本仍会失败。

3. 关于评论中的修复方案

评论里用 std::shared_ptr 包装 move-only 对象、使 lambda 只捕获可拷贝 shared_ptr 的思路可行，是兼容旧版 MSVC 的合理 workaround。一点补充：该方案目前只覆盖了 co_run 的两个分支，co_run_ec 存在完全相同的调用模式，同样需要处理：

• algorithm.h:736（co_run void 分支）
• algorithm.h:763（co_run 非 void 分支）
• algorithm.h:828（co_run_ec void 分支）
• algorithm.h:853（co_run_ec 非 void 分支）

供参考，是否采纳及如何合并由维护者定夺。

[fasiondog]

OK。这个以后再说吧，因为其他地方有网络服务在用，影响较大需要测试验证。msvc毕竟直接更新下就好了。