boost::asio::steady_timer编译为DLL时卡在WaitForSingleObject问题

这既不是Asio的使用错误，也不是常规代码逻辑Bug，本质是Windows平台DLL加载阶段的Loader Lock（加载器锁）死锁，刚好命中Asio Windows平台实现的场景限制。
触发逻辑非常明确：

• 如果在DllMain函数内，或者DllMain同步调用的代码路径里执行asio::steady_timer初始化，Asio在Windows环境下首次运行时会拉起内部后台工作线程，对应win_thread.ipp中的线程创建逻辑，线程拉起后会调用WaitForSingleObject阻塞等待新线程完成基础初始化才会返回。
• Windows系统有强制限制：DllMain执行期间，系统会全局持有Loader Lock，而新创建的线程启动后第一时间会尝试获取这个Loader Lock，用来完成DLL_THREAD_ATTACH的模块加载通知流程。此时就形成了无法解开的双向等待：
  • 执行DllMain的主线程持有Loader Lock，卡在WaitForSingleObject等待Asio工作线程完成初始化
  • Asio拉起的新工作线程阻塞在Loader Lock的获取流程上，根本走不到初始化完成的步骤
• 编译为EXE时完全正常，是因为EXE执行主逻辑时，所有模块加载流程已经走完，Loader Lock已经释放，线程可以正常启动完成初始化，不会触发死锁。

核心原则：绝对不要在DllMain及其同步调用路径里执行任何Asio相关的初始化操作，所有Asio相关对象（io_context、timer、socket等）的创建，全部挪到DLL加载完成后的执行路径中：

1. 精简DllMain逻辑，不要在里面放任何Asio相关代码

BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
{
    switch (ul_reason_for_call)
    {
        case DLL_PROCESS_ATTACH:
        case DLL_THREAD_ATTACH:
        case DLL_THREAD_DETACH:
        case DLL_PROCESS_DETACH:
            break;
    }
    return TRUE;
}

2. 给DLL增加显式导出的初始化函数，把所有Asio相关初始化逻辑放在这个函数里，等外部调用方执行LoadLibrary拿到DLL模块句柄之后，再主动调用这个导出函数完成初始化：

__declspec(dllexport) void DllInit()
{
    // 所有Asio相关初始化都挪到这里
    // 示例：
    // m_context = new asio::io_context();
    // asio::steady_timer timer(*m_context);
}

3. 如果场景必须在DLL加载阶段完成初始化、无法修改调用方逻辑，可以在编译Asio相关代码前定义宏ASIO_DISABLE_THREADS，强制禁用Asio的内部多线程调度逻辑，从根源上避免启动新线程触发死锁。注意这个方案会让Asio失去多线程调度能力，仅适合单线程轮询io_context的使用场景。

调试时直接打开调试器的线程视图，查看两个阻塞线程的调用栈：

• 执行初始化的线程卡在WaitForSingleObject调用，对应Asio的win_thread.ipp代码位置
• 新创建的工作线程卡在ntdll!LdrpAcquireLoaderLock调用位置
  满足这两个特征即可100%确认是Loader Lock死锁，将初始化逻辑移出DllMain路径后问题会直接消失。

内容的提问来源于stack exchange，提问作者thedemons