Paozhu vs Drogon —— 系统设计对比

基于源码实测（paozhu(https：//github.com/hggq/paozhu)，drogon(https://github.com/drogonframework/drogon)，均取 2026-10 最新源码目录）。

源码目录分析：drogon-master 经核查为 drogon 1.9.14（2026-10-11），其 lib/ 与 trantor/ 中不含 HTTP/2 服务器实现（无 Http2Server/Http2Connection；lib/src/HttpServer.cc 仅输出 HTTP/1.1，无 h2/ALPN 注册；trantor 只有 TLS 层的 ALPN 能力桩）。paozhu 则内置 HTTP/2（http2_parse.cpp 等）。故下文对 drogon 的 HTTP/2 描述以「drogon-master 实际代码」为准——drogon 主线截至 1.9.14 尚未内置 HTTP/2 服务器实现，paozhu 的 HTTP/2 是两者间的实际差异化能力。

0. 一句话定位

• Drogon：典型「muduo 风格」+ 反射宏注册 + 编译期代码生成，偏工业级、生态完整、上层 API 友好。
• Paozhu（炮竹）：单 io_context + Asio C++20 协程贯穿全栈（连 ORM 查询都是协程），HTTP/1.1 与 HTTP/2 均自研，偏「全异步协程 + 多租户」。

1. 并发 / IO 模型（核心差异）

设计哲学差异：

• Drogon 的「多独立循环」更贴合 Reactor 经典模型，单连接全程绑定一个线程，无锁、缓存亲和好。
• Paozhu 的「单 io_context 多 worker」是 Asio 经典模型，协程帧在堆上、不占 io 线程；业务与 IO 显式分层（io 协程 vs 业务 clientrunpool），router::co_resolve 会逐步派单：协程步就地 co_await，同步步进业务池（server.cpp:2351 注释）。

2. HTTP 协议层

说明：request.h 命名易误导——paozhu 真正的 HTTP 请求模型是 httppeer。

3. 路由系统（深度）

两者都是「声明式路由注册」，但机制分叉：Drogon 走编译期反射 + 宏 + 静态自注册；Paozhu 走源码注解 + 构建期 codegen 生成 reg_raw 表。此外 Paozhu 额外内置了基于 httppeer::flow_method 的简单任务编排（见 §3.4），Drogon 无对等机制。

3.1 注册方式与代码生成

Paozhu（controller/src/*.cpp 写 //@urlpath(pre,urlpath):mask，构建期 paozhu_pre 扫描）：

• 生成产物 common/autocontrolmethod.hpp 中是一张 reg_raw 调用表（autocontrolmethod.hpp:127-141）：reg_raw(site, path, pre_sync, co_pre, reg_sync, co_reg, mask_code)。每个路由登记 5 个槽位：同步 pre、co_await 版 pre、同步 handler、协程 handler、以及 //@urlpath 注解里的数字 mask_code（区分 HTTP method）。
• 带 :param 段的路径紧随其后用 reg_urlpath(site, path, {param_names...}) 单独登记参数名表（autocontrolmethod.hpp:139-140）。
• 注册期还生成 common/autorestfulpaths.hpp、common/reghttpmethod.hpp 等辅助表。

Drogon（HttpController.h 宏，编译期）：

• METHOD_ADD(method, pattern, ...) / ADD_METHOD_TO(method, path, ...)（HttpController.h:31-34）→ registerMethod(&method, pattern, {...}, ...)；还支持 ADD_METHOD_VIA_REGEX（:35）写正则。
• 静态自注册：每个 controller 含 class methodRegistrator + static methodRegistrator registrator_（HttpController.h:127-139），构造函数里把方法名 + 参数包登记进框架——在 main 之前由 CRT 静态初始化完成，零运行时扫描。类名到路径的映射由 DrClassMap::demangle(typeid(T).name()) 自动推导（HttpBinder.h:235），:: 转 /。

3.2 匹配结构

Paozhu：核心 router 类（router.h:32），运行时把 reg_raw 填进 _handlers / _urlpath_map / _site_to_slot（全局 slot 0，多租户见 §3.5）；co_resolve(peer, known_idx)（router.h:79）协程驱动整条匹配+pre+handler 链，并带 route_exact_checked 优化（httppeer.h:298-299，rpc/同步链跳过重复精确查找）。

• 找不到精确匹配时前缀回退最多 6 段（router.cpp 两级查表：lookup_exact → lookup_registered → lookup_key_in_slots，router.cpp:180-185），未注册的跳转名在编排排空时被跳过（router.cpp:350-363）。

Drogon：HttpControllersRouter + StaticFileRouter。三套结构（HttpControllersRouter.cc）：

• simpleCtrlMap_：无参数精确匹配（小写 key 的 std::unordered_map）。
• ctrlMap_：带参数但结构固定的精确路由，ctrlMap_.find(loweredPath) 直接哈希命中（HttpControllersRouter.cc:626）。
• ctrlVector_：含 :param / 正则的路由，编译期把 {param} 占位符换成 ([^/]*)（regex_replace，:564），运行时 std::regex_match 线性匹配（:635-640）。
• 每路由 binders_[req->method()] 按 HttpMethod 分桶；initMiddlewaresAndCorsMethods 自动注入中间件并开 OPTIONS/CORS（:58/63/75）。

3.3 预处理链（pre handler）与同步/协程混编

Paozhu —— 每条路由拆成 4 个独立槽位，同步与协程是「路由层一等公民」：reg_raw(site, path, pre_sync, co_pre, reg_sync, co_reg, mask_code)（common/autocontrolmethod.hpp）把一条路由注册为 同步 pre / 协程 pre / 同步 handler / 协程 handler 四个独立入口。主驱动 co_resolve（router.h:79，router.cpp:694）透明交织二者：协程步就地 co_await（pre co_await h.co_pre(peer) router.cpp:750-755；handler co_await h.co_regfun(peer) :806-811），同步步交给业务线程池执行；老版纯同步链 resolve() 已 #if 0 停用（:537 与其调用点 ThreadPool::http_clientrun 一并停用）。

• 同步/协程混编是内置能力：同一请求里「同步 pre 鉴权 → 协程 handler 查库」「协程 pre → 同步 handler」都可直接声明，框架按各入口的 pre_kind/reg_kind 自动分流，开发者无需自己切线程或包 std::async。这与 Drogon「handler 选一种形态、CoroMapper 是另一个类型」的设计思想不同——Paozhu 把「是否协程」下沉为每个注册入口的属性，而非整条 handler 的类型。
• 自带的 urlpath pre 拦截：每个路由的 pre_sync/co_pre 按声明顺序串成串行 pre 链；classify_step() 据返回值判定走向——@ok（放行）、同名（继续）、@exit（显式终止）、跳转名（router.cpp:76-87），首个非空即短路，空串是唯一放行信号（router.cpp:458-461）。此外还有站点级 pre/after hooks：run_site_hooks（同步 :462）与 co_run_site_hooks（协程 :478）批量跑 action_pre_lists/action_after_lists，超限时截断到前 site_hook_limit 条而非整条丢弃（避免鉴权静默失效）。
• flow 栈排空：编排栈排空时（pop_flow_index），若驱动是同步链却弹到协程条目则停止排空（:364-368），协程驱动则就地 co_await 继续（:865-873）。

Drogon：pre 逻辑由 Filters（HttpFilter + ADD_FILTER_TO / GlobalFilters.cc）与 Middlewares（HttpMiddleware，MiddlewaresFunction.cc + HttpAppFramework.h:718）承载，框架在 handler 前按 path/全局顺序执行，与路由表解耦、可复用、可排序。同步/异步的选择落在单个方法形态上（binder 的 Blocking/Callback/future 三态，或协程用独立的 CoroMapper），没有「一条路由同时声明同步 pre + 协程 handler」这种按入口拆分的混编槽位。

3.4 简单任务编排（Paozhu flow_method）—— 是，Paozhu 支持

结论：是的，Paozhu 在 httppeer 上内置了简单任务编排，通过 httppeer::flow_method 实现「单请求内多 handler 顺序编排」。

• 结构：httppeer 持有一个懒分配的栈 std::unique_ptr> flow_method（httppeer.h:300-301）——存的是后续要执行的 handler 名。
• 入栈 API（httppeer.cpp:2135-2155）：
  • push_next(name)：push_back（栈顶，LIFO，后压先出）。
  • push_last(name)：push_front（栈底，FIFO，先压先出——顺序拆解的默认推荐）。
  • push_steps({...})：批量压入。
• 出栈/消费（httppeer.cpp:2156-2169 pop_flow() 取 back 弹出；router.cpp:340-368 pop_flow_index）：一个 handler 正常完成（返回空串）后，路由器从栈弹下一个已注册 handler 名并接着执行；一个 handler 只弹一个，剩余等它自己「返回空串」再弹，直到栈空或整链触顶（router.cpp:651-657 同步链、834-839 协程链）。
• 流程控制指令：kFlowOk / kFlowExit（显式终止、不弹栈）/ kFlowTimeloop（转事件循环）由 classify_step 解释（router.cpp:76-87）。
• 健壮性：弹出未注册名时跳过继续弹下一个（不吞掉整条编排，:350-363）；协程条目压到同步链上按设计停下（:364-368）。

这意味着一个请求可以「handler A → 压 B、C、D → A 返回空串后依次跑 B→C→D」，构成轻量顺序工作流 / pipeline。Drogon 没有对等的内建机制：它的组合原语是 Filters/Middlewares（横切关注，非顺序步骤编排）与 handler 自身逻辑；若要在 Drogon 里串多个 handler，需 handler 内手动调用或重定向，框架层不提供编排栈。

3.5 多租户 / 站点 slot

Paozhu：路由天然挂在站点 slot 上——host_index → slot，_site_to_slot 每站点一条 slot，路由表按 slot 隔离（router.cpp:337 find_name_in_slots(peer_slot(peer), ...)）；reg_raw 第一个参数就是 site（域名，空串=全局 slot 0）。配合 §9 的主题视图，是框架级多租户。 Drogon：路由本身不带租户概念；多租户靠「多 app / 多 controller 分组 + DrObject 命名」在业务层实现，无一站式 slot 隔离。

3.6 小结对照表

核心差异：Drogon 的路由是「宏反射 + 静态注册 + Filters/Middlewares」的工业级经典范式，关注点分离干净；Paozhu 是「注解 + codegen + 站点 slot + flow_method 编排」的一体化范式，额外给了请求内顺序任务编排这一轻量工作流能力，且多租户在路由层即内建。

4. ORM 深度对比

二者均支持 MySQL / PostgreSQL / SQLite 三方言，且 ORM 查询都支持 C++20 协程异步。但在生成时机、代码组织、查询风格、缓存、事务、关系表达上差异显著。

4.1 生成代码结构

Paozhu（paozhu_cli orm ，生成器 vendor/httpcli/modelfun.hpp）每张表产出三层：

• _base.h：纯数据/反射层——namespace _info 含 col_count、enum cols、struct meta（字段定义）、type:: 类型别名、col_names、null_col 位图、assign_field_value（world_base.h:41-45、L76-80），以及脏字段位图 __dirty_bits + get_dirty_indices()/clear_dirty()/make_update_dirty_sql()。
• _opsql.h：template class _opsql : public B_BASE（含全部查询/缓存/脏更新方法，构造时按 dbtag 从 get_orm_conn_pool_obj() 取 orm_conn_pool）。
• 脏更新机制：setXxx() 写字段时标记对应脏位；update_dirty()（文本协议）/ exec_update_dirty()（预编译）/ async_update_dirty() / async_exec_update_dirty() / commit_update_dirty() 仅对脏位字段拼 UPDATE，执行成功后 clear_dirty()；脏位为空时短路、不发出全字段误更新，且缺 WHERE 时拒绝执行（article_opsql.h:9866/15248/10319/15323/13120）。这与 Drogon 的 dirtyFlag_[] 机制等价，都是「只写变化列」的增量更新。

Drogon（drogon_ctl create_model，复用 CSP 模板 model_h.csp/model_cc.csp）每张表生成一个模型类（示例 orm_lib/tests/mysql/Users.h）：

关键差异：Paozhu 把「数据定义(base)」与「SQL 操作(opsql)」分离成两个文件并支持外联关系 .cpp；Drogon 把所有东西塞进一个模型类，持久化细节用 private + friend 封装，更面向对象。

4.2 查询 API 风格

Paozhu —— 链式 builder（返回 M_MODEL&），方法名偏「直接 SQL 动词」：

Drogon —— 流式 Mapper + Criteria（模板 Mapper 在 orm/Mapper.h:115，构造收 DbClientPtr）：

风格差异：Paozhu 偏向「熟悉的链式动词 + 每列快捷方法」，上手成本低；Drogon 用 Criteria 表达式对象 + Mapper 流式设置，类型安全更强、但需理解 Criteria/SqlBinder 体系。

分页对比：Paozhu 的 page() 自动复用已设 where，一次调用完成「计数 + 取数 + 返回导航四元组」；Drogon 的 paginate(page,perPage)（Mapper.h:173/2013）仅设 offset/limit，count() 默认 Criteria() 空条件（Mapper.h:459），需把同一 Criteria 分别传给 count(criteria) 与查询，分页导航（总页数/窗口）要自己算。

4.3 缓存机制（最大功能差异）

Paozhu 缓存已知局限（实测）：

结论：Paozhu 自带查询级结果缓存（可显著降 DB 压力，但需注意上述局限）；Drogon 把缓存交给上层（如 Redis / 业务层），ORM 本身每次查询都打连接池。

4.4 异步与协程模型

Paozhu —— 全协程（Asio co_await）：

Drogon —— 三形态（同步 / 回调 / future），协程为叠加层：

4.5 事务

差异：Drogon 用一等 Transaction 对象塞进 Mapper，API 干净、可组合；Paozhu 是把事务连接 lock 到模型上，更手动、需显式 unlock 防泄漏。

4.6 关系 / 外键

Paozhu：oneXXX/manyXXX 在外联 .cpp（orm/fk_child_opsql.cpp：oneFkParent(L9)/manyFkParent(L38)；orm/fk_parent_opsql.cpp：oneFkChild(L9)/manyFkChild(L38)），实现即用本表外键值对关联模型 where()/whereIn()；另提供通用 leftJoin() 做显式 JOIN。

Drogon：关系是「生成期配置 + 运行时每模型方法」，无 hasMany/hasOne 风格的通用 Mapper 关系 API。

4.7 类型映射与参数绑定

Paozhu：生成期 modelfun.hpp 用 pg_type_to_mysql_type()(L337) 与 SQLite 亲和性映射(L886+) 把 SQL 类型转 MySQL 二进制类型码，再 get_field_type()(L1232) 按码映射 C++（0x03→int、0x08→long long、0x0A-0x0D 日期→string、0xFC-0xFE varchar/text→string），最终由 _base.h struct meta + type:: 落地。

Drogon：生成期 create_model.cc 直接按库写死映射（PG L309-360 / MySQL L621-679 / SQLite L870-902）。参数绑定 SqlBinder::operator<<（SqlBinder.h:382-444）按 ClientType 分支：

4.8 连接池

Paozhu：orm_conn_pool.cpp 按 dbtag 维护读写分离连接池（async_get_mysql_select_conn 读 / async_get_mysql_edit_conn 写），协程取/建连接（co_await async_add_*_connect）；后端 pg_conn/mysql_conn/sqlite_conn 各自实现 async_* 非阻塞 I/O，由 init_orm_conn_pool(io_context,...)（server.cpp:9269）启动。

Drogon：DbClientImpl（orm_lib/src/DbClientImpl.cc）三态集合 connections_/readyConnections_/busyConnections_（互斥保护）；execSql 有空闲则取用，否则压入 sqlCmdBuffer_（上限 200000，超限报 “Too many queries in buffer”）；按 connNum 决定事件循环数（SQLite 固定 1 个，PG/MySQL 取 hardware_concurrency() 与 connNum 较小值）。各库连接类 PgConnection/MysqlConnection/Sqlite3Connection 仅负责单连接非阻塞 I/O；支持 execSqlWithTimeout 超时抛 TimeoutError。

底层协议实现差异（架构级）：

4.9 业务代码风格（实际写法）

§4.2 讲的是 API 形态，这里给出真实业务代码长什么样（均取自两侧源码示例）。

Paozhu —— 模型对象即查询构建器，链式动词 + 协程/同步双形态（示例 controller/src/testormcache.cpp / testcrud.cpp）：

// 模型对象本身就是 builder；条件、缓存、查询一气呵成
Article art;
art.where("isopen", 1).whereEQ(art.Alias::aid, aid).use_cache();  // 链式条件 + 查询缓存
co_await art.fetch_one();                          // 协程查询，结果回填 art
client << "
title:" << art.getTitle();
if (art.is_hit_cache()) { /* 命中缓存分支 */ }// 分页：直接返回 (bar_min, bar_max, current_page, total_page)
unsigned int page = client.get["page"].to_int();
auto [lo, hi, cur, total] = art.page(page, 10, 5); // page, per_page, 导航栏宽度

