尧图网站建设 
Hical vs Drogon vs Crow vs Oat vs cpp-httplib vs Cinatra上一篇横评我们从架构设计、功能完整度和开发体验角度对比了四个 C Web 框架。结论是各有适合的场景——但没回答一个关键问题到底差多少。本文用硬数据补上这个缺口相同硬件、相同容器、相同压测工具12 个场景全量对比包括别人不太敢贴的对自己不利的数据。目录1. 引言2. 测试环境与方法论3. 基础吞吐量对比4. 中间件链开销对比5. 高并发扩展性6. 资源效率7. 延迟分析8. 综合分析与选型建议9. 结论10. 复现指南1. 引言C Web 框架的选型讨论中最常听到三句话“Drogon 在 TechEmpower 上排名很高”“Crow 极简几行代码就能跑”“Oat 零依赖开箱即用”“cpp-httplib 零依赖单头文件几行就能搭 HTTP 服务”“Cinatra 是国产 C20 协程框架性能号称顶尖”这些都是事实但缺少在统一条件下的定量对比。框架官网的 benchmark 通常只跑 Hello World且各自用不同的硬件、不同的压测工具、不同的并发参数——数据之间几乎没有可比性。本文的定位补充 2026 年 C Web 框架横评Hical vs Drogon vs Crow vs Oat的定性对比用数据量化各框架的性能差异所有数据可复现——Docker 一键启动run_bench.sh跑一遍就能拿到结果先说一件必须交代的事本文数据采集于2026-09-28整份重跑过一轮。跟上一版逐格对了一遍基础场景里各家偏移在 -3%~10%高并发场景到了 8%~32%。这个漂移量说明上一轮整体不该用所以这版把 6 个框架 6 个场景全部重采了一遍上一版的数字本文不再引用。2. 测试环境与方法论2.1 硬件 容器环境项目规格宿主机Windows 10 Enterprise LTSC 2021Intel Core i7-11700K 3.60GHz8 核 16 线程32GB 内存虚拟机Oracle VirtualBox 7.1Ubuntu 24.04.3 LTS Server8 CPU / 16GB 内存 / 102GB SSDDockerDocker Engine 29.4.3VM 内原生运行非 Docker Desktop容器资源每容器限制4 CPU 1024MB 内存nofile65536网络Docker 内部 bridge 网桥wrk 独立容器通过服务名访问各框架虚拟化配置说明这台 VM 之前一直跑在宿主 Hyper-V / VBS 开启的状态下。VT-x 被 Hyper-V 独占后VirtualBox 只能降级到 WHPX/NEM 慢路径——每次 VM exit 要走用户态 API、内存变成嵌套两级地址翻译、中断还得经 hypervisor 转发。对一个每秒百万次 syscall、百万次中断的网络密集负载来说这个代价接近一个数量级。后来做了以下修正宿主机关闭 Hyper-V / VBSbcdedit /set hypervisorlaunchtype off后重启网卡从默认的 e1000Intel 82540EM全模拟网卡换成 virtio-net半虚拟化半虚拟化接口设为 KVM启用 PAE/NXSATA 控制器勾选「使用主机 I/O 缓存」虚拟硬盘标记为固态驱动器修完前后不是小修小补是 4 倍量级的差距。如果你也在 VirtualBox 里跑压测建议先按上面四条自查一遍再怀疑代码。2.2 框架版本 编译配置框架版本编译器优化级别异步模型备注Hicalmain ba28ad02.7.0 后GCC 14Ubuntu 24.04ReleaseBoost.Asio 协程仓库源码 Boost 静态链接Drogonv1.9.8GCCUbuntu 24.04 默认ReleaseTrantor 事件循环Crowv1.2.0GCCUbuntu 24.04 默认ReleaseStandalone Asio单头文件Oatv1.3.0GCCUbuntu 24.04 默认ReleaseSimple同步线程池零外部依赖cpp-httplibv0.18.3GCCUbuntu 24.04 默认Release同步线程池单头文件 nlohmann/jsonCinatrayalantinglibs v0.3.0GCCUbuntu 24.04 默认ReleaseC20 协程阿里 yalantinglibs 生态所有框架统一-DCMAKE_BUILD_TYPEReleaseCMake 的 Release 默认就是-O3 -DNDEBUG没有工程级覆盖统一 4 工作线程。Oat 用 Simple API同步模型每个连接占用一个线程上下文——这是 Oat 官方推荐的标准模式。2.3 压测工具与参数工具版本默认参数wrk4.1.04 threads, 100 connections, 30s durationPOST 请求使用挂载的 Lua 脚本post_echo.lua携带 JSON Body{name:Alice,age:30,email:aliceexample.com}避免 heredoc 管道问题。宿主机内核参数在容器启动前调过端口范围放宽到1024-65535、somaxconn和tcp_max_syn_backlog提到 65535、打开tcp_tw_reuse。这些是网络栈级别的参数容器创建时从宿主 net namespace 继承。2.4 数据采集流程每个场景用wrk -t4 -c并发 -d30s打一轮逐个框架串行执行同一时刻只有一个框架在承压原始 wrk 输出和 QPS 汇总都在benchmark/output/results.md里本文所有表格都从这份文件里取数补充数据内存 / 二进制 / 镜像大小 / 代码行数由collect_stats.sh采集结果在benchmark/output/stats.md2.5 测试场景总览#场景端点目标1Hello WorldGET /框架调度纯开销下限2JSON 序列化GET /api/statusJSON 构建 序列化性能3JSON EchoPOST /api/echo反序列化 序列化完整链路4路径参数GET /users/42参数路由匹配 JSON 响应5高并发 1,000GET /中等并发扩展性6高并发 10,000GET /极限并发观察错误率和 OOM中间件场景不进横评。之前测过 0/3/10 层协程洋葱链和一整套同步过滤链但比到后面发现问题在于不可比六家里只有 Hical 和 Drogon 有真正等价的运行时协程中间件其余四家Crow / Oat / cpp-httplib / Cinatra要么是编译期模板、要么根本没有运行时中间件机制只能用std::function手搓调用链去模拟。拿模拟出来的数字和真机制并排比看着热闹其实测的不是同一个东西。所以中间件从这张表里撤掉了。Hical 的 bench 服务器里仍留着/middleware/0和/middleware/10两个端点——那是给我自己跟踪中间件开销用的见仓库里 VM 压测指南的基线表不进框架对比其他五家的服务器里也没有对应实现。3. 基础吞吐量对比3.1 Hello World — 纯框架开销六个框架返回相同的 13 字节固定字符串不涉及 JSON 或数据库。Hicalserver.router().get(/,[](constHttpRequest)-HttpResponse{returnHttpResponse::ok(Hello, World!);});Drogonapp().registerHandler(/,[](constHttpRequestPtr,std::functionvoid(constHttpResponsePtr)callback){autorespHttpResponse::newHttpResponse();resp-setBody(Hello, World!);callback(resp);},{Get});CrowCROW_ROUTE(app,/)([](){returncrow::response(200,Hello, World!);});OatENDPOINT(GET,/,hello){returncreateResponse(Status::CODE_200,Hello, World!);}cpp-httplibsvr.Get(/,[](consthttplib::Request,httplib::Responseres){res.set_content(Hello, World!,text/plain);});Cinatraserver.set_http_handlerGET(/,[](coro_http_requestreq,coro_http_responseres){res.set_status_and_content(status_type::ok,Hello, World!);});框架QPSAvg 延迟Max 延迟StdevCinatra605,123149.52us12.22ms183.62usHical562,810174.11us19.66ms315.23usDrogon515,760195.54us16.08ms265.15usCrow311,188327.38us19.55ms255.88usOat226,0902.92ms100.31ms7.22mscpp-httplib85,41027.56ms317.88ms36.14ms分析Cinatra605K第一Hical563K第二两家差 7.5%Drogon516K第三跟 Hical 差 9.1%。这仨加起来跨了 17% 的区间但量级还是一档。再往下 Crow311K和 Oat226K各差一档cpp-httplib 的 85K 是最后一名。这里必须说清楚一个口径问题六个框架返回的都是 13 字节的Hello, World!实际在网络上传的字节数却差得很多。用Transfer/sec ÷ Requests/sec反推每请求的 wire 字节wrk 的 MB 是 1024 进制框架每请求字节其中响应头Transfer/secHical175 B~162 B93.93MBDrogon151 B~138 B74.27MBCrow134 B~121 B39.77MBcpp-httplib110 B~97 B8.95MBCinatra106 B~93 B61.17MBOat97 B~84 B20.91MB这个算法可以拿 wrk 日志里的GB read交叉验证Hical 那行写着16940788 requests in 30.10s, 2.76GB read2.76 GiB ÷ 16940788 ≈ 174.9 B跟表里的 175 B 对得上。Hical 每请求比 Cinatra 多推约 69 字节整轮多发 65% 的字节。差异主要在响应头的自动附带策略上——Hical 在连接建立时预构建了Server/Connection/Date三个通用头Cinatra 默认不发Date。所以「Cinatra 比 Hical 快 7.5%」这句话得打个折扣论单位带宽的效率Hical 反而更高93.93MB/s vs 61.17MB/s。反过来说如果你的瓶颈是出网带宽而不是 QPS这 69 字节就是实打实的成本。QPS 是单维指标读表的时候心里得有这根弦。3.2 JSON 序列化各框架构建相同结构的 JSON 对象{status:running,framework:xxx}并序列化为响应体。JSON 库差异框架JSON 库序列化方式HicalBoost.JSONjson::object→json::valueDrogonjsoncppJson::Value→ 内部序列化Crowcrow::jsoncrow::json::wvalueOat内置 ObjectMapperDTO → 自动序列化cpp-httplibnlohmann/jsonjson→dump()Cinatraiguana (struct_json)iguana::to_json()框架QPSAvg 延迟Max 延迟StdevQPS 下降Cinatra567,065166.70us10.01ms214.82us-6.3%Hical534,547183.22us10.30ms213.57us-5.0%Drogon361,592285.04us12.26ms244.45us-29.9%Crow280,068362.79us9.32ms222.95us-10.0%Oat190,9153.27ms83.43ms7.46ms-15.6%cpp-httplib79,62529.93ms550.67ms40.90ms-6.8%QPS 下降列表示相对 Hello World 场景的衰减反映 JSON 序列化引入的额外开销。分析这个场景基本是 JSON 库的选型考试。Hical 的 Boost.JSON-5.0%、Cinatra 的 iguana-6.3%、cpp-httplib 的 nlohmann-6.8%三个几乎没付出代价Drogon 的 jsoncpp 掉了 29.9%。差距不是框架的锅是库的锅——换个 JSON 库Drogon 这个数字能立刻好看一截。3.3 JSON Echo反序列化 序列化接收 POST Body解析后原样返回。框架QPSAvg 延迟Max 延迟StdevQPS 下降Cinatra533,886178.81us9.07ms187.74us-11.8%Hical439,399234.31us13.15ms236.15us-21.9%Drogon292,815349.84us10.56ms239.38us-43.2%Crow236,927428.62us9.31ms211.02us-23.9%Oat146,8883.65ms152.02ms7.54ms-35.0%cpp-httplib72,80232.51ms541.59ms44.04ms-14.8%Drogon 在 JSON Echo 场景相对 Hello World 下降 43.2%比纯序列化场景-29.9%又多掉 13 个点——jsoncpp 的反序列化比序列化更贵。Hical 掉 21.9%Cinatra 掉 11.8%。3.4 路径参数GET /users/42路由系统从 URL 提取id参数并构建 JSON 响应。路由匹配机制差异框架静态路由参数路由匹配复杂度Hical哈希表 O(1)按方法分组线性扫描O(1) O(N/M)Drogon哈希表正则匹配O(1) O(regex)Crow前缀树 TrieTrie 节点匹配O(path_len)OatPathPattern模式匹配O(pattern_count)cpp-httplib正则匹配正则捕获组O(regex)CinatraRadix Tree:param_name模式O(path_len)框架QPSAvg 延迟Max 延迟StdevCinatra538,086181.31us11.01ms221.29usHical516,732192.86us10.45ms208.88usDrogon335,876303.41us9.27ms200.81usCrow271,959370.34us8.21ms164.05usOat189,8582.79ms93.68ms6.24mscpp-httplib80,82028.99ms238.31ms38.21ms参数路由这档 Cinatra538K和 Hical517K都在 50 万上下正则匹配那套代价没怎么体现在 Hical 身上只掉了 8.2%。Drogon336K掉到第二梯队正则匹配参数路由的代价在这里体现得比较直接。3.5 基础场景汇总场景CinatraHicalDrogonCrowOatcpp-httplibHello World605,123562,810515,760311,188226,09085,410JSON 序列化567,065534,547361,592280,068190,91579,625JSON Echo533,886439,399292,815236,927146,88872,802路径参数538,086516,732335,876271,959189,85880,820四个基础场景的名次一模一样Cinatra 全第一Hical 全第二Drogon 全第三后面 Crow、Oat、cpp-httplib 依次排。Cinatra 对 Hical 的领先在 4.1%~21.5% 之间浮动路径参数最小、JSON Echo 最大而 Drogon 一旦进 JSON 就掉到 -35%~-43%——它不是被 Cinatra 甩开的是被自己的 JSON 库甩开的。4. 高并发扩展性固定 Hello World 端点逐步提升并发连接数100 → 1000 → 10000观察 QPS 变化和错误率。4.1 QPS 随并发数变化并发连接CinatraDrogonHicalCrowOatcpp-httplib100605,123515,760562,810311,188226,09085,4101,000479,291464,828447,487265,762177,77184,33210,000197,470197,957181,924185,720123,48074,864相对 c100 的衰减并发连接HicalDrogonCinatraCrowOatcpp-httplib1,000-20.5%-9.9%-20.8%-14.6%-21.4%-1.3%10,000-67.7%-61.6%-67.4%-40.3%-45.4%-12.3%4.2 延迟随并发数变化并发连接CinatraDrogonHicalCrowOatcpp-httplib100149.52us195.54us174.11us327.38us2.92ms27.56ms1,0002.05ms2.12ms2.24ms3.75ms7.86ms276.80ms10,00035.09ms29.49ms31.56ms53.33ms54.73ms66.31ms分析从 100 并发到 1000 并发Hical-20.5%和 Cinatra-20.8%一起掉两成Crow 掉 14.6%Drogon 只掉 9.9%。到 10000 并发Drogon198K和 Cinatra197K咬在一起Crow186K排第三Hical182K第四——四个异步框架里它排最后。这组和上一版是反过来的。上一版 Hical 在 1000 并发排第二、10000 并发排第三这一版两个档位各往后挪了一位。我的看法是上一版的整体测量就有偏差见开头那段但具体偏在哪、为什么偏我没做 profiling不编原因。顺带记一笔我自己没想明白的地方用QPS × 平均延迟反推在途请求数——Hical 98.0、Drogon 100.9、Crow 101.9、Cinatra 90.5四家整整齐齐卡在 wrk 的 100 并发上这个很合理。但 Oat 推出 660、cpp-httplib 推出 2354两个数都超过了 100。按常理推不出这个结果我没去查先如实标在这里。4.3 错误率 Socket Errors并发 10KHicalDrogonCrowCinatraOatcpp-httplibSocket errors无无无timeout 2,288timeout 7,899read 161,186 timeout 55说明上一版 10K 测试里六个框架全都报connect 8983错误——容器有效 fd 只有一千出头所谓的一万并发根本没压进去测的其实是千级并发。这一版把nofile提到 65536、宿主内核参数也调了连接是真建立起来了Hical、Drogon、Crow 三家零错误Cinatra 有 2288 个 timeoutOat 的 7899 个 timeout 是同步线程池在万级连接下的典型表现。cpp-httplib 出现了 16 万个读错误read 161186是六家里唯一报读方向错误的。同一场景它的 QPS 也掉到 74,864六家最低。5. 资源效率5.1 内存占用框架空载内存满载内存Hical129.6MiB129.6MiBDrogon97.79MiB92.05MiBCinatra92.46MiB86.87MiBCrow65.02MiB64.91MiBOat18.8MiB16.36MiBcpp-httplib1.891MiB1.895MiB数据来自docker stats --no-stream为容器级 RSS。满载数据在 wrk 同时压测所有框架时采样。Hical 依旧是内存占用最高的129.6MiB比第二的 Drogon 高 33%——这是 PMR 三层内存池预分配换来的。Pool 预分配之后运行时几乎不再向系统要内存空载满载一个数代价就是启动就占住这一坨。cpp-httplib 的 1.9MiB 是另一个极端因为它压根没有连接池和缓冲区池。表里 Drogon、Cinatra、Oat 的满载数字比空载还低一点这是 RSS 采样时刻的正常波动不是真的把内存还回去了。Hical 和 cpp-httplib 空载满载完全一致倒是很干净。5.2 二进制 Docker 镜像大小框架二进制大小Docker 镜像备注Hical3.0M122MB本地源码 Boost 静态链接Drogon1.9M122MBTrantor jsoncpp 动态链接Oat767K118MB零外部依赖全静态链接Cinatra508K118MBHeader-onlyyalantinglibs 生态Crow401K118MBHeader-only极少运行时依赖cpp-httplib400K118MBHeader-only零外部依赖Hical 的 3.0M 是六家里最大的因为它把 Boost.Asio / Boost.JSON / Boost.System 全都静态链进去了。Crow、cpp-httplib、Cinatra 框架本身是 header-only外部依赖动态链接二进制里只有用户代码和少量模板实例化。Docker 镜像的差异主要来自基础镜像ubuntu:24.04 约 118MB各框架额外增量只有 0~4MB——所以镜像大小这个指标基本没有区分度。5.3 代码行数框架文件行数Crowcrow/main.cpp56cpp-httplibcpphttplib/main.cpp65Drogondrogon/main.cpp67Cinatracinatra/main.cpp84Hicalhical/main.cpp95Oatoatpp/main.cpp112wc -l含注释和空行按横评用的端点集统计。Hical 那 95 行里有 36 行是/middleware/0和/middleware/10两个端点只给 Hical 自己跟踪中间件开销用其他五家没有对应实现扣掉之后是 59 行跟 Crow 的 56 行基本持平。剩下的差异基本只是 API 风格——Crow 的CROW_ROUTE一行一个端点最省Oat 的 DTO Controller 定义最啰嗦。这个数字看看就好跟性能没关系。6. 延迟分析6.1 全场景延迟汇总Avg / Max场景CinatraHicalDrogonCrowOatcpp-httplibHello World149.52us / 12.22ms174.11us / 19.66ms195.54us / 16.08ms327.38us / 19.55ms2.92ms / 100.31ms27.56ms / 317.88msJSON 序列化166.70us / 10.01ms183.22us / 10.30ms285.04us / 12.26ms362.79us / 9.32ms3.27ms / 83.43ms29.93ms / 550.67msJSON Echo178.81us / 9.07ms234.31us / 13.15ms349.84us / 10.56ms428.62us / 9.31ms3.65ms / 152.02ms32.51ms / 541.59ms路径参数181.31us / 11.01ms192.86us / 10.45ms303.41us / 9.27ms370.34us / 8.21ms2.79ms / 93.68ms28.99ms / 238.31ms高并发 1K2.05ms / 238.93ms2.24ms / 152.87ms2.12ms / 166.47ms3.75ms / 16.43ms7.86ms / 1.67s276.80ms / 1.93s高并发 10K35.09ms / 2.00s31.56ms / 83.39ms29.49ms / 94.41ms53.33ms / 76.53ms54.73ms / 2.00s66.31ms / 1.88s6.2 延迟稳定性Stdev 是比平均延迟更重要的指标——尾延迟才是生产环境里导致用户体验劣化的真正杀手。场景CinatraHicalDrogonCrowOatcpp-httplibHello World183.62us315.23us265.15us255.88us7.22ms36.14ms高并发 1K3.25ms1.73ms1.26ms436.99us16.54ms370.58ms高并发 10K21.43ms10.14ms10.00ms3.04ms95.18ms241.97ms加粗为该项最低。基础场景100c下四家异步框架的 Stdev 都挤在 180~320us 这一档Cinatra 183.62us 最低Crow 和 Drogon 差不太多255.88us / 265.15usHical 的 315.23us 稍高一点。Crow 的稳是全场最扎实的——1K 时 Stdev 436.99us、10K 时 3.04ms两个档位都是最低。它 QPS 排在中游但延迟这条线上没什么短板。Hical 这一版的表现跟上一版正好翻了个面。上一版它在 10K 下的 Max 是 445.50ms六家里最差这一版是 83.39ms只比 Crow 的 76.53ms 高一点Stdev 10.14ms 同样只输给 Crow。1000 并发时 Max 152.87ms也优于 Drogon 的 166.47ms 和 Cinatra 的 238.93ms。Cinatra 反过来。10K 的平均延迟 35.09ms 看着还行Max 直接 2.00sStdev 21.43ms 是四家异步框架里最高的再加上那 2288 个 timeout。平均值这个指标把它的问题盖得严严实实。选型的时候如果只扫 Avg 这一列Cinatra 的 35ms 显得很稳妥而上一版 Hical 那个 445ms 又显得很不稳妥——两次都看走眼了。7. 综合分析与选型建议7.1 维度评分维度CinatraHicalDrogonCrowOatcpp-httplib基础 QPS★★★★★★★★★☆★★★★☆★★★☆☆★★☆☆☆★☆☆☆☆高并发扩展性★★★★☆★★★☆☆★★★★★★★★★☆★★☆☆☆★☆☆☆☆延迟稳定性★★☆☆☆★★★★☆★★★★☆★★★★★★☆☆☆☆★☆☆☆☆内存效率★★★☆☆★★☆☆☆★★★☆☆★★★★☆★★★★★★★★★★中间件灵活度★★☆☆☆★★★★★★★★★★★★☆☆☆★★☆☆☆★☆☆☆☆代码简洁度★★★☆☆★★★☆☆★★★★☆★★★★★★★☆☆☆★★★★★生态成熟度★★★☆☆★★☆☆☆★★★★★★★★☆☆★★★☆☆★★★★☆中间件灵活度和生态成熟度基于架构分析和社区现状评估非量化数据。所有维度按六框架内部横向比较不是绝对水平。7.2 各框架适用场景选 Cinatra如果纯吞吐是首要指标本文 6 个场景里它拿了 5 个第一想用 C20 协程 国产生态yalantinglibs需要 iguana 反射驱动的自动 JSON 序列化能接受高并发下明显的长尾10K 时 Max 2 秒 2288 个 timeout并且不介意中间件是全局 AOP 模型选 Drogon如果高并发是核心场景10K 连接下它是第一198K QPS且零错误需要久经考验的生产级框架和完整生态ORM、HTTP 客户端、WebSocket能接受 jsoncpp 在 JSON 密集场景的开销或打算换掉它选 Hical如果需要路由级中间件精确控制六家里只有 Hical 和 Drogon 支持本文未压测中间件此条为架构能力对 JSON 序列化性能敏感Boost.JSON 四个基础场景都在第二紧跟 iguana看重万级连接下的延迟波动和长尾10K 时 Max 83.39ms、Stdev 10.14ms两项都只输给 Crow选 Crow如果原型验证、内部工具、教学用途追求最小依赖和最快上手对延迟稳定性要求高于吞吐量1K/10K 的 Stdev 都是全场最低选 Oat如果零外部依赖是硬性需求喜欢 DTO Controller 的强类型 API 风格高并发不是核心需求选 cpp-httplib如果极致简洁不想引入任何构建依赖原型验证、脚本式 HTTP 服务、嵌入式场景对性能要求不高开发效率优先记住它 10K 并发下会报 16 万个 read 错误7.3 性能格局总结六框架性能依旧是“四档”格局只是每一档的位置动了动第一梯队Cinatra53万~61万和 Hical44万~56万。Drogon 在纯文本场景与它们同档52万但一进 JSON 就掉到 29万~36万卡在两档之间第二梯队24万~31万 QPSCrow 独占第三梯队12万~23万 QPSOat同步线程池模型的天花板第四档7万~8.5万 QPScpp-httplib但第一梯队内部不是一个平面。Cinatra 赢在纯吞吐和高并发 100010K 要看 Drogon要论万级连接下的长尾是 Crow 和 Hical 的地盘。选型的时候先想清楚自己最怕什么——怕吞吐上不去还是怕偶发长尾。8. 结论几点诚实的总结Cinatra 这轮还是赢得很干净。6 个场景里 5 个第一唯一输掉的是 10K 并发197K vs Drogon 198K差 0.2%。Hical 在 6 个场景里全部落后 Cinatra幅度 4.1%~21.5%。Cinatra 赢在基础吞吐但高并发下压不住尾巴。10K 时 Max 2.00s、Stdev 21.43ms、2288 个 timeout这三项在四家异步框架里都是最差的。平均延迟漂亮、尾巴失控这类问题在每天跑几亿请求的场景里一定会暴露出来。Hical 这轮的表现在两张表上相反。QPS 侧两个并发档位都比上一版各退了一名延迟侧它的长尾反而是六家里第二好的10K 时 Max 83.39ms上一版这个数是 445.50ms。同样是重测之后结论变了这次我没有 profiling 数据不做归因两组数都摆在这儿。平均值和 Max 讲的是两个故事。四家异步框架的 Avg 延迟在 29.49ms~53.33ms 之间最多差 1.8 倍Max 从 Crow 的 76.53ms 到 Cinatra 的 2.00s差了 26 倍。只看平均值那一列看不出这中间到底发生了什么。JSON 库选型比框架选型影响更大。Drogon 换掉 jsoncppJSON 场景的数字能立刻好一截而这是它四个基础场景里唯一明显掉队的地方。微基准不等于生产性能。Hello World 和实际业务之间隔着数据库查询、鉴权、日志、复杂对象序列化等大量 I/O框架的裸 QPS在生产里会被摊薄。可复现比可信更重要。本文的全部测试环境和脚本都已开源不同意结论docker compose up自己跑一遍。9. 复现指南所有测试代码、Docker 配置和压测脚本均已公开详见仓库benchmark/README.md包含完整的构建、启动、压测、采集和清理流程。gitclone https://github.com/hical61/hical.gitcdhical/benchmark# 后续步骤参照 benchmark/README.md跑之前建议先自查虚拟化环境见 2.1。这台 VM 上开着 Hyper-V 和不开着同一份二进制的成绩能差 4 倍——在那之前你测的是 hypervisor不是框架。利益声明本文作者是 Hical 框架的开发者。为减少偏见所有测试代码、Docker 配置和压测脚本均已公开欢迎复现验证。对 Hical 不利的数据同样如实展示6 个场景全部落后 Cinatra、10K 并发在四家异步框架里垫底、内存占用六家最高。 C++ Web 框架性能实测（Benchmark）
Hical vs Drogon vs Crow vs Oat vs cpp-httplib vs Cinatra上一篇横评我们从架构设计、功能完整度和开发体验角度对比了四个 C Web 框架。结论是各有适合的场景——但没回答一个关键问题到底差多少。本文用硬数据补上这个缺口相同硬件、相同容器、相同压测工具12 个场景全量对比包括别人不太敢贴的对自己不利的数据。目录1. 引言2. 测试环境与方法论3. 基础吞吐量对比4. 中间件链开销对比5. 高并发扩展性6. 资源效率7. 延迟分析8. 综合分析与选型建议9. 结论10. 复现指南1. 引言C Web 框架的选型讨论中最常听到三句话“Drogon 在 TechEmpower 上排名很高”“Crow 极简几行代码就能跑”“Oat 零依赖开箱即用”“cpp-httplib 零依赖单头文件几行就能搭 HTTP 服务”“Cinatra 是国产 C20 协程框架性能号称顶尖”这些都是事实但缺少在统一条件下的定量对比。框架官网的 benchmark 通常只跑 Hello World且各自用不同的硬件、不同的压测工具、不同的并发参数——数据之间几乎没有可比性。本文的定位补充 2026 年 C Web 框架横评Hical vs Drogon vs Crow vs Oat的定性对比用数据量化各框架的性能差异所有数据可复现——Docker 一键启动run_bench.sh跑一遍就能拿到结果先说一件必须交代的事本文数据采集于2026-09-28整份重跑过一轮。跟上一版逐格对了一遍基础场景里各家偏移在 -3%~10%高并发场景到了 8%~32%。这个漂移量说明上一轮整体不该用所以这版把 6 个框架 6 个场景全部重采了一遍上一版的数字本文不再引用。2. 测试环境与方法论2.1 硬件 容器环境项目规格宿主机Windows 10 Enterprise LTSC 2021Intel Core i7-11700K 3.60GHz8 核 16 线程32GB 内存虚拟机Oracle VirtualBox 7.1Ubuntu 24.04.3 LTS Server8 CPU / 16GB 内存 / 102GB SSDDockerDocker Engine 29.4.3VM 内原生运行非 Docker Desktop容器资源每容器限制4 CPU 1024MB 内存nofile65536网络Docker 内部 bridge 网桥wrk 独立容器通过服务名访问各框架虚拟化配置说明这台 VM 之前一直跑在宿主 Hyper-V / VBS 开启的状态下。VT-x 被 Hyper-V 独占后VirtualBox 只能降级到 WHPX/NEM 慢路径——每次 VM exit 要走用户态 API、内存变成嵌套两级地址翻译、中断还得经 hypervisor 转发。对一个每秒百万次 syscall、百万次中断的网络密集负载来说这个代价接近一个数量级。后来做了以下修正宿主机关闭 Hyper-V / VBSbcdedit /set hypervisorlaunchtype off后重启网卡从默认的 e1000Intel 82540EM全模拟网卡换成 virtio-net半虚拟化半虚拟化接口设为 KVM启用 PAE/NXSATA 控制器勾选「使用主机 I/O 缓存」虚拟硬盘标记为固态驱动器修完前后不是小修小补是 4 倍量级的差距。如果你也在 VirtualBox 里跑压测建议先按上面四条自查一遍再怀疑代码。2.2 框架版本 编译配置框架版本编译器优化级别异步模型备注Hicalmain ba28ad02.7.0 后GCC 14Ubuntu 24.04ReleaseBoost.Asio 协程仓库源码 Boost 静态链接Drogonv1.9.8GCCUbuntu 24.04 默认ReleaseTrantor 事件循环Crowv1.2.0GCCUbuntu 24.04 默认ReleaseStandalone Asio单头文件Oatv1.3.0GCCUbuntu 24.04 默认ReleaseSimple同步线程池零外部依赖cpp-httplibv0.18.3GCCUbuntu 24.04 默认Release同步线程池单头文件 nlohmann/jsonCinatrayalantinglibs v0.3.0GCCUbuntu 24.04 默认ReleaseC20 协程阿里 yalantinglibs 生态所有框架统一-DCMAKE_BUILD_TYPEReleaseCMake 的 Release 默认就是-O3 -DNDEBUG没有工程级覆盖统一 4 工作线程。Oat 用 Simple API同步模型每个连接占用一个线程上下文——这是 Oat 官方推荐的标准模式。2.3 压测工具与参数工具版本默认参数wrk4.1.04 threads, 100 connections, 30s durationPOST 请求使用挂载的 Lua 脚本post_echo.lua携带 JSON Body{name:Alice,age:30,email:aliceexample.com}避免 heredoc 管道问题。宿主机内核参数在容器启动前调过端口范围放宽到1024-65535、somaxconn和tcp_max_syn_backlog提到 65535、打开tcp_tw_reuse。这些是网络栈级别的参数容器创建时从宿主 net namespace 继承。2.4 数据采集流程每个场景用wrk -t4 -c并发 -d30s打一轮逐个框架串行执行同一时刻只有一个框架在承压原始 wrk 输出和 QPS 汇总都在benchmark/output/results.md里本文所有表格都从这份文件里取数补充数据内存 / 二进制 / 镜像大小 / 代码行数由collect_stats.sh采集结果在benchmark/output/stats.md2.5 测试场景总览#场景端点目标1Hello WorldGET /框架调度纯开销下限2JSON 序列化GET /api/statusJSON 构建 序列化性能3JSON EchoPOST /api/echo反序列化 序列化完整链路4路径参数GET /users/42参数路由匹配 JSON 响应5高并发 1,000GET /中等并发扩展性6高并发 10,000GET /极限并发观察错误率和 OOM中间件场景不进横评。之前测过 0/3/10 层协程洋葱链和一整套同步过滤链但比到后面发现问题在于不可比六家里只有 Hical 和 Drogon 有真正等价的运行时协程中间件其余四家Crow / Oat / cpp-httplib / Cinatra要么是编译期模板、要么根本没有运行时中间件机制只能用std::function手搓调用链去模拟。拿模拟出来的数字和真机制并排比看着热闹其实测的不是同一个东西。所以中间件从这张表里撤掉了。Hical 的 bench 服务器里仍留着/middleware/0和/middleware/10两个端点——那是给我自己跟踪中间件开销用的见仓库里 VM 压测指南的基线表不进框架对比其他五家的服务器里也没有对应实现。3. 基础吞吐量对比3.1 Hello World — 纯框架开销六个框架返回相同的 13 字节固定字符串不涉及 JSON 或数据库。Hicalserver.router().get(/,[](constHttpRequest)-HttpResponse{returnHttpResponse::ok(Hello, World!);});Drogonapp().registerHandler(/,[](constHttpRequestPtr,std::functionvoid(constHttpResponsePtr)callback){autorespHttpResponse::newHttpResponse();resp-setBody(Hello, World!);callback(resp);},{Get});CrowCROW_ROUTE(app,/)([](){returncrow::response(200,Hello, World!);});OatENDPOINT(GET,/,hello){returncreateResponse(Status::CODE_200,Hello, World!);}cpp-httplibsvr.Get(/,[](consthttplib::Request,httplib::Responseres){res.set_content(Hello, World!,text/plain);});Cinatraserver.set_http_handlerGET(/,[](coro_http_requestreq,coro_http_responseres){res.set_status_and_content(status_type::ok,Hello, World!);});框架QPSAvg 延迟Max 延迟StdevCinatra605,123149.52us12.22ms183.62usHical562,810174.11us19.66ms315.23usDrogon515,760195.54us16.08ms265.15usCrow311,188327.38us19.55ms255.88usOat226,0902.92ms100.31ms7.22mscpp-httplib85,41027.56ms317.88ms36.14ms分析Cinatra605K第一Hical563K第二两家差 7.5%Drogon516K第三跟 Hical 差 9.1%。这仨加起来跨了 17% 的区间但量级还是一档。再往下 Crow311K和 Oat226K各差一档cpp-httplib 的 85K 是最后一名。这里必须说清楚一个口径问题六个框架返回的都是 13 字节的Hello, World!实际在网络上传的字节数却差得很多。用Transfer/sec ÷ Requests/sec反推每请求的 wire 字节wrk 的 MB 是 1024 进制框架每请求字节其中响应头Transfer/secHical175 B~162 B93.93MBDrogon151 B~138 B74.27MBCrow134 B~121 B39.77MBcpp-httplib110 B~97 B8.95MBCinatra106 B~93 B61.17MBOat97 B~84 B20.91MB这个算法可以拿 wrk 日志里的GB read交叉验证Hical 那行写着16940788 requests in 30.10s, 2.76GB read2.76 GiB ÷ 16940788 ≈ 174.9 B跟表里的 175 B 对得上。Hical 每请求比 Cinatra 多推约 69 字节整轮多发 65% 的字节。差异主要在响应头的自动附带策略上——Hical 在连接建立时预构建了Server/Connection/Date三个通用头Cinatra 默认不发Date。所以「Cinatra 比 Hical 快 7.5%」这句话得打个折扣论单位带宽的效率Hical 反而更高93.93MB/s vs 61.17MB/s。反过来说如果你的瓶颈是出网带宽而不是 QPS这 69 字节就是实打实的成本。QPS 是单维指标读表的时候心里得有这根弦。3.2 JSON 序列化各框架构建相同结构的 JSON 对象{status:running,framework:xxx}并序列化为响应体。JSON 库差异框架JSON 库序列化方式HicalBoost.JSONjson::object→json::valueDrogonjsoncppJson::Value→ 内部序列化Crowcrow::jsoncrow::json::wvalueOat内置 ObjectMapperDTO → 自动序列化cpp-httplibnlohmann/jsonjson→dump()Cinatraiguana (struct_json)iguana::to_json()框架QPSAvg 延迟Max 延迟StdevQPS 下降Cinatra567,065166.70us10.01ms214.82us-6.3%Hical534,547183.22us10.30ms213.57us-5.0%Drogon361,592285.04us12.26ms244.45us-29.9%Crow280,068362.79us9.32ms222.95us-10.0%Oat190,9153.27ms83.43ms7.46ms-15.6%cpp-httplib79,62529.93ms550.67ms40.90ms-6.8%QPS 下降列表示相对 Hello World 场景的衰减反映 JSON 序列化引入的额外开销。分析这个场景基本是 JSON 库的选型考试。Hical 的 Boost.JSON-5.0%、Cinatra 的 iguana-6.3%、cpp-httplib 的 nlohmann-6.8%三个几乎没付出代价Drogon 的 jsoncpp 掉了 29.9%。差距不是框架的锅是库的锅——换个 JSON 库Drogon 这个数字能立刻好看一截。3.3 JSON Echo反序列化 序列化接收 POST Body解析后原样返回。框架QPSAvg 延迟Max 延迟StdevQPS 下降Cinatra533,886178.81us9.07ms187.74us-11.8%Hical439,399234.31us13.15ms236.15us-21.9%Drogon292,815349.84us10.56ms239.38us-43.2%Crow236,927428.62us9.31ms211.02us-23.9%Oat146,8883.65ms152.02ms7.54ms-35.0%cpp-httplib72,80232.51ms541.59ms44.04ms-14.8%Drogon 在 JSON Echo 场景相对 Hello World 下降 43.2%比纯序列化场景-29.9%又多掉 13 个点——jsoncpp 的反序列化比序列化更贵。Hical 掉 21.9%Cinatra 掉 11.8%。3.4 路径参数GET /users/42路由系统从 URL 提取id参数并构建 JSON 响应。路由匹配机制差异框架静态路由参数路由匹配复杂度Hical哈希表 O(1)按方法分组线性扫描O(1) O(N/M)Drogon哈希表正则匹配O(1) O(regex)Crow前缀树 TrieTrie 节点匹配O(path_len)OatPathPattern模式匹配O(pattern_count)cpp-httplib正则匹配正则捕获组O(regex)CinatraRadix Tree:param_name模式O(path_len)框架QPSAvg 延迟Max 延迟StdevCinatra538,086181.31us11.01ms221.29usHical516,732192.86us10.45ms208.88usDrogon335,876303.41us9.27ms200.81usCrow271,959370.34us8.21ms164.05usOat189,8582.79ms93.68ms6.24mscpp-httplib80,82028.99ms238.31ms38.21ms参数路由这档 Cinatra538K和 Hical517K都在 50 万上下正则匹配那套代价没怎么体现在 Hical 身上只掉了 8.2%。Drogon336K掉到第二梯队正则匹配参数路由的代价在这里体现得比较直接。3.5 基础场景汇总场景CinatraHicalDrogonCrowOatcpp-httplibHello World605,123562,810515,760311,188226,09085,410JSON 序列化567,065534,547361,592280,068190,91579,625JSON Echo533,886439,399292,815236,927146,88872,802路径参数538,086516,732335,876271,959189,85880,820四个基础场景的名次一模一样Cinatra 全第一Hical 全第二Drogon 全第三后面 Crow、Oat、cpp-httplib 依次排。Cinatra 对 Hical 的领先在 4.1%~21.5% 之间浮动路径参数最小、JSON Echo 最大而 Drogon 一旦进 JSON 就掉到 -35%~-43%——它不是被 Cinatra 甩开的是被自己的 JSON 库甩开的。4. 高并发扩展性固定 Hello World 端点逐步提升并发连接数100 → 1000 → 10000观察 QPS 变化和错误率。4.1 QPS 随并发数变化并发连接CinatraDrogonHicalCrowOatcpp-httplib100605,123515,760562,810311,188226,09085,4101,000479,291464,828447,487265,762177,77184,33210,000197,470197,957181,924185,720123,48074,864相对 c100 的衰减并发连接HicalDrogonCinatraCrowOatcpp-httplib1,000-20.5%-9.9%-20.8%-14.6%-21.4%-1.3%10,000-67.7%-61.6%-67.4%-40.3%-45.4%-12.3%4.2 延迟随并发数变化并发连接CinatraDrogonHicalCrowOatcpp-httplib100149.52us195.54us174.11us327.38us2.92ms27.56ms1,0002.05ms2.12ms2.24ms3.75ms7.86ms276.80ms10,00035.09ms29.49ms31.56ms53.33ms54.73ms66.31ms分析从 100 并发到 1000 并发Hical-20.5%和 Cinatra-20.8%一起掉两成Crow 掉 14.6%Drogon 只掉 9.9%。到 10000 并发Drogon198K和 Cinatra197K咬在一起Crow186K排第三Hical182K第四——四个异步框架里它排最后。这组和上一版是反过来的。上一版 Hical 在 1000 并发排第二、10000 并发排第三这一版两个档位各往后挪了一位。我的看法是上一版的整体测量就有偏差见开头那段但具体偏在哪、为什么偏我没做 profiling不编原因。顺带记一笔我自己没想明白的地方用QPS × 平均延迟反推在途请求数——Hical 98.0、Drogon 100.9、Crow 101.9、Cinatra 90.5四家整整齐齐卡在 wrk 的 100 并发上这个很合理。但 Oat 推出 660、cpp-httplib 推出 2354两个数都超过了 100。按常理推不出这个结果我没去查先如实标在这里。4.3 错误率 Socket Errors并发 10KHicalDrogonCrowCinatraOatcpp-httplibSocket errors无无无timeout 2,288timeout 7,899read 161,186 timeout 55说明上一版 10K 测试里六个框架全都报connect 8983错误——容器有效 fd 只有一千出头所谓的一万并发根本没压进去测的其实是千级并发。这一版把nofile提到 65536、宿主内核参数也调了连接是真建立起来了Hical、Drogon、Crow 三家零错误Cinatra 有 2288 个 timeoutOat 的 7899 个 timeout 是同步线程池在万级连接下的典型表现。cpp-httplib 出现了 16 万个读错误read 161186是六家里唯一报读方向错误的。同一场景它的 QPS 也掉到 74,864六家最低。5. 资源效率5.1 内存占用框架空载内存满载内存Hical129.6MiB129.6MiBDrogon97.79MiB92.05MiBCinatra92.46MiB86.87MiBCrow65.02MiB64.91MiBOat18.8MiB16.36MiBcpp-httplib1.891MiB1.895MiB数据来自docker stats --no-stream为容器级 RSS。满载数据在 wrk 同时压测所有框架时采样。Hical 依旧是内存占用最高的129.6MiB比第二的 Drogon 高 33%——这是 PMR 三层内存池预分配换来的。Pool 预分配之后运行时几乎不再向系统要内存空载满载一个数代价就是启动就占住这一坨。cpp-httplib 的 1.9MiB 是另一个极端因为它压根没有连接池和缓冲区池。表里 Drogon、Cinatra、Oat 的满载数字比空载还低一点这是 RSS 采样时刻的正常波动不是真的把内存还回去了。Hical 和 cpp-httplib 空载满载完全一致倒是很干净。5.2 二进制 Docker 镜像大小框架二进制大小Docker 镜像备注Hical3.0M122MB本地源码 Boost 静态链接Drogon1.9M122MBTrantor jsoncpp 动态链接Oat767K118MB零外部依赖全静态链接Cinatra508K118MBHeader-onlyyalantinglibs 生态Crow401K118MBHeader-only极少运行时依赖cpp-httplib400K118MBHeader-only零外部依赖Hical 的 3.0M 是六家里最大的因为它把 Boost.Asio / Boost.JSON / Boost.System 全都静态链进去了。Crow、cpp-httplib、Cinatra 框架本身是 header-only外部依赖动态链接二进制里只有用户代码和少量模板实例化。Docker 镜像的差异主要来自基础镜像ubuntu:24.04 约 118MB各框架额外增量只有 0~4MB——所以镜像大小这个指标基本没有区分度。5.3 代码行数框架文件行数Crowcrow/main.cpp56cpp-httplibcpphttplib/main.cpp65Drogondrogon/main.cpp67Cinatracinatra/main.cpp84Hicalhical/main.cpp95Oatoatpp/main.cpp112wc -l含注释和空行按横评用的端点集统计。Hical 那 95 行里有 36 行是/middleware/0和/middleware/10两个端点只给 Hical 自己跟踪中间件开销用其他五家没有对应实现扣掉之后是 59 行跟 Crow 的 56 行基本持平。剩下的差异基本只是 API 风格——Crow 的CROW_ROUTE一行一个端点最省Oat 的 DTO Controller 定义最啰嗦。这个数字看看就好跟性能没关系。6. 延迟分析6.1 全场景延迟汇总Avg / Max场景CinatraHicalDrogonCrowOatcpp-httplibHello World149.52us / 12.22ms174.11us / 19.66ms195.54us / 16.08ms327.38us / 19.55ms2.92ms / 100.31ms27.56ms / 317.88msJSON 序列化166.70us / 10.01ms183.22us / 10.30ms285.04us / 12.26ms362.79us / 9.32ms3.27ms / 83.43ms29.93ms / 550.67msJSON Echo178.81us / 9.07ms234.31us / 13.15ms349.84us / 10.56ms428.62us / 9.31ms3.65ms / 152.02ms32.51ms / 541.59ms路径参数181.31us / 11.01ms192.86us / 10.45ms303.41us / 9.27ms370.34us / 8.21ms2.79ms / 93.68ms28.99ms / 238.31ms高并发 1K2.05ms / 238.93ms2.24ms / 152.87ms2.12ms / 166.47ms3.75ms / 16.43ms7.86ms / 1.67s276.80ms / 1.93s高并发 10K35.09ms / 2.00s31.56ms / 83.39ms29.49ms / 94.41ms53.33ms / 76.53ms54.73ms / 2.00s66.31ms / 1.88s6.2 延迟稳定性Stdev 是比平均延迟更重要的指标——尾延迟才是生产环境里导致用户体验劣化的真正杀手。场景CinatraHicalDrogonCrowOatcpp-httplibHello World183.62us315.23us265.15us255.88us7.22ms36.14ms高并发 1K3.25ms1.73ms1.26ms436.99us16.54ms370.58ms高并发 10K21.43ms10.14ms10.00ms3.04ms95.18ms241.97ms加粗为该项最低。基础场景100c下四家异步框架的 Stdev 都挤在 180~320us 这一档Cinatra 183.62us 最低Crow 和 Drogon 差不太多255.88us / 265.15usHical 的 315.23us 稍高一点。Crow 的稳是全场最扎实的——1K 时 Stdev 436.99us、10K 时 3.04ms两个档位都是最低。它 QPS 排在中游但延迟这条线上没什么短板。Hical 这一版的表现跟上一版正好翻了个面。上一版它在 10K 下的 Max 是 445.50ms六家里最差这一版是 83.39ms只比 Crow 的 76.53ms 高一点Stdev 10.14ms 同样只输给 Crow。1000 并发时 Max 152.87ms也优于 Drogon 的 166.47ms 和 Cinatra 的 238.93ms。Cinatra 反过来。10K 的平均延迟 35.09ms 看着还行Max 直接 2.00sStdev 21.43ms 是四家异步框架里最高的再加上那 2288 个 timeout。平均值这个指标把它的问题盖得严严实实。选型的时候如果只扫 Avg 这一列Cinatra 的 35ms 显得很稳妥而上一版 Hical 那个 445ms 又显得很不稳妥——两次都看走眼了。7. 综合分析与选型建议7.1 维度评分维度CinatraHicalDrogonCrowOatcpp-httplib基础 QPS★★★★★★★★★☆★★★★☆★★★☆☆★★☆☆☆★☆☆☆☆高并发扩展性★★★★☆★★★☆☆★★★★★★★★★☆★★☆☆☆★☆☆☆☆延迟稳定性★★☆☆☆★★★★☆★★★★☆★★★★★★☆☆☆☆★☆☆☆☆内存效率★★★☆☆★★☆☆☆★★★☆☆★★★★☆★★★★★★★★★★中间件灵活度★★☆☆☆★★★★★★★★★★★★☆☆☆★★☆☆☆★☆☆☆☆代码简洁度★★★☆☆★★★☆☆★★★★☆★★★★★★★☆☆☆★★★★★生态成熟度★★★☆☆★★☆☆☆★★★★★★★★☆☆★★★☆☆★★★★☆中间件灵活度和生态成熟度基于架构分析和社区现状评估非量化数据。所有维度按六框架内部横向比较不是绝对水平。7.2 各框架适用场景选 Cinatra如果纯吞吐是首要指标本文 6 个场景里它拿了 5 个第一想用 C20 协程 国产生态yalantinglibs需要 iguana 反射驱动的自动 JSON 序列化能接受高并发下明显的长尾10K 时 Max 2 秒 2288 个 timeout并且不介意中间件是全局 AOP 模型选 Drogon如果高并发是核心场景10K 连接下它是第一198K QPS且零错误需要久经考验的生产级框架和完整生态ORM、HTTP 客户端、WebSocket能接受 jsoncpp 在 JSON 密集场景的开销或打算换掉它选 Hical如果需要路由级中间件精确控制六家里只有 Hical 和 Drogon 支持本文未压测中间件此条为架构能力对 JSON 序列化性能敏感Boost.JSON 四个基础场景都在第二紧跟 iguana看重万级连接下的延迟波动和长尾10K 时 Max 83.39ms、Stdev 10.14ms两项都只输给 Crow选 Crow如果原型验证、内部工具、教学用途追求最小依赖和最快上手对延迟稳定性要求高于吞吐量1K/10K 的 Stdev 都是全场最低选 Oat如果零外部依赖是硬性需求喜欢 DTO Controller 的强类型 API 风格高并发不是核心需求选 cpp-httplib如果极致简洁不想引入任何构建依赖原型验证、脚本式 HTTP 服务、嵌入式场景对性能要求不高开发效率优先记住它 10K 并发下会报 16 万个 read 错误7.3 性能格局总结六框架性能依旧是“四档”格局只是每一档的位置动了动第一梯队Cinatra53万~61万和 Hical44万~56万。Drogon 在纯文本场景与它们同档52万但一进 JSON 就掉到 29万~36万卡在两档之间第二梯队24万~31万 QPSCrow 独占第三梯队12万~23万 QPSOat同步线程池模型的天花板第四档7万~8.5万 QPScpp-httplib但第一梯队内部不是一个平面。Cinatra 赢在纯吞吐和高并发 100010K 要看 Drogon要论万级连接下的长尾是 Crow 和 Hical 的地盘。选型的时候先想清楚自己最怕什么——怕吞吐上不去还是怕偶发长尾。8. 结论几点诚实的总结Cinatra 这轮还是赢得很干净。6 个场景里 5 个第一唯一输掉的是 10K 并发197K vs Drogon 198K差 0.2%。Hical 在 6 个场景里全部落后 Cinatra幅度 4.1%~21.5%。Cinatra 赢在基础吞吐但高并发下压不住尾巴。10K 时 Max 2.00s、Stdev 21.43ms、2288 个 timeout这三项在四家异步框架里都是最差的。平均延迟漂亮、尾巴失控这类问题在每天跑几亿请求的场景里一定会暴露出来。Hical 这轮的表现在两张表上相反。QPS 侧两个并发档位都比上一版各退了一名延迟侧它的长尾反而是六家里第二好的10K 时 Max 83.39ms上一版这个数是 445.50ms。同样是重测之后结论变了这次我没有 profiling 数据不做归因两组数都摆在这儿。平均值和 Max 讲的是两个故事。四家异步框架的 Avg 延迟在 29.49ms~53.33ms 之间最多差 1.8 倍Max 从 Crow 的 76.53ms 到 Cinatra 的 2.00s差了 26 倍。只看平均值那一列看不出这中间到底发生了什么。JSON 库选型比框架选型影响更大。Drogon 换掉 jsoncppJSON 场景的数字能立刻好一截而这是它四个基础场景里唯一明显掉队的地方。微基准不等于生产性能。Hello World 和实际业务之间隔着数据库查询、鉴权、日志、复杂对象序列化等大量 I/O框架的裸 QPS在生产里会被摊薄。可复现比可信更重要。本文的全部测试环境和脚本都已开源不同意结论docker compose up自己跑一遍。9. 复现指南所有测试代码、Docker 配置和压测脚本均已公开详见仓库benchmark/README.md包含完整的构建、启动、压测、采集和清理流程。gitclone https://github.com/hical61/hical.gitcdhical/benchmark# 后续步骤参照 benchmark/README.md跑之前建议先自查虚拟化环境见 2.1。这台 VM 上开着 Hyper-V 和不开着同一份二进制的成绩能差 4 倍——在那之前你测的是 hypervisor不是框架。利益声明本文作者是 Hical 框架的开发者。为减少偏见所有测试代码、Docker 配置和压测脚本均已公开欢迎复现验证。对 Hical 不利的数据同样如实展示6 个场景全部落后 Cinatra、10K 并发在四家异步框架里垫底、内存占用六家最高。