C++20

Hical 性能剖析实战：perf + 火焰图定位 QPS 瓶颈 在 C++ 框架性能实测中，Hical 的 Hello World QPS（~27K）远低于 Cinatra（165K）和 Drogon（161K）。静态链接 + strip 验证后确认瓶颈不在链接方式。本文记录用 perf record + 火焰图精确定位 CPU 热点的全过程。 目录 1. 背景与动机 2. Profiling 环境搭建 3. 数据采集 4. 火焰图分析 5. 优化方向 6. 复现指南 1. 背景与动机 1.1 已排除的因素 在本次 profiling 之前，已经通过对照实验排除了以下因素： 假设 验证方式 结论 动态链接 Boost 有性能损耗 改为 Boost 静态链接，重跑压测 QPS 无显著变化（27K → 27K） strip 影响性能 strip vs 不 strip 对比 无影响（符号表不参与运行时） 二进制体积（icache 压力） 7.8M(strip) vs 9.3M(不strip) QPS 在噪声范围内，非瓶颈 排除结论：性能瓶颈在框架运行时架构，需要 profiling 定位具体热点函数。 ...

2026 年 C++ Web 框架横评：Hical vs Drogon vs Cinatra vs Crow vs Oat++ 如果你在 2026 年启动一个需要 C++ Web 服务的项目，面前摆着 Drogon、Cinatra、Crow、Oat++ 和 Hical 五个选择。该怎么选？本文从架构设计、异步模型、内存管理、功能完整度、开发体验五个维度做一次横向对比，帮你快速定位最适合的框架。 一句话概括 框架 一句话定位 Drogon 久经考验的高性能全栈框架，TechEmpower 榜单常客 Cinatra header-only 的 C++20 协程 HTTP 框架，阿里 yalantinglibs 生态成员 Crow 极简轻量的微框架，Express.js 风格，上手最快 Oat++ 零依赖、内置 Swagger 的 API 框架，嵌入式友好 Hical 自研 HTTP/WS 栈 + PMR 内存池 + C++26 反射的现代全栈框架 核心对比表 Hical Drogon Cinatra Crow Oat++ C++ 标准 C++20（C++26 就绪） C++17 / C++20 C++20 C++14 / C++17 C++11+ 异步模型 协程（co_await 全链路） 回调 + 协程混合 协程（async_simple::Lazy） 回调 自研异步 API 内存管理 PMR 三层内存池 默认分配器 默认分配器 默认分配器 默认分配器 HTTP 解析 picohttpparser（自研栈） 自研（Trantor） 自研 自研 自研 SSL/TLS 编译期模板分支 运行时分支 运行时配置 运行时分支 运行时分支 路由 哈希表 O(1) + 参数线性 基数树 字符串匹配 + 正则 前缀树 Controller 映射 中间件 洋葱模型（协程链） Filter 链 AOP 切面 基础 Interceptor WebSocket 内置（自研 RFC 6455） 内置 内置 内置 内置 Cookie / Session 内置（RFC 6265） 内置 有限 有限 有限 文件上传 内置（DoS 防护） 内置 内置 需手动 内置 静态文件 内置（ETag/304） 内置 内置 需手动 有限 ORM 协程化 DB 中间件（MySQL） 内置（PG/MySQL/SQLite） 无（生态有 ormpp） 无 模块化（PG/SQLite/Mongo） OpenAPI/Swagger 内置（自动生成 + Swagger UI） 第三方 无 无 内置 日志系统 内置（6 级 + 异步双缓冲 + 通道路由） 自带（简易） 基础 无 自带（loggers） CORS 内置中间件 内置 需手动 需手动 内置 HTTP/2 不支持 支持 不支持 不支持 不支持 反射/自动序列化 C++26 双轨（原生 + 宏） 无 生态有 struct_json/struct_pack 无 宏 DTO 系统 HTTP 客户端 无 内置 内置（协程化） 无 内置 外部依赖 Boost.Asio + OpenSSL + zlib Trantor + jsoncpp + … 无（可选 OpenSSL） Asio 零依赖 License MIT MIT MIT BSD-3 Apache-2.0 深度对比 1. 异步模型 这是选框架时最该关注的维度，因为它决定了你写业务逻辑的方式。 ...