风格要点：拿到模型实例 → 在其上 .where()/.whereEQ()/.use_cache()/.fetch_one()/.page() 链式拼装 → 协程 co_await 或同步 fetch_one()；没有独立的 Mapper 层，模型即 DAO。

Drogon —— 泛型 Mapper + Criteria 表达式，按模型类型 CRUD（示例 orm_lib/tests/db_test.cc）：

using namespace drogon_model::postgres;
Mapper mapper(clientPtr);          // clientPtr = app().getDbClient()
Users user;
user.setUserId("pg"); user.setUserName("alice");
mapper.insert(user);                      // 同步写入
auto u = mapper.findByPrimaryKey(2);      // 按主键查// 协程形态
CoroMapper cmapper(clientPtr);
auto cu  = co_await cmapper.findByPrimaryKey(2);
auto us  = co_await cmapper.orderBy(Users::Cols::_user_id).limit(2).findAll();
auto one = co_await cmapper.findOne(Criteria(Users::Cols::_id, CompareOperator::EQ, 1));

风格要点：Mapper 是独立于模型对象的通用 CRUD 门面，条件用 Criteria(列, 比较符, 值) 表达式构造；模型对象只承载数据 + setter/getter，所有持久化操作经 Mapper 发起。

一句话：Paozhu 是「模型自己会查自己」（builder 内聚在模型上，动词式、上手快）；Drogon 是「Mapper 代理模型 CRUD」（泛型门面 + Criteria 表达式，类型安全、关注点分离更清晰）。

