C++20

从零构建现代C++ Web服务器（六）：数据库中间件与协程连接池 系列导航：第一篇：设计理念 | 第二篇：协程与内存池 | 第三篇：路由、中间件与SSL | 第四篇：实战与性能 | 第五篇：Cookie、Session与文件服务 | 第六篇：数据库中间件（本文） 前置知识 阅读过本系列前五篇（特别是第二篇的协程基础和第三篇的中间件洋葱模型） 了解 SQL 基础和 MySQL 数据库操作 了解连接池的基本概念 目录 1. Web 框架为什么需要数据库层 2. 架构总览：六层洋葱 3. 后端抽象：DbConnection 接口 4. MySQL 实现：any_connection 封装 5. LRU PreparedStatement 缓存 6. 协程连接池：用 steady_timer 做信号量 7. DB 中间件：请求级连接生命周期 8. 查询日志：装饰器模式的妙用 9. 综合实战：用户管理 API + 数据库 10. 总结 1. Web 框架为什么需要数据库层 前五篇构建了 hical 的完整 HTTP 骨架——协程驱动的异步 I/O、PMR 内存池、路由、中间件、SSL、Cookie/Session、静态文件。但现实中的 Web 服务几乎都绑定数据库：用户注册要写库、商品查询要读库、交易扣款要事务。 如果把数据库操作留给业务代码自行处理，会出现几个典型问题： 问题 后果 每个请求都新建连接 MySQL 握手 + 认证 ≈ 1-3ms，高并发下成为瓶颈 业务代码管理连接生命周期 忘记关闭 → 连接泄漏，异常时忘记回滚 → 数据不一致 手动拼接 SQL SQL 注入漏洞（游戏服务器的经济系统被注入 = 灾难） 同步 MySQL 客户端 mysql_query() 阻塞 io_context 线程 → 吞吐暴跌 hical v2.3.0 补齐了这最后一块拼图： ...

设计 Hical OpenAPI 模块的心得 一、为什么要做这件事 Hical 框架从一开始就内建了两套反射基础设施：MetaJson（DTO 字段反射）和 MetaRoutes（路由反射）。这意味着框架在编译期就已经知道"每个结构体有哪些字段、叫什么名字、什么类型、是否必填"以及"每个 Handler 有哪些路由、什么方法、什么路径"。 这些信息恰好是生成 OpenAPI spec 所需要的全部输入。 在 C++ Web 框架领域，Drogon 通过插件支持 Swagger，Oat++ 有内建的 API 文档生成，但没有任何 C++ 框架能做到"从 C++20 宏反射层自动导出 OpenAPI 3.0 spec"这件事。这是 Hical 反射层设计的一个天然延伸，也是最有潜力的差异化卖点。 做之前我最担心的问题是：C++20 的宏回退路径能不能提取足够的类型信息来生成 JSON Schema？C++26 的 jsonSchema<T>() 可以用 std::meta::type_of(member) 直接获取字段类型，但 C++20 只有 FieldDescriptor<Class, FieldType> 的成员指针。后来发现，通过 decltype(std::declval<T>().*(field.pointer)) 在 fold expression 的每次展开中推导出具体的 FieldType，完全可以做到。这个验证结果让我决定动手。 二、架构决策 四层分离 最终的架构是四层设计： 1 2 3 4 Layer 4: OpenApiEndpoint.h — serveOpenApi() / Swagger UI Layer 3: OpenApiDocument.h/cpp — 文档组装 Layer 2: OpenApiRegistry.h/cpp — 路由元数据收集 + 标注宏 Layer 1: OpenApiSchema.h — JSON Schema 生成 这不是一开始就想好的。最初的想法是把所有东西塞进一个 OpenApi.h 里——Schema 生成、路由收集、文档组装、端点注册全放一起。但很快发现几个问题： ...