Hical 踩坑实录五部曲（二）：MSVC / GCC / Clang 三平台 C++20 编译差异 引言 Hical 从第一天起就要求在 GCC 14+、Clang 20+、MSVC 2022+ 三个编译器上通过 CI。框架大量使用了 C++20 新特性：Concepts、co_await 协程、PMR 内存池、std::format、__VA_OPT__ 递归宏。 三平台兼容的代价就是踩三倍的坑。 这篇文章记录了开发 Hical 过程中遇到的编译器差异踩坑——每个坑按统一结构展开：现象 → 最小复现 → 根因 → 解决方案。 目录 Hical 踩坑实录五部曲（二）：MSVC / GCC / Clang 三平台 C++20 编译差异 引言 目录 坑 1：模板参数推导差异——GCC 过、MSVC 报错 坑 2：Concepts 约束检查时机差异 坑 3：__VA_OPT__ 宏展开行为差异 坑 4：PMR allocator 传播行为差异 坑 5：std::format 可用性与行为差异 坑 6：协程 promise_type 与异常处理差异 坑 7：链接顺序敏感——Windows 特有的 ws2_32 问题 经验总结：三平台兼容清单 编译器设置 C++20 特性 协程 一般性 坑 1：模板参数推导差异——GCC 过、MSVC 报错 现象：一段在 GCC 14 上完美编译的透明哈希代码，在 MSVC 上报 C2672: no matching overloaded function found。 ...

Hical 踩坑实录五部曲（一）：Boost.Asio 协程开发的 N 个坑 引言 Hical 的所有异步 I/O 都基于 Boost.Asio 协程（co_await + boost::asio::use_awaitable）。路由处理器返回 Awaitable<HttpResponse>，中间件用洋葱模型 co_await next(req)，连接池用 co_await timer.async_wait() 做非阻塞等待。 协程消除了回调地狱，但引入了一套全新的陷阱。这篇记录的每一个坑，都是在压测或线上环境中真实触发过的。 目录 Hical 踩坑实录五部曲（一）：Boost.Asio 协程开发的 N 个坑 引言 目录 坑 1：co_await 后 this 悬挂——对象已析构 坑 2：协程异常传播——catch 里不能 co_await 坑 3：steady_timer 当协程信号量的技巧 坑 4：jthread vs thread——精准匹配停止信号 坑 5：多线程 io_context + 协程的线程安全陷阱 坑 6：detached 协程的异常黑洞 坑 7：io_context::stop() 不等于安全退出 总结：协程安全编程检查清单 坑 1：co_await 后 this 悬挂——对象已析构 现象：压测时低概率崩溃，堆栈指向 TcpServer 的 accept 循环，访问了已释放的内存。 最小复现： 1 2 3 4 5 6 7 8 9 10 11 // ❌ 危险的写法 Awaitable<void> TcpServer::acceptLoop() { while (running_) { auto socket = co_await acceptor_.async_accept(use_awaitable); // ⚠️ 如果在 co_await 期间 TcpServer 被析构， // this 已经是悬空指针！ this->createConnection(std::move(socket)); // 💥 use-after-free } } 根因：协程帧通过 co_spawn(io_context, coroutine, detached) 提交到 io_context。协程帧的生命周期由 io_context 管理，与创建协程的对象完全分离。 ...