4.10 小结对照表

核心差异要点：

5. 流量限制对比

两者限流定位完全不同：Drogon 是请求级（per-IP / per-user / per-route，令牌桶/滑窗/固定窗，插件开箱即用）；Paozhu 是连接接纳级过载保护（60 秒连接数窗口 + 负载自适应放行率）+ 站点上传限额 + IP 封锁。

5.1 Drogon —— 请求级 RateLimiter + Hodor 插件

核心类（lib/inc/drogon/RateLimiter.h）：

Hodor 插件（lib/inc/drogon/plugins/Hodor.h，Drogon 官方限流插件）：

Drogon 的限流是生产级、细粒度、声明式：配一段 JSON 即可对 /api/.* 做「全局 1000/s + 单 IP 100/s + 单用户 50/s」的组合策略，算法可换。

5.2 Paozhu —— 连接接纳级过载保护 + 上传限额 + IP 封锁

连接接纳限速（内建在 httpserver 核心，server.h:247 ratelimiter() 线程驱动）：

上传限额：httppeer::check_upload_limit()（httppeer.cpp:789，站点级 host_index 守卫）——按站点限制上传体大小。

IP 封锁：check_blockip(peer_session)（server.cpp:5757，TLS 握手失败连接不计入流量），配合黑名单/白名单做接入层拦截。

