Posts

本系列以 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 模式——应用程序发起异步操作，操作系统完成后通知应用。 ...

课程导航：学习路径 | Boost.System | Boost.Asio | Boost.Beast | Boost.JSON | Boost.MySQL 前置知识 课程 1: Boost.System（error_code、system_error） 课程 2: Boost.Asio（io_context、协程、TCP socket） HTTP 协议基础（请求/响应格式、状态码、头部） 学习目标 完成本课程后，你将能够： 理解 Beast 的 HTTP message 模型和 Body 类型系统 使用 Parser 安全解析 HTTP 请求（含 body_limit 保护） 编写协程式 HTTP 服务端和客户端 实现 WebSocket 升级和消息循环 读懂 Hical 的 HttpServer、HttpRequest/Response 封装和 WebSocket 集成 目录 前置知识 学习目标 目录 1. 核心概念 1.1 Beast 的定位 1.2 HTTP message 模型 1.3 Buffer 体系 1.4 Parser 与安全限制 2. 基础用法 2.1 构建 HTTP 请求和响应 2.2 协程式 HTTP 服务端 2.3 Parser 高级用法 3. 进阶主题 3.1 WebSocket 3.2 自定义 Body 类型 3.3 超时机制 4. Hical 实战解读 4.1 handleSession：完整 HTTP 处理循环 4.2 HttpRequest/Response 封装 4.3 WebSocketSession 封装 4.4 handleWebSocket：升级与消息循环 4.5 错误处理模式 5. 练习题 练习 1：基础 HTTP 服务端 练习 2：body_limit 保护 练习 3：WebSocket Echo Server 练习 4：Keep-Alive 练习 5（挑战）：静态文件服务器 参考答案 练习 1 参考答案：基础 HTTP 服务端 练习 2 参考答案：body_limit 保护 练习 3 参考答案：WebSocket Echo Server 练习 4 参考答案：Keep-Alive 练习 5 参考答案：静态文件服务器 6. 总结与拓展阅读 Beast 核心 API 速查表 HTTP 请求处理数据流 拓展阅读 下一步 1. 核心概念 1.1 Beast 的定位 Beast 是协议实现库，不是 Web 框架。它在 Asio 之上添加 HTTP/WebSocket 协议的解析和序列化，但不提供路由、中间件等应用层功能（这些由 Hical 提供）。 ...

课程导航：学习路径 | Boost.System | Boost.Asio | Boost.Beast | Boost.JSON | Boost.MySQL 前置知识 课程 1: Boost.System（error_code 用于安全解析） C++ 基础：模板、if constexpr、可变参数模板 JSON 数据格式基础 学习目标 完成本课程后，你将能够： 掌握 Boost.JSON 的值类型体系（value/object/array） 安全解析和序列化 JSON 数据 理解 PMR 分配器如何加速 JSON 操作 读懂 Hical 的 MetaJson 反射层——自动 JSON 序列化的实现原理 目录 前置知识 学习目标 目录 1. 核心概念 1.1 Boost.JSON vs 其他 JSON 库 1.2 值类型体系 1.3 构造与访问 2. 基础用法 2.1 创建 JSON 值 2.2 解析 JSON 字符串 2.3 序列化为字符串 2.4 访问和修改 2.5 类型转换 3. 进阶主题 3.1 PMR 分配器集成 3.2 增量解析 3.3 tag_invoke 自定义序列化 3.4 错误处理 4. Hical 实战解读 4.1 HttpRequest::jsonBody() 4.2 HttpResponse::setJsonBody() 4.3 HttpResponse::json() 工厂 4.4 MetaJson.h：反射驱动的自动序列化 4.5 PMR 与 JSON 的协同 5. 练习题 练习 1：JSON 解析与提取 练习 2：HICAL_JSON 宏实战 练习 3：安全 JSON 验证器 练习 4：PMR 性能对比 练习 5（挑战）：扩展 valueToJson 参考答案 练习 1 参考答案：JSON 解析与提取 练习 2 参考答案：HICAL_JSON 宏实战 练习 3 参考答案：安全 JSON 验证器 练习 4 参考答案：PMR 性能对比 练习 5 参考答案：扩展 valueToJson 支持 optional 6. 总结与拓展阅读 C++ 类型 ↔ JSON 类型映射表 API 速查表 拓展阅读 课程回顾 1. 核心概念 1.1 Boost.JSON vs 其他 JSON 库 特性 Boost.JSON nlohmann::json RapidJSON simdjson 接口风格 Boost 风格 STL 风格 SAX/DOM 只读 PMR 支持 原生 无 自定义 Allocator 无 增量解析 stream_parser 无 SAX API 无 编译速度 快（header-only 可选） 慢 快 快 可变性 读写 读写 读写 只读 Boost 集成 天然 独立 独立 独立 Hical 选择 Boost.JSON 的原因： ...