课程导航：学习路径 | Boost.System | Boost.Asio | Boost.Beast | Boost.JSON | Boost.MySQL 前置知识 课程 1: Boost.System（error_code、system_error） 课程 2: Boost.Asio（io_context、协程、co_await + use_awaitable） SQL 基础（SELECT/INSERT/UPDATE/DELETE、事务） MySQL 数据库基本操作 学习目标 完成本课程后，你将能够： 理解 Boost.MySQL 的类型擦除连接模型（any_connection） 使用 C++20 协程执行异步数据库操作 掌握参数化查询和 PreparedStatement 防 SQL 注入 理解结果集类型体系（results / static_results） 实现事务控制（BEGIN/COMMIT/ROLLBACK） 读懂 Hical 的连接池、Statement 缓存和数据库中间件设计 目录 前置知识 学习目标 目录 1. 核心概念 1.1 Boost.MySQL 的定位 1.2 连接类型体系 1.3 查询执行模型 1.4 结果集类型体系 2. 基础用法 2.1 建立连接 2.2 执行文本查询 2.3 参数化查询（客户端格式化） 2.4 PreparedStatement 2.5 结果集遍历 2.6 事务控制 3. 进阶主题 3.1 类型擦除连接 any_connection 3.2 静态类型结果集 static_results 3.3 多结果集（存储过程） 3.4 连接池 connection_pool 3.5 错误处理与诊断 4. Hical 实战解读 4.1 MysqlConnection：any_connection 的框架封装 4.2 StmtCache：LRU PreparedStatement 缓存 4.3 DbConnectionPool：协程式连接池 4.4 DbMiddleware：请求级连接生命周期 4.5 DbQueryLog：查询日志装饰器 4.6 完整请求处理流程 5. 练习题 练习 1：协程式 CRUD 练习 2：参数化查询实战 练习 3：事务与错误处理 练习 4：LRU 缓存设计 练习 5（挑战）：连接池实现 6. 总结与拓展阅读 核心 API 速查表 查询方式对比 拓展阅读 课程回顾 1. 核心概念 1.1 Boost.MySQL 的定位 Boost.MySQL 是一个纯异步的 MySQL 客户端库，直接实现 MySQL 客户端/服务器协议（不依赖 libmysqlclient），天然集成 Boost.Asio 的异步模型。 ...

