1. 先说清楚为什么要折腾 restbedC 社区里 RESTful 框架不少轻量的有 cpp-httplib、Drogon重量级的直接上 Boost.Beast 手搓。restbed 的位置比较特别它走的是异步非阻塞路线底层基于 Boost.Asio接口设计上又刻意往 Java 系 REST 框架的风格靠。如果你之前写过 Jersey、Spring MVC 那套注解风格再看 restbed 的 Resource 注册方式会非常亲切。这个框架适合谁适合对第三方库依赖敏感、需要在嵌入式设备或 Linux 服务器上快速搭一个 JSON API 服务的人。restbed 核心库体积小编译产物干净不强制绑定某个 Web 容器也没有一堆运行时依赖。和 Drogon 相比它更轻和 cpp-httplib 相比它多了完整的异步模型能扛更高并发。当然它也有缺点——文档常年处于“半失踪”状态API 变动过几次社区活跃度一般所以很多人在编译阶段就被劝退了。我这次是在 Ubuntu 20.04 和 Windows 10 两个环境分别编译的过程中踩了不少坑包括 OpenSSL 链接问题、CMake 版本过旧、Windows 下静态库运行库不一致导致的崩溃。这篇笔记就是把整个编译过程、遇到的问题和排查思路完整记录下来给后来的人省点时间。2. 编译前需要先搞清楚的几件事2.1 restbed 的源码结构和工作原理在敲任何编译命令之前我建议你先理解 restbed 的源码组织方式。项目托管在 GitHub 上核心代码在source/目录下主要模块包括restbed核心库包含 Service、Resource、Request、Response、Session 等核心类asio子模块restbed 使用的异步网络库是 Boost.Asio 的独立版本openssl子模块如果启用 HTTPS 支持需要链接 OpenSSLrestbed 的工作模式是事件驱动的。Service 对象负责监听端口收到 HTTP 请求后把它封装成 Session然后根据 URI 匹配到对应的 Resource 上。Resource 上注册了不同 HTTP 方法的回调函数这些回调在异步线程池里执行。理解了这个模型你就知道编译时为什么要关注线程和 SSL 相关的配置了。2.2 编译一个开源 C 库到底在编译什么很多人拿到源码就执行cmake .. make报错了就懵。编译 restbed 本质上是三件事第一编译生成librestbed静态库或动态库。这需要把source/下几十个.cc文件逐个编译成目标文件再打包成库文件。第二处理依赖关系。restbed 的 CMakeLists.txt 里有add_subdirectory逻辑会把 asio 和 openssl 一起编进来。如果你系统里已经装了 OpenSSLCMake 优先用系统库否则使用项目自带的第三方库。第三生成头文件引用路径和链接配置。编译完库之后你的项目代码要能#include restbed并正确链接这涉及到头文件路径、库搜索路径、链接顺序等一系列问题。很多编译错误其实不是代码问题是这三层里某一层没配对编译器版本不够新、CMake 版本太老、OpenSSL 版本不兼容、头文件路径不对、链接顺序错误。2.3 版本选择与依赖环境的坑restbed 的 master 分支更新不算频繁但偶尔会有提交变动 API。我建议直接拉最新 release 版本不要用 master。目前稳定版本是 4.7 左右具体以官方发布为准老版本比如 4.6 及之前用的是老式 CMake 配置新版改进了不少。依赖方面重点说三个一是 CMake 版本。restbed 要求 CMake 3.5但如果你用 Ubuntu 18.04 自带的 CMake 3.10某些配置项依然可能出问题。建议直接用 CMake 3.16 以上版本没有别的原因就是省事。二是编译器。GCC 5.4 以下的版本对 C14 的支持不完整restbed 代码里用了一些 C14 特性如果编译器太老会出现各种莫名其妙的模板报错。三是 OpenSSL。restbed 的 HTTPS 支持依赖 OpenSSL 1.1 及以上版本。Ubuntu 20.04 自带 OpenSSL 1.1.1没问题但如果你在 CentOS 7 上默认的是 OpenSSL 1.0.2编出来的代码在 TLS 握手时会出问题。Windows 的话推荐用 vcpkg 装 OpenSSL自己编译容易踩坑。提示如果你只想压测功能、不需要 HTTPS可以在 CMake 配置阶段加上-DBUILD_SSLOFF和-DBUILD_TESTSOFF能省掉 OpenSSL 这个最大的坑编译速度也快不少。3. 完整编译流程详解Linux 与 Windows3.1 Linux 下的编译步骤以 Ubuntu 20.04 为例第一步是安装基础工具链sudo apt update sudo apt install -y build-essential cmake git libssl-dev然后拉取代码git clone https://github.com/Corvusoft/restbed.git cd restbed这里有个关键细节restbed 仓库带了子模块但如果你不需要 HTTPS可以直接用 CMake 的选项关掉不用拉子模块。如果需要 HTTPS先更新子模块git submodule update --init --recursive接下来是 CMake 配置。我强烈建议用独立 build 目录不要在源码目录里直接编否则以后想清理很麻烦mkdir build cd build cmake -DCMAKE_BUILD_TYPERelease -DBUILD_TESTSOFF -DBUILD_EXAMPLESOFF ..注意-DBUILD_TESTSOFF这个参数restbed 的测试代码依赖 Catch2不开这个选项的话CMake 会自动下载 Catch2如果你网络不好或者在公司内网这一步能卡死你。同样道理-DBUILD_EXAMPLESOFF能省掉示例代码的编译加快速度。配置完成后直接编译make -j$(nproc)nproc是查看 CPU 核数-j参数指定并行编译任务数。我机器是 8 核编译整个项目大概两分钟不到。编译完成之后检查一下产物ls lib/正常会看到librestbed.so或librestbed.a取决于你在 CMake 里有没有设置BUILD_SHARED_LIBS。默认是生成静态库librestbed.a要动态库的话在 cmake 配置时加-DBUILD_SHARED_LIBSON。最后安装sudo make install默认会装到/usr/local/头文件在/usr/local/include/restbed/库文件在/usr/local/lib/。装完记得跑一下sudo ldconfig让动态链接库缓存更新。3.2 Windows 下的编译方式与 VS 版本选择Windows 下编译 restbed 有两种主流方式用 CMake Visual Studio或者用 vcpkg。先说你最容易踩的坑Visual Studio 版本。restbed 官方测试主要是在 VS2017 和 VS2019 上做的VS2022 也能编但要注意运行库设置。更关键的是如果你打算把 restbed 静态库链接到自己项目里必须确保 restbed 编译时的运行库/MT 或 /MD和你的项目一致否则会出现链接错误或者运行时崩溃。这个问题我后面在“常见问题”章节专门展开。用 CMake VS 的完整流程先装好 Visual Studio 2019 或 2022勾选“使用 C 的桌面开发”工作负载。再装 CMake 和 Git都勾选“添加到 PATH”。然后打开“开发者命令提示符”或者直接用 PowerShell 进入源码目录git clone https://github.com/Corvusoft/restbed.git cd restbed mkdir build cd build cmake .. -G Visual Studio 16 2019 -A x64 -DBUILD_TESTSOFF -DBUILD_EXAMPLESOFF cmake --build . --config Release注意-A x64必须加否则默认生成 Win32 平台出来的库是 32 位的。CMake 配置完成后build 目录里会生成.sln解决方案文件你可以用 Visual Studio 打开它右键restbed项目选择“生成”也可以直接用命令行cmake --build。编译完成后库文件在build/Release/目录下。Windows 下静态库是restbed.lib动态库会额外生成restbed.dll和导入库restbed.lib。如果你想省事直接用 vcpkg 也可以git clone https://github.com/Microsoft/vcpkg.git cd vcpkg .\bootstrap-vcpkg.bat .\vcpkg integrate install .\vcpkg install restbedvcpkg 会自动帮你编译好合适的版本并且处理 OpenSSL 的依赖。不过 vcpkg 装的是它自己维护的版本可能不是最新但稳定性有保障。如果你只是要用、不是要研究源码推荐走这条路。3.3 全静态编译把 restbed 编进你的可执行文件很多场景下比如部署到内网服务器你希望编译出来的可执行文件是不依赖动态库的这样拷过去就能跑。这涉及到全静态编译。Linux 下做全静态编译需要在 CMake 配置时指定cmake -DCMAKE_EXECUTABLE_LINKER_FLAGS-static ..但这里有个大坑静态链接 OpenSSL 时如果系统只装了动态版的 libssl.so链接器会报找不到-lssl。你需要装 OpenSSL 的开发静态库sudo apt install -y libssl-devUbuntu 的 libssl-dev 只带.so软链接和.a静态库一般是齐全的。但如果你的目标机器是精简系统编译机上没有静态库那就要自己从源码编一个 OpenSSL 静态库出来。我这里给你一个完整的全静态编译命令序列# 先编译安装 OpenSSL 静态库到 /opt/openssl-static cd /tmp wget https://www.openssl.org/source/openssl-1.1.1w.tar.gz tar xzf openssl-1.1.1w.tar.gz cd openssl-1.1.1w ./config --prefix/opt/openssl-static no-shared make -j$(nproc) sudo make install # 再编译 restbed指定使用刚才的静态 OpenSSL cd /path/to/restbed rm -rf build mkdir build cd build cmake .. \ -DCMAKE_BUILD_TYPERelease \ -DBUILD_TESTSOFF \ -DBUILD_EXAMPLESOFF \ -DCMAKE_EXECUTABLE_LINKER_FLAGS-static \ -DOPENSSL_ROOT_DIR/opt/openssl-static \ -DOPENSSL_INCLUDE_DIR/opt/openssl-static/include \ -DOPENSSL_CRYPTO_LIBRARY/opt/openssl-static/lib/libcrypto.a \ -DOPENSSL_SSL_LIBRARY/opt/openssl-static/lib/libssl.a make -j$(nproc)编译你自己的程序时同样要指定全静态链接g -stdc14 -static myapp.cpp -I/opt/openssl-static/include \ -L/path/to/restbed/build -lrestbed \ -L/opt/openssl-static/lib -lssl -lcrypto -lpthread -ldl注意链接顺序restbed 依赖 OpenSSL所以-lrestbed必须在-lssl和-lcrypto前面。GNU 链接器是单遍扫描库顺序错了直接报undefined reference。3.4 交叉编译把 restbed 编到 ARM 或其他指定平台问“pppd 怎么编译到指定平台”的人大概率是在做嵌入式开发。restbed 也常被用在树莓派、ARM 开发板上。交叉编译的本质是用一套工具的编译器生成另一种架构的代码。关键是要告诉 CMake 三件事用哪个编译器、目标平台是什么、依赖库在哪里。以树莓派 ARM64 为例先安装交叉编译工具链sudo apt install -y gcc-aarch64-linux-gnu g-aarch64-linux-gnu然后写一个工具链文件toolchain-rpi64.cmakeset(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR aarch64) set(CMAKE_C_COMPILER aarch64-linux-gnu-gcc) set(CMAKE_CXX_COMPILER aarch64-linux-gnu-g) set(CMAKE_FIND_ROOT_PATH /usr/aarch64-linux-gnu) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)配置时指定工具链文件mkdir build-arm64 cd build-arm64 cmake .. -DCMAKE_TOOLCHAIN_FILE../toolchain-rpi64.cmake \ -DCMAKE_BUILD_TYPERelease \ -DBUILD_TESTSOFF \ -DBUILD_EXAMPLESOFF make -j$(nproc)交叉编译最大的坑不在 restbed 本身而在 OpenSSL。因为 OpenSSL 的 configure 脚本会检测主机环境交叉编译时需要用perl Configure指定目标平台不能直接 ./config。你可以选择在目标板子上编译 OpenSSL或者用工具链的 sysroot 里的 OpenSSL 静态库。最稳妥的做法是把 OpenSSL 的源码放到目标板子上在板子上编好再拷回来用——虽然麻烦但不会出错。注意交叉编译时只要你的代码里用到了std::thread、std::mutex这类 C11 线程库链接阶段都必须加-lpthread。restbed 本身用了 AsioAsio 在多线程环境下依赖 pthread忘了这个链接参数程序跑起来会直接崩溃。4. 编译过程中的常见问题与排查技巧4.1 OpenSSL 相关的链接错误这是 restbed 编译中最常见的报错没有之一。表现形式是链接时报undefined reference to SSL_CTX_new undefined reference to SSL_new或者cannot find -lssl先说根因restbed 在开启 HTTPS 支持时CMake 需要找到 OpenSSL 的头文件和库文件。有几种情况会导致失败第一种系统里根本没装 OpenSSL 开发库。Ubuntu 上要装libssl-devCentOS 上要装openssl-devel。Restbed 的 CMake 检测不到 OpenSSL 会怎样分版本有的版本直接报错退出有的版本默默把 SSL 功能关掉。如果编出来之后发现Service::set_ssl相关方法不存在大概率就是 SSL 功能被禁了。第二种装了但 CMake 找不到路径。这通常发生在 OpenSSL 装到自定义目录的场景。你可以在 CMake 配置时手动指定cmake .. -DOPENSSL_ROOT_DIR/usr/local/ssl -DOPENSSL_INCLUDE_DIR/usr/local/ssl/include第三种OpenSSL 版本太老。OpenSSL 1.0.2 和 1.1.x 的 API 有差异restbed 用的是 1.1.x 的 API如果 CMake 找到了 1.0.2编出来的代码在运行时会段错误。排查方式是跑openssl version如果版本是 1.0.2建议换系统或者自己编译新版。还有个容易忽视的点OpenSSL 1.1.1 之后TLS 1.0 和 TLS 1.1 默认是禁用的如果客户端只支持老协议握手会失败。这不算编译问题但你在调试 HTTPS 接口时会遇到先知道有这个坑。4.2 CMake 缓存导致的“改了什么没生效”这个问题我从 Code::Blocks 时代就开始踩换了 VS 也一样踩。现象是你改了 CMakeLists.txt 或者加了某个编译选项重新跑cmake甚至make clean之后编译行为没有变化还带着旧的配置。根因是 CMakeCache.txt。CMake 会把第一次配置时的选项缓存下来后续再跑 cmake它默认不会覆盖你之前指定的值。比如你第一次编译时设了-DBUILD_TESTSON后来想改成 OFF光在命令行写-DBUILD_TESTSOFF是没用的CMake 会保留缓存里的 ON。解决办法很简单删掉 build 目录重新建。如果你不想全部重编可以在 build 目录下手动删掉 CMakeCache.txt但小心别把别的配置也删了。我的习惯是给不同配置建不同的构建目录比如build-release、build-debug、build-arm64互不干扰。这样既节省重新配置的时间也避免了缓存串味。4.3 Windows 下运行库不一致导致的链接错误这个坑非常隐蔽遇到的人十有八九要折腾半天。Windows 下 Visual Studio 编译 C 时每个项目都可以选运行库模式/MT静态链接运行时、/MD动态链接运行时。Debug 版本对应/MTd和/MDd。如果 restbed 用/MD编译成静态库而你的项目用/MT编译链接时会报类似这样的错误error LNK2038: mismatch detected for RuntimeLibrary: value MT_StaticRelease doesnt match value MD_DynamicRelease解决方案是统一运行库设置。在 Visual Studio 里你的项目属性 - C/C - 代码生成 - 运行库改成和 restbed 一致的模式。或者更简单直接用 vcpkg 装 restbedvcpkg 默认支持动态和静态两种模式你看一下你项目的设置选对应的模式安装# 静态链接 .\vcpkg install restbed:x64-windows-static # 动态链接 .\vcpkg install restbed:x64-windows提一句有些人在 VS 里生成但找不到 lib 文件在哪。Windows 下 CMake 生成的解决方案按配置分目录Release/、Debug/、x64/Release/等等。不要在根目录翻直接去对应目录找。还有restbed 的项目名可能叫restbed也可能叫restbed_static取决于 CMake 配置。别只找restbed.lib也看看restbed_static.lib。4.4 编译器报“文件无法打开”或者头文件找不到这个问题在 Windows 上比较常见尤其是不用 vcpkg 而是手动下载源码的人。报错一般是fatal error C1083: Cannot open include file: boost/shared_ptr.hpp: No such file or directory注意restbed 早期版本依赖 Boost后来的版本已经改成使用独立的 asio不再依赖 Boost。如果你拉的是老版本源码或者某些分支它可能还在用 Boost 头文件。解决方法是给 CMake 指定 Boost 路径或者直接切到新版源码。另外一个头文件找不到的场景是你自己的工程里#include restbed报错。这通常是你只设置了库路径、没设置头文件路径。在 CMakeLists 里加include_directories(/usr/local/include) target_link_libraries(your_target restbed)或者用find_package的方式不过 restbed 官方并没有提供标准的 CMake config 文件所以通常还是手动指定路径。4.5 编译速度太慢怎么办如果你用的是 keil5编译慢是天经地义的与 restbed 无关。但如果你用 GCC 或 VS 编 restbed 觉得很慢多半是没开并行编译。Linux/macOS 下make -j$(nproc)Windows 下用 CMakecmake --build . --config Release -- /m/m是 MSBuild 的并行编译参数等价于 Linux 的-j。另外如果只是改了自己项目的代码不需要重新编 restbed。restbed 编译一次生成库文件后你的项目直接链接就行。不要每次都在你的项目里add_subdirectory(restbed)让它参与全量编译——这是很多人编译慢的根本原因。4.6 编译期异常的排查思路所谓“编译期异常”我理解为编译或链接过程中的任何非预期错误。经验来看80% 的编译问题按以下顺序排查都能解决第一步确认工具链版本符合要求。g --version要 6.0 以上cmake --version要 3.10 以上。我见过太多人用 Ubuntu 16.04 自带的 GCC 5.4 编译 C14 项目报各种模板错误。第二步确认依赖完整。restbed 的依赖是 asio 和 OpenSSLasio 在 restbed 子模块里OpenSSL 需要系统安装。缺哪个编译阶段就会报错。第三步清理重来。很多“玄学”编译错误删掉 build 目录重新 configure 就解决了。CMake 缓存、残留对象文件、头文件缓存都可能引发幽灵问题。第四步看完整日志。不要只看最后几行。用make -j$(nproc) 21 | tee build.log把完整输出存下来搜索error:定位第一个报错位置。第一个错误才是根因后面的往往是连锁反应。5. 编译完成后如何验证 restbed 是否可用5.1 检查产物完整性编译成功不等于链接成功。我习惯编译后马上检查三样东西第一库文件是否存在。静态库和动态库的大小是不是合理。librestbed.a正常在几 MB 到十几 MB 之间如果只有几十 KB八成是只编了个空壳或者在链接阶段被裁剪了。第二头文件是否齐全。include/restbed/目录下至少要有restbed这个主头文件以及detail/子目录下的内部头文件。如果你只拷贝了主头文件编译自己项目时能过链接时大概率报undefined reference。第三符号是否完整。Linux 下可以用 nm 检查nm -C lib/librestbed.a | grep restbed::Service::startWindows 下可以用dumpbin /symbols restbed.lib或者用llvm-nm。如果关键方法没有导出说明编译时宏定义有问题。5.2 用最小示例验证功能我在编译完任何库之后都会写一个最小程序验证基础功能。for restbed我最常用的是这个#include memory #include restbed using namespace std; using namespace restbed; int main( ) { auto resource make_shared Resource ( ); resource-set_path( /hello ); resource-set_method_handler( GET, [ ]( const shared_ptr Session session ) { session-close( OK, Hello, Restbed!, { { Content-Length, 17 } } ); } ); auto settings make_shared Settings ( ); settings-set_port( 1984 ); Service service; service.publish( resource ); service.start( settings ); return 0; }编译命令g -stdc14 hello.cpp -I/usr/local/include -L/usr/local/lib -lrestbed -lpthread -o hello如果编译链接通过运行后在另一个终端curl http://localhost:1984/hello能返回Hello, Restbed!就说明库基本可用。注意我代码里显式写了Content-Length: 17这是 restbed 的一个特性——它不会自动帮你算 Content-Length如果你不写响应头某些 HTTP 客户端会一直等不到响应结束因为响应体长度未知、连接也没有关闭。这个细节几乎每个新手都会踩到。5.3 一个完整的 CMake 工程示例如果你在自己的项目里用 restbed我建议像下面这样组织 CMakeLists.txtcmake_minimum_required(VERSION 3.10) project(MyRestbedApp CXX) set(CMAKE_CXX_STANDARD 14) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 指定 restbed 安装路径如果 restbed 在系统默认路径可以注释掉 set(RESTBED_ROOT /usr/local) include_directories(${RESTBED_ROOT}/include) link_directories(${RESTBED_ROOT}/lib) add_executable(myapp main.cpp) target_link_libraries(myapp restbed pthread dl crypto ssl)dl是为了链接动态库加载器如果你是全静态编译可以去掉。crypto和ssl是 OpenSSL 的库restbed 开启 HTTPS 后必须链接。少一个pthread程序跑起来会莫名崩溃少ssl和crypto链接会报 undefined reference。6. 几个深入使用的经验补充6.1 理解 restbed 的线程模型避免隐性 bugrestbed 默认会启动一个线程池线程数等于 CPU 核数。每个线程都运行一个 Asio io_context 的事件循环。这意味着你的请求回调可能在任意线程上执行。如果你在回调里操作共享资源必须加锁或者用原子变量否则并发一上来就崩。很多人编译完 restbed写了个单线程测试没问题就以为万事大吉。实际上线一压测各种数据竞争问题冒出来。这不是 restbed 的问题是你没用对线程模型。restbed 提供Service::start的workers参数可以控制线程数如果你确定自己的回调是线程安全的可以开到 CPU 核数的两倍。6.2 HTTPS 配置的正确姿势restbed 开启 HTTPS 需要在Settings里设置证书和私钥路径auto settings make_shared Settings ( ); settings-set_port( 443 ); settings-set_ssl_authentication( /path/certificate.pem, /path/private_key.pem ); settings-set_ssl_authentication( true );这个功能能不能用取决于你编译时是否成功链接了 OpenSSL。如果你发现自己编译的 restbed 里没有set_ssl_authentication方法回编译那一步重新检查 OpenSSL 相关配置。证书有个容易踩的坑restbed 要求 PEM 格式的证书。如果你用.cer或者.p12格式要先转换openssl x509 -in cert.cer -out cert.pem openssl pkcs12 -in key.p12 -out key.pem -nodes另外如果你只是本地测试可以用自签名证书。restbed 不会校验证书的 CA所以自签名证书可以正常用。6.3 已有编译好的库能不能开箱即用几个热门提及里有一个是“已经编译好的 pdfium 库开箱即用”这类想法很美好现实很骨感。预编译库的问题在于它不一定匹配你的编译器版本、运行库模式、架构类型。比如你用 GCC 13 编译项目但预编译库是 GCC 9 编的C ABI 有差异链接会报std::__cxx11相关错误。我的原则是能用包管理器装的就用包管理器vcpkg、conan不能的就自己编译。restbed 这种小项目自己编译成本很低没必要冒险用来历不明的预编译库。当然如果你非要用预编译版本至少确认对方提供的动态库和你的目标系统完全一致最好在容器环境里跑通了再上生产。6.4 编译优化选项的建议restbed 是网络密集型应用编译优化建议开-O2就够了-O3提升不明显但代码体积会变大。调试阶段用-O0 -g方便上 GDB。我自己有一个习惯线上版本用-O2 -DNDEBUG杀掉 assert 和调试输出减少不必要的开销。如果是嵌入式环境加上-ffunction-sections -fdata-sections和链接器的--gc-sections能去掉未使用的函数和数据减小最终二进制体积。我有一版交叉编译的 restbed用这个组合把存储空间从 3MB 压到了不到 1MB。7. 一些绕不开的细节从入门到“上了生产”编译这件事按部就班做一遍之后回头看其实步骤不复杂。但其中有一些“如果提前知道就好了”的细节值得再说一遍。第一条是构建目录隔离这是一个粉丝问我“为什么我改了 CMakeLists.txt 不生效”次数最多的原因我的回答永远是删掉 build 目录从零开始配置。这个习惯能让你的修改每次都干净生效。第二条是别开着 HTTPS 编译又不去设置证书拿着编好的库跑curl http://没问题一切 HTTPS 就报握手失败然后在排除问题上浪费半小时。这个不是知识问题是流程问题。第三条是链接顺序你以后如果要把 restbed 和其他第三方库混用链接顺序规则永远是把“依赖别人的库”放在前面被依赖的库放在后面。比如你的项目同时用了 restbed 和 opencv那指令里必须先写-lrestbed再写-lopencv_core如果你遇到了莫名奇妙的 undefined reference第一反应先检查链接顺序对不对。最后说一句我没有给 restbed 做任何封装或是二开就是原原本本编译、使用。它的代码质量在 C 社区里算中上文档缺失是个硬伤但代码风格清晰出问题值得深入读源码。如果你准备把它用在商业项目里我建议你把source/里的关键文件通读一遍尤其是service.cpp和resource.cpp读懂这两个文件你排错能力会上升一个档次。