不知道你有没有这样的经历想在项目里用boost::asio写个异步socket服务结果第一关就在boost库源码编译安装上卡了整整一天。网上教程翻了几十篇照着敲完bootstrap、b2不是报找不到cl.exe就是链接时告诉你libboost_system-vc143-mt-x64-1_84.lib打不开再或者编译到一半内存爆炸直接把机器卡死。我这次正好要给一个C20网络通信模块引入Boost::asio异步网络编程方案从boost库源码编译安装开始重新完整走了一遍流程这篇文章就把所有步骤、参数、踩坑点一次性讲透。如果你是第一次搞C网络编程或者之前一直用包管理器装boost但从没自己编译过这篇就是给你准备的。全文以Boost 1.84.0为例覆盖Windows和Linux两套环境从为什么需要源码编译、环境准备、b2参数逐一拆解到asio工程真实链接验证全部基于我实测过的命令和报错整理。放心抄作业但每步背后的原因也要看懂因为下次换版本、换编译器你依然会踩新的坑。1. 为什么我绕开现成安装包坚持自己源码编译Boost1.1 包管理器里的Boost不一定适合asio开发很多人在Ubuntu上直接apt install libboost-all-dev在Windows下从官网下载预编译installer觉得这样省事。这套方案应付一般项目没问题但一旦你进入Boost::asio异步网络编程领域问题就来了。asio对Boost版本非常敏感。它长期处于快速迭代状态不同版本对C标准支持、对TS模型、对协程支持都有差异。你从apt装的可能是三年五年前的Boost 1.7x当时asio连awaitable和co_spawn都还是不稳定的实验特性而你现在想用C20协程写异步TCP服务代码根本编译不过。功能缺失是小事更要命的是apt源里的Boost是用发行版自带的GCC编译的ABI和工具链跟你项目里用的新版GCC或Clang未必完全兼容链接阶段时不时蹦出莫名其妙的符号错误。Windows那边官网预编译installer分vc14.1/vc14.2/vc14.3对应VS2017/2019/2022。听起来方便可安装器默认只会装它认为常用的库和头文件路径也给你铺得比较乱。并且installer是Release和Debug分开装的很多人装完忘了勾Debug版本的lib结果一用debug构建就疯狂报错。与其跟这些不明不白的黑盒行为较劲不如自己源码编译把每个环节都控制在自己手里。1.2 Boost库的特殊构成header-only与需要单独编译的两类Boost现在一共有160多个库但这里面有个非常重要的分类绝大多数第一次接触的人根本不知道——一类是header-only库代码全部写在头文件里编译器直接include就能用不需要链接任何.lib或.so文件。另一类是必须编译的库包括system、filesystem、thread、regex、date_time、program_options、serialization、locale、python等它们有独立源码文件需要先编译成静态库.a/.lib或动态库.so/.dll链接阶段才能用。那asio属于哪一类从Boost 1.66开始asio核心功能变成header-only了理论上你只需要#include boost/asio.hpp就能用基本的异步IO能力。但注意这是有代价的很多asio示例会用到boost::system::error_code和boost::system::system_error而system库几乎不可能完全绕开。而且实际网络工程里你迟早要碰filesystem、thread、regex这些库它们都需要编译。所以我的建议是哪怕asio本身header-only也要把system、thread、date_time、regex、filesystem这些核心配套库编译出来备用。这也是为什么本文不会让你--without-system而是一股脑把这些常用库都编出来。1.3 源码编译带来哪些实实在在的好处我在多个项目里对比过自己编译的优势在后续开发阶段体现得非常明显第一版本完全可控。想上Boost 1.84就用1.84想切1.80就切1.80不受操作系统源和第三方仓库的更新节奏影响。第二ABI与编译器严格匹配。你用VS2022的MSVC 14.3编译生成的lib文件名会带上vc143标签链接时不会跟你VS2019编译的其他模块搞混。Linux上用GCC 13编出来的库也规避了apt自带GCC版本过老的问题。第三可以控制编译特性。比如关闭python、ICU等无关依赖只编译asio链路需要的库编译时间大幅缩短。不做Python绑定的纯网络服务硬编一遍Boost.Python纯粹是浪费时间还容易因为Python版本不一致报错。第四充分的调优空间。可以为b2指定cxxflags把C标准、优化选项、是否保留调试符号一次性灌进去得到最贴合项目需求的二进制结果。2. 编译前的环境准备编译器、依赖项、目录结构一个都不能少2.1 Windows平台VS版本与开发者命令行环境Windows下编译Boost推荐直接用Visual Studio的工具链。我这边用的是VS2022对应的编译工具集是MSVC 14.3。VS2019是MSVC 14.2VS2017是14.1b2里用toolsetmsvc-14.3来指定。准备工作这几样缺一不可安装Visual Studio 2022时务必勾选“使用C的桌面开发”工作负载。只装VS Code和MinGW的后面b2找不到cl.exe会很痛苦。打开“x64 Native Tools Command Prompt for VS 2022”。这个环境变量Windwos下非常重要它自动帮你把cl.exe、link.exe、nmake.exe以及各种头文件、库路径都配置好了。检查磁盘空间。完整编译所有Boost库大概需要10GB以上空间只编译我们需要的几个库也要预留3GB左右。别在C盘只剩几百MB的情况下开工b2会中途失败且日志极难排查。确保没有安装其他可能劫持命令行环境的软件。比如某些终端工具会覆盖PATH变量导致cl能找到的路径不对。建议就用VS自带的命令提示符窗口跑编译。2.2 Linux平台gcc、build-essential与可选依赖Linux相对简单一个gcc和一个make基本就够了。我是在Ubuntu 22.04上操作的先确认这些基础包已装sudo apt update sudo apt install build-essential g make然后检查gcc版本gcc --version g --versionasio本身不需要额外依赖但如果后面的网络工程里你打算用Boost.Beast做WebSocket或HTTP那最好先确认一下OpenSSL开发库是否存在。asio有一个--with-openssl编译选项Beast的TLS部分需要它。愿意装的可以先装不想装的也不会影响本次基本编译sudo apt install libssl-dev如果后续某些Boost组件需要ICUUnicode支持你也可以选择编译时加--with-icu。但对纯粹的asio异步网络编程来说ICU不是刚需我在本次操作中没有启用它后面会讲怎么显式排除。2.3 从官网下载源码并检查目录结构Boost源码包的命名规律是boost_版本号下划线例如1.84.0对应boost_1_84_0.tar.bz2Windows下还有对应的.zip包。直接去boost官网下载或者在Linux下用wget都行wget https://boostorg.jfrog.io/artifactory/main/release/1.84.0/source/boost_1_84_0.tar.bz2 tar --bzip2 -xf boost_1_84_0.tar.bz2 cd boost_1_84_0Windows下用zip解压到C:\boost_1_84_0注意路径不要带中文和空格。解压完成后进去一眼确认关键文件是否齐全bootstrap.bat和bootstrap.sh引导脚本用来生成b2。b2.exe或b2编译驱动工具生成后就在这里。boost/目录所有头文件。libs/目录各库源码。tools/build/b2的配置文件。看到这些就可以进入下一步了。记得先别动目录里的任何文件直接编译。3. 分平台编译实操bootstrap与b2参数详解3.1 Windows下完整编译流程打开“x64 Native Tools Command Prompt for VS 2022”进入源码目录cd C:\boost_1_84_0 bootstrap.batbootstrap.bat运行结束检查当前目录下有没有生成b2.exe。如果没有说明脚本没能找到VS环境多半是你没有在VS的命令行窗口里跑或者VS安装时没勾C桌面开发。接下来执行编译命令。我第一次编译时不加任何参数结果浪费了40多分钟把160多个库全编了一遍后来发现完全没必要。这里给出我实际使用的参数b2.exe toolsetmsvc-14.3 address-model64 linkstatic runtime-linkshared threadingmulti variantrelease --stagedirstage --with-system --with-thread --with-date_time --with-regex --with-filesystem --with-atomic -j8这行命令的意图用MSVC 14.3生成64位Release多线程静态库只处理asio链路需要的6个库8路并行编译输出到当前目录下的stage文件夹。编译过程大概持续5到15分钟取决于CPU核心数。我这边8核16线程编这几个库大概6分钟。中途如果看到大段红色error先别急着关窗口把错误信息截下来跳到第4章对照排查。编译成功会看到类似这样的一行...updated 123 targets...然后去C:\boost_1_84_0\stage\lib看生成的.lib文件。你会看到类似libboost_system-vc143-mt-x64-1_84.lib的文件名。这个命名规则后面还会反复用到先记住它的含义。3.2 Linux下完整编译流程Linux下的bootstrap更简单cd ~/boost_1_84_0 ./bootstrap.sh --prefix/usr/local/boost--prefix可以指定最终安装路径。如果你不想污染系统目录用/usr/local/boost这样的独立路径就很好。然后执行编译./b2 stage --stagedir/home/user/boost_1_84_0/stage toolsetgcc address-model64 linkstatic,shared threadingmulti variantrelease --with-system --with-thread --with-date_time --with-regex --with-filesystem --with-atomic -j$(nproc)和Windows版命令的区别主要有两个一是linkstatic,shared。Linux下很多工程喜欢同时备着静态库和动态库我两个都编了。注意用逗号连起来表示两种都要。二是-j$(nproc)。nproc会返回CPU逻辑核数直接把它注入-j参数不用手工数。8核机器就是-j8。编译时间比Windows稍短我这边6核机器大约4分钟。结束后在stage/lib目录下会生成libboost_system.a、libboost_system.so等文件。注意看.so结尾的动态库后面通常会带一个版本号软链接比如libboost_system.so.1.84.0这是正常的。如果只stage不install库就不会安装到系统目录这是我自己比较喜欢的方式所有东西都锁在项目目录里后面做CMake找库路径也方便。如果你希望全系统都能用#include boost/asio.hpp那就跑sudo ./b2 install --prefix/usr/local/boostinstall会把头文件复制到/usr/local/boost/include库复制到/usr/local/boost/lib。3.3 b2核心参数逐项拆解不只复制要彻底理解b2是Boost构建系统的驱动命令能力非常强大但参数含义不搞懂的话经常是“编译一时爽链接火葬场”。下面这些参数是asio开发绕不开的一个个说清楚toolset指定编译器。Windows下用msvc-14.3对应VS2022、msvc-14.2VS2019、msvc-14.1VS2017。Linux下通常toolsetgcc但如果你用Clang也可以指定toolsetclang。编译器不匹配时b2会直接忽略你的源码并报错所以这个参数务必跟实际环境一致。link生成静态库static还是动态库shared或两者都要static,shared。asio核心使用静态库最省心因为libboost_system.a会被直接打包进你的可执行文件部署时不用带一堆so。但如果你的项目要搞插件架构、追求动态更新那就得选shared。这里决定后面链接命令怎么敲必须提前定好。runtime-link链接运行库的方式。Windows下有两种shared对应动态运行库/MDstatic对应静态运行库/MT。如果这里选shared那编译出来的lib就会带-vc143-mt标记链接到项目时要确保项目配置也是“多线程DLL”运行库。我用runtime-linkshared是主流默认后面讲VS项目配置时会再次对应上。threading多线程支持asio网络编程不可能不用多线程所以固定multi。variantrelease还是debug。如果工程需要调试建议单独再编一次variantdebug否则后面调试时符号对不上。address-model32位还是64位V160版本默认64位没问题。--with-xxx只编译指定的库这是个好习惯。它的反面是--without-xxx——表示“除了这些其他都编”。我推荐用--with白名单方式编译量小且更容易控制错误范围。--stagedir库输出目录。可以用相对路径或绝对路径我习惯用绝对路径避免跟源码目录混在一起。-j并行编译任务数。设成核心数即可太大会导致内存爆掉太小编译慢。3.4 为什么asio只需要这几个配套库就够用了我们来盘一下为什么我只挑了system、thread、date_time、regex、filesystem、atomic这6个库。这一步能帮你以后少编一堆没用的东西。system提供boost::system::error_code和error_category。asio的所有异步操作都拿error_code返回结果没有system库你连错误处理都写不了。thread异步网络编程里线程池、std::thread、boost::thread的封装都在这里。你需要它做线程同步、创建io_context运行线程。date_timeasio的定时器steady_timer、deadline_timer依赖时间类型这个库是必须的。regex严格说asio不需要regex但是如果后续工程要做HTTP/WebSocket解析正则表达式几乎是刚需我提前编出来备着。filesystem文件传输类网络服务一定会用到比如服务器把磁盘文件发给客户端路径操作和文件读写全靠它。atomic多线程编程的原子操作库很多boost并发组件都依赖它编上没坏处。至于其他的——python不要因为我们做的是C网络服务原生程序locale不要地区化对socket处理没有任何帮助graph不要、wave不要、coroutine暂时也用不上。需要时随时回来再编对应的库就行boost支持增量编译补编很快。4. 编译期高频报错排雷完整排查链路与解决方案4.1 “cl.exe找不到”是环境问题不是Boost问题这是Windows平台最常见的拦路虎。报错信息长这样error: No best alternative for /home/user/... error: failed to build Boost.Build engine或者更直接一点cl不是内部或外部命令。这个问题的根因特别简单bootstrap.bat在执行时需要调用cl.exe来编译Boost.Build引擎而cl.exe在普通cmd的PATH里根本不存在。它藏在VS安装目录里并且需要一大堆额外的环境变量配合才能正常工作。解决办法只有一个关掉普通命令行重新打开“x64 Native Tools Command Prompt for VS 2022”。这个入口的本质是自动运行了vcvars64.bat把INCLUDE、LIB、PATH全部配好。如果你用的是其他终端工具也可以手动执行C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvars64.bat注意看你VS安装的具体版本路径Professional和Enterprise的目录名不一样。每次新开窗口编译前都确认一遍环境这个动作养成习惯就不会栽在这里。4.2 Python.h缺失以及其他无关模块的拖累Linux上如果你不带任何--with参数直接全量编译大概率会遇到这种事情fatal error: Python.h: No such file or directory或者Windows上报pyconfig.h找不到。原因是Boost.Python库需要Python开发头文件而系统里一般没装。这种问题其实是最冤枉的——你根本没打算用Boost.Python结果是它拖垮了整个编译流程。解法有两个一是装Python开发头文件但如果你的Python是conda或其他发行版头文件路径本身就会出幺蛾子跟b2兼容性又是一堆事二是干脆不编它用白名单方式./b2 ... --with-system --with-thread --with-date_time --with-regex --with-filesystem --with-atomic一旦用--with-xxx列出明确要编的库boost就只处理这些Python、ICU、OpenSSL那些依赖全部绕开。这也是我强烈推荐白名单模式的原因。还有一个Linux上常见问题b2: error while loading shared libraries: libb2.so...。这是你自己之前装过别的版本b2且路径混乱造成的检查PATH里的b2位置确保用的是当前目录下刚生成的./b2。4.3 编译器与平台位数不匹配静动态库互相打架链接阶段经常出现这类错误fatal error LNK1104: cannot open file libboost_system-vc142-mt-x64-1_84.lib如果你明明用的是VS2022为什么它找的是vc142因为编译boost时用的toolsetmsvc-14.2或者是项目配置里继承了某个旧版工具集。解决办法是让“boost编译工具集”和“项目工具集”严格一致。VS2022对应msvc-14.3项目属性里展开“C/C”的“平台工具集”确认选的是v143。再有一种情况编译boost时没指定address-model64默认编出32位库而项目是x64平台链接时也会找不到对应lib。Linux下情况类似file libboost_system.a看一下生成的库是x86-64还是i386跟uname -m比对。另一种极其隐蔽的坑是“静态库和动态运行库混用”。用linkstatic编出来的静态库如果编译时runtime-linkshared/MD那链接到MSVC项目时项目必须也设置为“多线程DLL”/MD。如果项目配的是“多线程”/MT那会出现一堆抽象的LNK2038运行时库不匹配错误。这个错非常抓狂因为报错位置根本不指向boost库而是一堆系统库。记住boost编译参数里的runtime-link和MSVC项目里的“运行库”选项必须一一对应。4.4 编译到一半机器卡死或OOMBoost编译是出了名的吃内存。-j8不是万能的在虚拟机里跑4G内存根本不扛不住。b2会同时启动8个编译进程每个进程都要吃数百MB内存加上仓库本身的负担很容易直接OOM。我的经验是先看机器配置。物理机16G内存用-j8没问题虚拟机8G就别逞强老老实实-j4甚至-j2。如果已经OOM了kill掉乱跑的进程后别急着重新全量编译——Boost支持断点续编不会重新编译已经编好的部分直接用更小的-j参数重新执行相同命令行它会接着上次的进度继续。还有一个容易被忽略的Windows上杀毒软件会实时扫描生成的每个.obj和.lib文件拖慢速度不说偶尔还会把正写了一半的文件锁住导致编译失败。我在自己的机器上踩过一次后来直接把stage目录加进了杀毒排除列表编译速度和稳定性都立竿见影。4.5 VS2019/2022中Debug与Release混杂的隐患如果你平时调试时用Debug构建正式发布用Release那么你可能会遇到一个很恶心的问题boost库只有Release版本Debug下链接时报找不到libboost_system-vc143-mt-gd-x64-1_84.lib。注意文件名里的gd两个字母——这是Debug版本lib的专属标记。也就是说Debug构建必须配Debug编译的boost库。解决方法是编译两次一次variantrelease一次variantdebug。同样用--with白名单花不了多少时间。或者你的项目长期只用Release构建那就把项目属性里的调试运行时库改成Release对应的多线程DLL不过这会失去一些调试保护我不推荐为了省编译时间而牺牲调试能力。推荐做法我直接给参数b2.exe toolsetmsvc-14.3 address-model64 linkstatic runtime-linkshared threadingmulti variantrelease --stagedirstage --with-system --with-thread --with-date_time --with-regex --with-filesystem --with-atomic -j8 b2.exe toolsetmsvc-14.3 address-model64 linkstatic runtime-linkshared threadingmulti variantdebug --stagedirstage --with-system --with-thread --with-date_time --with-regex --with-filesystem --with-atomic -j8两次编译输出到同一个stage/lib目录boost会自动区分文件名互不干扰。5. asio工程的真实链接验证从最小demo跑到CMake配置编译安装只是过程真正要验证的是asio代码能不能顺畅编译链接。这一节我带你从零跑通一个最小开发示例。5.1 最小asio示例用DNS解析验证整条链路新建一个test_asio.cpp内容如下#include boost/asio.hpp #include iostream #include string int main() { boost::system::error_code ec; boost::asio::io_context io; boost::asio::ip::tcp::resolver resolver(io); auto results resolver.resolve(www.boost.org, https, ec); if (ec) { std::cerr resolve failed: ec.message() std::endl; return -1; } for (const auto entry : results) { std::cout entry.endpoint().address().to_string() std::endl; } return 0; }这个demo干了三件事创建一个io_contextasio事件循环的最小单元、创建一个TCP域名解析器、解析某个域名并打印IP。它能跑通就说明asio头文件、system库、thread库、网络库全部就绪。如果你是在C11以上boost::asio::io_context可以直接无参构造不需要传外部io_contextip::tcp::resolver::resolve返回的endpoint也能直接拿到地址。5.2 Linux下g手工编译命令g -stdc17 test_asio.cpp -I/usr/local/boost/include -L/usr/local/boost/lib -lboost_system -pthread -o test_asio如果库在stage/lib而头文件还在源码目录下那就写g -stdc17 test_asio.cpp -I/home/user/boost_1_84_0 -L/home/user/boost_1_84_0/stage/lib -lboost_system -pthread -o test_asio解释下几个关键点-lboost_system对应libboost_system.a这是asio错误处理依赖的库。-pthread是必须的asio底层会用到线程原语不加会在链接期报undefined reference to pthread_create。如果编译时报boost/asio.hpp: No such file or directory说明-I路径没指对头文件在boost源码根目录。运行./test_asio正常会输出两个IPv4地址或一个IPv6地址。如果输出resolve failed先ping一下网络或换一个域名再试。5.3 Windows下的VS项目配置与CMake配置Windows下新建一个控制台项目把test_asio.cpp添加进来然后按这几步配项目属性 - C/C - 常规 - 附加包含目录加入C:\boost_1_84_0。链接器 - 常规 - 附加库目录加入C:\boost_1_84_0\stage\lib。链接器 - 输入 - 附加依赖项加入libboost_system-vc143-mt-x64-1_84.lib。C/C - 代码生成 - 运行库确认是“多线程DLL”/MD和编译boost时runtime-linkshared对应。如果你不想手写lib文件名也可以加入宏BOOST_ALL_NO_LIB这个宏告诉boost“不要自动链接”。但注意自动链接机制本来是方便你少写一个lib名的只有在报错的时候我才会用BOOST_ALL_NO_LIB强制关闭它然后手工指定lib。CMake项目里我推荐这种方式干净利落cmake_minimum_required(VERSION 3.16) project(asio_demo LANGUAGES CXX) set(BOOST_ROOT C:/boost_1_84_0) set(BOOST_LIBRARYDIR C:/boost_1_84_0/stage/lib) find_package(Boost 1.84.0 REQUIRED COMPONENTS system) add_executable(test_asio test_asio.cpp) target_link_libraries(test_asio PRIVATE Boost::system) target_compile_features(test_asio PRIVATE cxx_std_17) if(NOT WIN32) find_package(Threads REQUIRED) target_link_libraries(test_asio PRIVATE Threads::Threads) endif()CMake会通过Boost::system的target自动帮你处理include路径和lib路径比手工配置省心太多。在Linux上如果boost没有install到系统目录记得把BOOST_ROOT设成你的boost源码根目录。5.4 运行时报“找不到boost_system.dll”的处理逻辑Windows下如果你用linkshared编译boost运行程序时可能会弹窗提示找不到boost_system-vc143-mt-x64-1_84.dll。这不是编译错误是动态库没有复制到可执行文件旁边或PATH里。解决方案有三个按我个人偏好排序一是项目里尽量用静态库linkstatic可执行文件自包含部署时少操一份心。我日常开发基本都是静态链接。 二是把stage/lib下对应的dll文件复制到编译输出目录比如x64/Release/下跟exe放一起。 三是把stage/lib路径加到系统PATH环境变量里。这个最省事但也会带来“版本混乱触发器”的隐患——多个项目各自依赖不同版本boost时系统PATH里那个老版本会横插一杠子。5.5 代码里要不要定义BOOST_ASIO_STANDALONEBOOST_ASIO_STANDALONE是一个让人容易困惑的宏。它表示“用自己的standalone asio模式运行”此时asio不依赖Boost.System、Boost.Thread等库而是使用C标准库的std::error_code、std::thread等。如果你定义了这个宏理论上可以不链接libboost_system因为错误处理全部切到标准库了。但问题是你的工程其他部分可能还会用到boost的filesystem、regex等这些库仍然需要链接。我个人的建议是在原生boost模式下就老老实实不定义这个宏让asio走完整boost依赖这样最不容易产生“这个能用那个不能用”的割裂感。等以后你觉得自己对asio足够熟了再考虑引入standalone模式和ASIO独立版本。6. 版本选择建议与下一步规划6.1 boost版本怎么挑最新版是不是最好的很多人喜欢一上来就选最新版boost觉得新版本特性全、修bug多。但实际工程里版本选择要综合评估。如果只是学习asio我推荐选一个稳定了半年以上的版本比如1.84.0或1.85.0。这些版本出来有一段时间网上的教程、博客、论坛问题沉淀都比较多踩坑有迹可循。赶上boost刚发布1.86那阵子社区相关编译问题和FAQ还没更新到位自己查资料会很费劲。如果你的项目要跟其他第三方库联动还需注意版本兼容。比如OpenSSL、CMake、编译器之间都存在一个ilib兼容矩阵boost版本过老或过新都会导致find_package(Boost)时版本校验不过。记住一个检查命令Linux下./b2 --version grep BOOST_LIB_VERSION boost/version.hppWindows下也可以在源码目录的boost/version.hpp里看到#define BOOST_LIB_VERSION 1_84确认你编的到底是不是想要的版本。6.2 我个人的建议初期用小而精的库集合跑通在我的开发流程里asio网络模块通常不会一开始就把boost全家桶引入工程。先只编译文章开头那几个库都是精打细算过的不会出现“编译通过但用不上”的资源浪费。等你确认asio链路能稳定运行再根据项目需求增量编译更多库。boost的优势就在这它能随用随编不像某些库必须一次全量依赖。接下来这个系列我准备沿着这条路径继续深入用asio写一个能处理并发连接的TCP回显服务再把它扩展成一个结构完整的echo server的线程池模型然后加入boost::asio::ip::tcp::acceptor的异步接收、async_read/async_write的协议解析再往后可能会碰Beast库做WebSocket服务以及同步/异步的性能对比测试。这一篇的目录结构打好了后面每篇文章的代码都会基于你刚才编出来的这套库来跑。6.3 随便聊几句题外话网络编程的起点很多人看asio的异步模型第一眼都是懵的io_context是什么async_read为什么不返回值handler为什么用lambda包了一层又一层不要怕这是每一个C网络编程新手都要跨过的坎。asio把自己的抽象层做得非常直观——你可以把io_context理解成一个专门处理“网络事件”的事件循环类似GUI程序里的消息泵所有异步操作完成时都会回调你注册的handler放在队列里排队执行。这一套模型你一旦跑通第一个completion handler后面就水到渠成了。不过那都是之后的文章了。这一篇的核心目标只有一个把boost库源码编译安装这一步彻底走通。无论你是Windows还是Linux把b2参数理解透把链接问题想明白后面写异步网络代码时就不用再被环境问题折腾了。要说的都说了剩下的就是动手执行。