Paozhu 没有「per-IP / per-user / per-route 请求配额」这一层；要做单 IP QPS 限制需自己写中间件（利用 router 的 site pre hooks 或 flow_method 链）。

5.3 小结对照表

核心差异：Drogon 把限流做成业务友好的请求级配额（单 IP/用户/路由、可换算法、插件化）；Paozhu 把限流做成系统级的连接过载闸门（防雪崩、平滑接纳），并附上传限额与 IP 封锁。两者不重叠——若 paozhu 需要「单 IP 100 QPS」，得用 router 的 site pre hooks 自写计数器；若 drogon 需要「连接总量过载保护」，得靠 OS/反向代理或自写 filter。

6. 协议与中间件支持（WebSocket / MQTT / Redis / RPC / Socket）

这一维差异极大：Paozhu 把五类协议全部内置到 httpserver 核心（且用统一的 subpub 注册模型贯穿 ws/mqtt/socket）；Drogon 仅内置 WebSocket 与 Redis，MQTT / RPC / 裸 Socket 服务器均无框架级支持。

6.1 WebSocket

6.2 Redis

6.3 MQTT

6.4 RPC

6.5 裸 Socket / TCP 服务器

6.6 架构主题：统一的 subpub 注册模型

Paozhu 在 ws/mqtt/socket 三处都使用 *_subpub_reg（ws_subpub_reg / mqtt_subpub_reg / sock_subpub_reg）——同一套「订阅注册 + 发布分发」内核贯穿多协议；Redis 也走 redis_subpub。这是 paozhu「协议全家桶」背后的统一抽象。Drogon 各能力彼此独立（WebSocket 控制器、Redis nosql 库、无 MQTT/socket），没有跨协议的统一 pub/sub 内核。