课程导航：学习路径 | Boost.System | Boost.Asio | Boost.Beast | Boost.JSON | Boost.MySQL 前置知识 C++ 基础（类、模板、异常处理） 了解操作系统错误码概念（errno、GetLastError） 学习目标 完成本课程后，你将能够： 理解 error_code + error_category 的设计原理 掌握 I/O 操作中 错误码 和 异常 两种错误处理模式 编写自定义 error_category 读懂 Hical 的跨平台错误码映射层 目录 前置知识 学习目标 目录 1. 核心概念 1.1 为什么需要统一的错误码体系 1.2 error_code 三要素 1.3 error_category 体系 1.4 error_condition vs error_code 2. 基础用法 2.1 创建和检查 error_code 2.2 两种错误处理模式 2.3 常见错误码速查表 3. 进阶主题 3.1 自定义 error_category 3.2 跨平台错误码映射 4. Hical 实战解读 4.1 Error.h：框架级错误码枚举 4.2 Error.cpp：fromBoostError 跨平台映射 4.3 错误码在连接管理中的使用 4.4 设计模式总结 5. 练习题 练习 1：error_code 基础 练习 2：自定义 error_category 练习 3：阅读源码 参考答案 练习 1 参考答案 练习 2 参考答案 练习 3 参考答案 6. 总结与拓展阅读 核心要点 拓展阅读 下一步 1. 核心概念 1.1 为什么需要统一的错误码体系 C 语言 errno 的问题： ...

Hical 是一个现代 C++ 高性能 Web 框架，基于 Boost.Asio/Beast，具备 PMR 内存池、协程异步 I/O、WebSocket、SSL/TLS、C++26 反射层等特性。本文覆盖游戏行业 + 通用行业的全部适用场景。 一、游戏行业场景（简要） 场景 说明 GM/运营后台 REST API + 静态页面 + Session 鉴权 支付/SDK 回调网关 高并发 HTTP 接入，协程非阻塞 WebSocket 实时服务 聊天、排行榜推送、GM 监控 内部微服务 HTTP 层 MetaJson/MetaRoutes 零样板代码 二、通用行业场景 1. IoT / 嵌入式设备管理后台 ⭐ 高匹配度 为什么适合： IoT 网关和嵌入式设备普遍用 C/C++ 开发，Hical 保持语言一致性 单二进制部署，无运行时依赖，适合资源受限环境（树莓派、工控机） PMR 内存池提供可预测的内存行为，避免 GC 抖动 WebSocket 双向通信天然适合设备状态实时推送 典型用例： 设备状态监控 Dashboard（HTTP + WebSocket 推送） 固件 OTA 更新接口（Multipart 文件上传） 传感器数据采集 HTTP 接口 边缘计算节点的本地 Web 管理界面 2. 高频交易 / 量化金融辅助服务 为什么适合： ...

C++26 反射落地实战：双路线条件编译实现自动路由注册、JSON 序列化与 OpenAPI 文档生成 本文以 Hical 框架（v2.5）为例，展示如何在 C++26 反射尚未被主流编译器完全支持的现阶段，用"C++26 反射 + C++20 宏回退"的双路线策略，让用户享受相同的 API——从 JSON 序列化、路由注册到 OpenAPI 3.0 文档自动生成。 问题：Web 框架中的重复样板代码 每个 Web 框架都有三大类重复劳动： 1. 路由注册——每个处理函数都要手写一行注册： 1 2 3 4 5 6 router.get("/api/users", listUsers); router.get("/api/users/{id}", getUser); router.post("/api/users", createUser); router.put("/api/users/{id}", updateUser); router.del("/api/users/{id}", deleteUser); // ... 50 个路由 = 50 行手写注册 2. JSON 序列化——每个 DTO 都要手写字段映射： 1 2 3 4 json["name"] = user.name; json["age"] = user.age; json["email"] = user.email; // ... 10 个字段 = 10 行手写映射 3. API 文档——每个接口都要手写 OpenAPI 描述，且与代码脱节： ...

为 C++ Web 框架设计三层 PMR 内存池：从原理到实战 本文以 Hical 框架为例，深入讲解如何利用 C++17 PMR（Polymorphic Memory Resource）为高并发 Web 服务器构建三层内存池架构。 为什么 Web 服务器需要自定义内存管理？ 一个 HTTP 请求的生命周期中，框架需要分配大量临时对象：解析缓冲区、路径字符串、JSON 值、响应体。在高并发场景下（如 50K QPS），new/delete 的全局锁竞争会成为显著瓶颈： 1 2 3 50,000 请求/秒 × 每请求 ~20 次分配 = 1,000,000 次/秒 new/delete ↓ 全局堆锁竞争 → CPU 空转 传统方案是自研内存池，但 C++17 提供了标准化的解决方案 —— PMR。 PMR 速览 PMR 的核心思想：把内存分配策略从容器类型中解耦。 1 2 3 4 5 // 传统方式：分配器绑定在类型中 std::vector<int> vec; // 永远用 std::allocator // PMR 方式：运行时切换分配策略 std::pmr::vector<int> vec(&myPool); // 用自定义内存池 标准库提供了三种现成的内存资源： ...

从零构建现代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) 更快。参数路由数量通常很少（几十个），线性扫描完全可以接受。 ...