Hical 协程入门：告别回调地狱，用 co_await 写异步 C++ 传统 C++ 异步编程离不开回调嵌套、状态机、手动生命周期管理——代码写得像意大利面。C++20 协程从根本上改变了这一切：异步代码写起来和同步一样直观，编译器帮你管理暂停与恢复。本文从零讲解如何在 Hical 框架中使用协程，不需要你懂 Boost.Asio 底层。 什么是协程？30 秒版本 传统回调式： 1 2 3 4 5 6 7 8 9 10 11 12 // 回调嵌套——"回调地狱" socket.async_read(buffer, [&](error_code ec, size_t n) { if (!ec) { socket.async_write(buffer, [&](error_code ec2, size_t) { if (!ec2) { socket.async_read(buffer, [&](error_code ec3, size_t) { // 继续嵌套... }); } }); } }); 协程式： 1 2 3 4 // 同样的逻辑，协程版——像写同步代码一样 auto n = co_await socket.async_read(buffer, use_awaitable); co_await socket.async_write(buffer, use_awaitable); auto n2 = co_await socket.async_read(buffer, use_awaitable); co_await 会暂停当前函数，等 I/O 完成后自动恢复执行。没有回调，没有嵌套，错误用 try/catch 处理。 Hical 对协程做了什么封装？ Hical 在 Coroutine.h 中提供了三个核心工具： ...

C++ 也能优雅写 Web？5 分钟用 Hical 搭建 REST API 提到 C++ 写 Web 服务，你脑海中浮现的可能是满屏的模板报错、手动解析 HTTP 报文、以及回调嵌套到看不清缩进的代码。但在 2026 年，C++20 协程 + PMR 内存池 + C++26 反射的组合，已经让 C++ Web 开发体验发生了质变。本文用 Hical 框架带你体验：10 行代码启动 HTTP 服务器，40 行代码搞定完整 REST API。 10 行代码，启动 HTTP 服务器 1 2 3 4 5 6 7 8 9 10 11 12 13 #include "core/HttpServer.h" using namespace hical; int main() { HttpServer server(8080); server.router().get("/", [](const HttpRequest&) -> HttpResponse { return HttpResponse::ok("Hello, hical!"); }); server.start(); } 1 2 curl http://localhost:8080/ # Hello, hical! 没有工厂类，没有 Builder 链，没有 XML 配置。创建服务器、注册路由、启动 —— 三步完事。 ...

实测：C++ vs Go vs Rust，谁的 Web 性能更强？ “2026 年了，还有人用 C++ 写 Web 服务？” 这个问题我被问过不止一次。答案是：有，而且有相当充分的理由。本文不是要说服你用 C++，而是把三种语言放在同一个擂台上，用数据说话，帮你在实际项目里做出最合适的选择。 目录 1. 背景：三种语言在 Web 领域的 2026 年现状 2. 测试环境与方法论 3. Hello World QPS 对比 4. JSON CRUD QPS 对比 5. 内存占用对比 6. 开发效率对比 7. 生态与工具链对比 8. 各语言适用场景 9. 总结 1. 背景：三种语言在 Web 领域的 2026 年现状 C++：从游戏服务器到高性能 API C++ 在 Web 领域长期处于"少数派"地位，但 2020 年代之后情况在变化。C++20 协程（co_await）和 PMR 内存池让 C++ 的异步 Web 编程体验大幅改善；C++26 的反射提案进一步压缩了模板样板代码。游戏公司、金融公司、CDN 基础设施商是 C++ Web 服务的主要用户群——他们要么已经有大量 C++ 代码，要么对延迟的要求超出了 GC 语言的舒适区。 ...