C++20 实战心得：现代 C++ 真正成熟的一代 C++11 是革命，C++17 是打磨，C++20 是让 C++ 终于像一门「现代语言」。 写在前面 如果说 C++17 的升级是务实的，那 C++20 就是一次结构性的飞跃。协程、Concepts、Ranges、Modules——每一个都是重量级特性。但老实说，截至 2026 年，并非所有特性都已经在生产环境中稳定好用。 这篇文章从我在游戏服务器和 Hical 框架开发中的实际使用出发，聊聊哪些 C++20 特性已经值得用、哪些还需要等等。 一、Concepts —— 模板错误信息终于能看懂了 1.1 C++20 之前的模板报错 先感受一下 C++17 时代的"恐怖"： 1 2 std::list<int> lst; std::sort(lst.begin(), lst.end()); GCC 会喷出几十行模板展开错误，核心意思是 std::list::iterator 不是随机访问迭代器——但你得从一堆 __normal_iterator、__gnu_cxx 嵌套模板中自己悟出来。 1.2 Concepts：把约束说人话 1 2 3 4 5 6 7 8 9 template <std::random_access_iterator Iter> void mySort(Iter first, Iter last) { // ... } std::list<int> lst; mySort(lst.begin(), lst.end()); // 错误信息：约束 'random_access_iterator' 不满足 // 一行，清清楚楚 Concepts 的本质：给模板参数加上编译期的「类型契约」。SFINAE 能做的它都能做，但写法是人能读懂的。 ...

本系列以 Hical 框架源码为实战案例，系统讲解项目使用的 5 个核心 Boost 库。 本系列与 Hical 框架系列的关系 系列 视角 目标读者 Hical 框架系列（01-05） 框架怎么设计 想理解 Hical 架构的人 Boost 学习课程 Boost 库怎么用 想掌握 Boost 库本身的人 同一段源码（如 TcpServer::acceptLoop()），Blog 讲 “为什么用协程做 accept 循环”，本系列讲 "async_accept + use_awaitable 的 API 语义是什么"。 学习路径 1 2 3 4 5 6 7 8 9 10 11 课程 1: Boost.System ← 最基础，error_code 是所有 I/O 操作的返回值 │ ▼ 课程 2: Boost.Asio ← 核心 I/O 引擎，依赖 error_code │ ├───────────────┐ ▼ ▼ 课程 3: Boost.Beast 课程 5: Boost.MySQL ← 都构建在 Asio 异步模型之上 │ ▼ 课程 4: Boost.JSON ← 数据层，与 HTTP 请求/响应及数据库结果配合 课程概览 # 课程 核心主题 前置依赖 预计时长 1 Boost.System 统一错误码、error_category、跨平台映射 C++ 基础 1-2 小时 2 Boost.Asio io_context、协程、TCP、定时器、多线程模型 课程 1 4-6 小时 3 Boost.Beast HTTP 消息模型、Parser、WebSocket、SSL 课程 1+2 3-4 小时 4 Boost.JSON 值类型体系、解析/序列化、PMR 集成、反射 课程 1 2-3 小时 5 Boost.MySQL 协程式数据库访问、连接池、PreparedStatement 缓存 课程 1+2 3-5 小时 各课程一句话摘要 课程 1 — Boost.System：理解 error_code + error_category 体系，掌握 I/O 操作的两种错误处理模式（错误码 vs 异常）。 课程 2 — Boost.Asio：从 io_context 出发，掌握 C++20 协程式异步 I/O，学会 TCP 服务器、定时器和多线程模型。 课程 3 — Boost.Beast：在 Asio 之上构建 HTTP/WebSocket 协议层，学会请求解析、响应构建和 WebSocket 消息循环。 课程 4 — Boost.JSON：掌握 JSON 值类型操作、PMR 高性能分配，以及 Hical 反射层如何实现自动序列化。 课程 5 — Boost.MySQL：掌握协程式异步数据库访问、参数化查询防注入、连接池设计，以及 Hical 的 Statement 缓存与数据库中间件。 开发环境准备 编译器要求 编译器 推荐版本 GCC 14+ Clang 20+ MSVC 2022 Boost 安装 Linux (apt)： ...

课程导航：学习路径 | Boost.System | Boost.Asio | Boost.Beast | Boost.JSON | Boost.MySQL 前置知识 课程 1: Boost.System（error_code、system_error） C++ 基础：模板、lambda、智能指针 C++20 协程语法（co_await、co_return）——本课程会从零讲解 学习目标 完成本课程后，你将能够： 理解 io_context 的工作原理和生命周期管理 掌握 C++20 协程式异步编程（co_await + use_awaitable） 编写协程式 TCP 服务器和客户端 使用 steady_timer 实现定时任务 理解多线程模型的选型和 strand 序列化 读懂 Hical 的 EventLoop、连接管理和 SSL 集成 目录 前置知识 学习目标 目录 1. 核心概念 1.1 Asio 的设计哲学 1.2 io_context：事件循环的心脏 1.3 Executor 模型：post vs dispatch 1.4 三种异步完成方式 2. 基础用法 2.1 最小 io_context 示例 2.2 TCP 基础：同步与异步 2.3 协程式异步 I/O 2.4 steady_timer 定时器 2.5 buffer 操作 3. 进阶主题 3.1 多线程模型 3.2 strand 序列化执行 3.3 SSL/TLS 支持 3.4 signal_set 信号处理 4. Hical 实战解读 4.1 AsioEventLoop：io_context 的框架封装 4.2 dispatch vs post 实战 4.3 EventLoopPool：多线程池模型 4.4 AsioTimer：定时器的生产级封装 4.5 TcpServer：协程式 accept 循环 4.6 Coroutine.h：协程工具函数 4.7 SSL 集成 5. 练习题 练习 1：协程式 Echo Server 练习 2：周期性日志 练习 3：多 io_context 模型 练习 4：SSL Echo Server 练习 5：协程式 HTTP 客户端 参考答案 练习 1 参考答案：协程式 Echo Server 练习 2 参考答案：周期性日志 练习 3 参考答案：多 io_context 模型 练习 4 参考答案：SSL Echo Server 练习 5 参考答案：协程式 HTTP 客户端 6. 总结与拓展阅读 核心 API 速查表 三种异步模式对比 拓展阅读 下一步 1. 核心概念 1.1 Asio 的设计哲学 Boost.Asio 采用 Proactor 模式——应用程序发起异步操作，操作系统完成后通知应用。 ...

从零构建现代C++ Web服务器（一）：设计理念与架构总览 系列导航：第一篇：设计理念（本文） | 第二篇：协程与内存池 | 第三篇：路由、中间件与SSL | 第四篇：实战与性能 | 第五篇：Cookie、Session与文件服务 | 第六篇：数据库中间件 前置知识 熟悉 C++17、C++20 基础语法（模板、智能指针、lambda、协程、Concepts） 了解 TCP/IP 和 HTTP 协议基本概念 对异步编程模型有初步认知 目录 1. 为什么在 2026 年用 C++ 写 Web 框架？ 2. 现有方案分析 3. hical 的设计目标 4. 两层架构设计 5. C++20 Concepts 做后端抽象 6. 线程模型：1 Thread : 1 io_context 7. 全文总结 1. 为什么在 2026 年用 C++ 写 Web 框架？ 当大多数团队选择 Go、Rust 或 Node.js 构建 Web 服务时，用 C++ 写 Web 框架似乎是"逆潮流而行"。但事实是，在特定场景下 C++ 仍然不可替代： 极致性能需求：游戏服务器、实时通信、高频交易等场景对延迟敏感到微秒级别 与现有 C++ 生态集成：当你的业务逻辑、数据处理库本身就是 C++ 时，跨语言调用引入的开销和复杂度不可忽视 内存可控：C++ 没有 GC 暂停，配合内存池可以实现完全可预测的内存行为 更重要的是，C++20/26 带来了一系列改变游戏规则的特性： ...

从零构建现代C++ Web服务器（三）：路由、中间件与 SSL 系列导航：第一篇：设计理念 | 第二篇：协程与内存池 | 第三篇：路由、中间件与SSL（本文） | 第四篇：实战与性能 | 第五篇：Cookie、Session与文件服务 | 第六篇：数据库中间件 前置知识 阅读过本系列前两篇（架构分层、协程基础、PMR 内存池） 了解 HTTP 请求/响应基本结构 了解中间件（Middleware）的概念（如 Express/Koa 的洋葱模型） 目录 1. 路由系统设计 2. 洋葱模型中间件管道 3. 模板化 SSL：编译期零开销 4. WebSocket 集成 5. 组装：HttpServer 门面 6. 总结 1. 路由系统设计 1.1 双策略路由：快速与灵活的平衡 Web 框架的路由系统需要处理两类路径： 静态路由：/api/status、/api/users — 路径固定，可以精确匹配 参数路由：/users/{id}、/posts/{pid}/comments/{cid} — 路径含变量，需要模式匹配 hical 采用双策略设计： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 请求到达: GET /api/users/42 │ ▼ ┌─────────────────────────────┐ │ 1. 静态路由查找 (O(1)) │ │ unordered_map 哈希表 │ │ 查找 {GET, "/api/users/42"} │ │ → 未命中 │ └───────────┬─────────────────┘ │ ▼ ┌─────────────────────────────┐ │ 2. 参数路由匹配 (线性扫描) │ │ 遍历 paramRoutes_: │ │ {GET, "/users/{id}"} │ │ → 匹配！提取 id = "42" │ └───────────┬─────────────────┘ │ ▼ 执行 handler 为什么不统一用 Trie 树？因为绝大多数实际应用中，静态路由占比远大于参数路由。用哈希表处理静态路由是 O(1)，比 Trie 的 O(path_length) 更快。参数路由数量通常很少（几十个），线性扫描完全可以接受。 ...

从零构建现代C++ Web服务器（二）：协程异步与 PMR 内存池 系列导航：第一篇：设计理念 | 第二篇：协程与内存池（本文） | 第三篇：路由、中间件与SSL | 第四篇：实战与性能 | 第五篇：Cookie、Session与文件服务 | 第六篇：数据库中间件 前置知识 了解协程关键字（co_await、co_return、co_yield）的基本含义 理解智能指针和 RAII 模式 了解 std::pmr（Polymorphic Memory Resource）的基本概念 目录 从零构建现代C++ Web服务器（二）：协程异步与 PMR 内存池 前置知识 目录 1. 从回调地狱到 co_await 1.1 传统回调方式 1.2 协程方式 1.3 协程的工作原理（简化） 2. Awaitable：hical 的协程基石 工具函数 3. 协程在框架中的实际应用 3.1 Accept 循环 3.2 HTTP 会话处理 3.3 协程执行全景 4. PMR 内存池：为什么默认 allocator 不够好 4.1 问题分析 4.2 Benchmark 对比 5. 三层内存架构深度剖析 5.1 教学代码：从零实现简化版三层 PMR 5.2 教学代码：三层管理器 5.3 generation 计数器的妙用 6. PmrBuffer：零拷贝缓冲区 6.1 设计思路 6.2 教学代码：简化版 PmrBuffer 6.3 makeSpace 策略图解 7. 协程 + PMR 协同 8. 总结 核心要点 下篇预告 1. 从回调地狱到 co_await 1.1 传统回调方式 假设我们要写一个 TCP Echo Server。传统的异步回调方式是这样的： ...

从零构建现代C++ Web服务器（五）：Cookie、Session、静态文件与文件上传 系列导航：第一篇：设计理念 | 第二篇：协程与内存池 | 第三篇：路由、中间件与SSL | 第四篇：实战与性能 | 第五篇：Cookie、Session与文件服务（本文） | 第六篇：数据库中间件 前置知识 阅读过本系列前四篇（特别是第三篇的中间件洋葱模型） 了解 HTTP Cookie 与 Session 基本概念 了解 multipart/form-data 编码格式基本原理 目录 1. Web 应用的"最后一公里" 2. Cookie：无状态协议的状态记忆 3. Session：从 Cookie 到有状态会话 4. 静态文件服务：安全地托管资源 5. Multipart 文件上传：解析 RFC 7578 6. 综合实战：带登录的文件管理服务 7. 全系列总结 1. Web 应用的"最后一公里" 经过前四篇的铺垫，hical 已经具备了完整的 HTTP 服务器骨架——协程驱动的异步 I/O、PMR 内存池、双策略路由、洋葱模型中间件、SSL/WebSocket 支持，以及反射宏系统。 但如果你真正尝试用它搭建一个 Web 应用，很快就会发现少了几样东西：用户登录后刷新页面状态丢失、无法提供前端静态资源、用户没法上传头像文件。这些功能看似"基础"，却是 Web 应用从"能跑通"到"能用"的最后一公里。 hical v1.0.0 补齐了这四块拼图： 模块 解决的问题 集成方式 核心文件 Cookie HTTP 无状态协议下的客户端状态存储 req.cookie() / res.setCookie() Cookie.h HttpRequest.cpp HttpResponse.cpp Session 服务端有状态会话管理 makeSessionMiddleware() 中间件 Session.h Session.cpp StaticFiles 安全地托管前端/资源文件 serveStatic() 工厂函数 StaticFiles.h Multipart 文件上传（RFC 7578） MultipartParser::parse() 静态方法 Multipart.h Multipart.cpp 它们在 hical 整体架构中的位置： ...