6.7 小结对照表

核心差异：Paozhu 是「多协议全家桶」——一个框架同时是 HTTP/2、WebSocket、MQTT(broker)、Redis、RPC、裸 Socket 服务器，且由统一 subpub 内核串联；Drogon 是「专注 HTTP 的 Web 框架」——WebSocket 与 Redis 一等公民，其余协议（MQTT/RPC/TCP）交由外部库或自行扩展，框架本身不内建。

7. 控制器与代码生成

差异要点：

7.1 最小可运行示例（注解函数 vs 注册宏）

Paozhu —— 注解函数（取自 controller/src/testrand.cpp，真实最简写法）：

#include "httppeer.h"
namespace http
{
//@urlpath(null,testrand)        // 站点(null=全局 slot) + URL 路径；无前置过滤器
std::string testrand(std::shared_ptr peer)
{httppeer &client = peer->get_peer();client << "

随机数: " << rand_range(100, 999) << "

Drogon —— 注册宏（HttpController + 反射，类名自动转路径）：

class TestCtrl : public drogon::HttpController
{public:METHOD_LIST_BEGIN// 路径 "/testrand"，GET 方法，绑定 testrand 方法ADD_METHOD_TO(TestCtrl::testrand, "/testrand", Get);METHOD_LIST_ENDvoid testrand(const HttpRequestPtr &req,std::function &&cb) const{auto resp = HttpResponse::newHttpResponse();resp->setBody("

随机数

一句话：Paozhu 是「在业务代码里写一行 //@urlpath 注解就完成注册」，回归式、零样板；Drogon 是「在类里用 METHOD_LIST_BEGIN/ADD_METHOD_TO 宏声明路由」，宏反射、需继承 HttpController 基类。

8. C++20 协程

关键差异：Paozhu 把协程作为唯一一等公民（IO、业务、DB 全链路 awaitable）；Drogon 是「回调/future 为基础 + 协程叠加」的混合模型。Paozhu 用 Asio 的标准 co_await；Drogon 自研 Task/Awaiter 体系。

9. 多租户 / 主题

Paozhu 的多租户是框架级内建（域名→slot→路由表隔离 + 主题视图），Drogon 本仓无对等的一站式多租户抽象。

10. 依赖与工程化

10.1 收口：零第三方依赖的内置「全家桶」（Paozhu 工程化主线）

把前面各节的自研点收拢成一句话：Paozhu 的强制外部依赖极薄（约 Asio + OpenSSL 3），其上是几乎全栈自研；Drogon 核心同样薄（trantor + OpenSSL/Botan），但能力靠组合生态。

Paozhu 自研覆盖（不引入对应第三方库）

Drogon 对照（薄核心 + 生态组合）

代价与收益同源：Paozhu 的「全家桶自研」带来部署简单（少装外部库）、能力一致、零协议授权/版本纠缠，但代码体量巨大、自研一切正确性自担、生态/社区小（见 §11）；Drogon 则把「做透 HTTP + 易组合」作为工程主线。

11. 设计取舍总结

Paozhu 强项

Paozhu 代价

Drogon 强项

Drogon 代价（drogon-master 实测）

12. 选型建议

附：关键源码证据索引