从零构建现代C++ Web服务器（七）：生产级日志系统 系列导航：第一篇：设计理念 | 第二篇：协程与内存池 | 第三篇：路由与中间件 | 第四篇：实战与调优 | 第五篇：Cookie 与 Session | 第六篇：数据库中间件 | 第七篇：日志系统（本篇） 前置知识 阅读过第三篇的中间件洋葱模型 了解 C++20 std::format、std::jthread 了解日志系统的基本概念（级别、格式化、输出目标） 目录 1. 为什么需要自研日志系统？ 2. Phase 1：基础增强——从 fprintf 到 std::format 3. Phase 2：异步后端——从同步到生产级 4. Phase 3：结构化日志与可观测性 5. 性能深度分析 6. 线程安全设计 7. 实战：5 分钟搭建完整日志体系 8. 总结与设计决策表 9. 核心要点 10. 知识图谱 1. 为什么需要自研日志系统？ 前六篇把 hical 的核心骨架搭完了：协程 I/O、内存池、路由、中间件、SSL、会话、数据库。唯一的短板是日志——每次排查问题只能翻 stderr，没有文件、没有结构、没有追踪 ID。真正的生产环境里，日志比功能代码重要得多：功能代码决定程序的行为，日志决定你能不能在凌晨三点用最短时间还原那行让服务崩掉的数据路径。 1.1 现有轮子的取舍 先看市面上的主流方案： 库 优点 对 hical 的问题 spdlog 成熟、快（每秒数百万条）、格式丰富 外部依赖；fmt 与 std::format 语义略有差异 glog Google 出品，稳定 C++03 风格 API；宏冗余；不支持 std::format Trantor drogon 自带，协程时代设计 与 drogon 强耦合，无法独立引入 log4cxx 功能完备、配置文件驱动 重量级；Java 移植风格与现代 C++ 格格不入 自研 零依赖、API 与框架深度融合 需要投入设计成本 hical 的核心约束是零外部依赖——整个框架只依赖 Boost 和 OpenSSL，任何新模块都不能打破这条线。spdlog 引入 fmt 库就已经违规，glog 的 API 风格与现代 C++ 割裂，Trantor 无法解耦。 ...

用 Hical + MySQL 5 分钟搭建 CRUD API（C++20 协程版） C++ 访问数据库难吗？2026 年不再难了。本文用 Hical 的协程 DB 中间件，带你从零搭建一个完整的 MySQL CRUD API —— 连接池管理、事务自动提交/回滚、慢查询检测，全部开箱即用，代码比大多数 Python 教程还简洁。 三种姿势对比 方式 代码量 连接池 异步 防注入 裸 mysql_query 多，手动管理连接 手写 阻塞 手拼字符串，危险 ORM（如 ODB） 少，但有运行时膨胀 内置 视实现而定 安全 Hical 协程中间件 少，原生协程 内置 非阻塞 co_await PreparedStatement Hical 走第三条路：连接池是协程化的，查询全部走 PreparedStatement 防注入，事务在中间件层自动管理，业务代码只关心 SQL 逻辑。 环境准备 构建启用数据库支持 1 2 3 4 5 6 7 8 9 10 11 12 # Linux / macOS cmake -B build -DHICAL_WITH_DATABASE=ON -DCMAKE_BUILD_TYPE=Release cmake --build build -j$(nproc) # Windows (MSYS2 MINGW64) cmake -B build -G Ninja -DHICAL_WITH_DATABASE=ON -DCMAKE_BUILD_TYPE=Release cmake --build build # Windows (MSVC + vcpkg) cmake -B build -DHICAL_WITH_DATABASE=ON -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake cmake --build build --config Release 依赖说明 Boost >= 1.85（DB 中间件需要 Boost.MySQL，1.85 版引入 any_connection） OpenSSL（MySQL TLS 连接可选，已是框架强依赖） CMakeLists 里加一行即可： 1 2 target_link_libraries(my_app PRIVATE hical::hical_core) # HICAL_WITH_DATABASE=ON 时 hical_core 自动链接 Boost.MySQL 建表 SQL 1 2 3 4 5 6 7 8 9 10 11 CREATE DATABASE IF NOT EXISTS demo CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE demo; CREATE TABLE IF NOT EXISTS users ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, name VARCHAR(64) NOT NULL, email VARCHAR(128) NOT NULL UNIQUE, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; 完整 main.cpp 约 80 行，包含连接池初始化、中间件注册、4 个 CRUD 路由： ...

从零构建现代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 补齐了这最后一块拼图： ...