你会亲手构建什么

第一阶段：ReactorX 事件驱动引擎（Day 1–5）

一切性能的根基。

• Day 1 实现 epoll 封装（Poller）和事件分发抽象（Channel），第一次运行时你会看到键盘输入被事件循环捕获——这是事件驱动从概念变成代码的一刻
• Day 2 构建 EventLoop，实现 One Loop Per Thread 框架，到这天结束你已经能写一个真正跑起来的 echo server
• Day 3 接入基于 timerfd 的定时器
• Day 4 实现 eventfd 跨线程唤醒和线程池
• Day 5 做压测，QPS 可达 50 万+

第二阶段：NetCore 高性能网络库（Day 6–10）

在事件驱动引擎之上，搭建完整的网络抽象层。

• Day 6 封装 Socket RAII
• Day 7 实现 Acceptor 连接接受器（含 idleFd 技巧防止 fd 耗尽）
• Day 8 实现三区域自动扩容 Buffer（readv 系统调用一次读取所有数据）
• Day 9 是整个网络库最难也最精华的一天——TcpConnection 的四状态机、shared_ptr + weak_ptr + tie机制防止野指针和提前析构、高水位回调控制发送缓冲
• Day 10 把所有组件粘合成 Multi-Reactor 架构的 TcpServer，主 Reactor 只接连接，Sub Reactor 池负责 IO，Round-Robin 负载均衡，三十行代码启动支持数万并发的多线程服务器

第三阶段：RocketRPC 框架层（Day 11–25）

这才是今天的核心。

Day 11：项目骨架 + protobuf 入门

CMake 工程配置，第一个.proto文件，protoc 代码生成流程，用 NetCore TcpServer 验证接口。很多人卡在这里——不知道 protobuf 生成的代码是怎么跟框架连接起来的。这天讲清楚。

Day 12–13：协议抽象层 + TinyPB 编解码

Day 12 实现 AbstractProtocol 和 AbstractCoder 抽象层，用开闭原则讲清楚为什么要有这一层——协议可以换，上层框架代码一行不改。Day 13 是课程第一个硬核技术点：TinyPB 二进制帧格式逐字节讲解，查表法 CRC32 真实实现（对比 rocket 原版硬编码为 1 的"假校验"），网络字节序处理，encode/decode 完整实现。

Day 14：TcpClient 实现

NetCore 原生没有客户端组件，这是本项目新增的。非阻塞 connect 的 EINPROGRESS 处理（很多人在这里踩坑），基于map<msg_id, callback>的异步响应匹配——这是 RPC 客户端能做到"发出请求、回调通知"的底层机制。

Day 15：异步日志系统

独立线程写磁盘，sem_t + 条件变量驱动，framework log 与 app log 分离设计，日志文件按大小自动切分。为什么要在框架层之前先做日志？因为后面每一个模块出了问题，你都需要它。

Day 16：错误码 + msgid + 配置系统

pid + 时间戳 + 原子计数器生成全局唯一 msgid，这是跨服务链路追踪的基础。配置文件驱动端口、线程数、日志级别，不再硬编码。

Day 17：RpcController + RpcClosure

protobuf 四件套（Service / RpcChannel / RpcController / Closure）的关系从这天开始清晰起来。RpcController 携带 msgid、超时、错误码，RpcClosure 包装std::function回调。对比 rocket 原版的裸指针，说明shared_ptr在这里为什么是必要的，不是风格偏好，是生命周期问题。

Day 18：RpcDispatcher（本课程最精华的一天）

protobuf 反射 dispatch 逐行拆解：FindMethodByName→GetRequestPrototype→ParseFromString→CallMethod→SerializeToString。五个调用，串起了从"收到一个字节流"到"业务方法被调用"的完整路径。看懂这一天，你就真正理解了 gRPC 的 dispatch 机制是怎么回事。

Day 19：RpcServer（服务端整合）

messageCallback接入 TinyPBCoder decode，解码后进 RpcDispatcher，dispatch 完成后 encode + send。配置文件驱动启动流程。

Day 20：RpcChannel（客户端异步调用链）

CallMethod 的完整路径：序列化 → connect → writeMessage → readMessage → 反序列化 → closure 回调。per-call 超时控制用EventLoop.runAfter触发取消，shared_from_this保证异步回调时对象还活着。RpcChannel 使用独立的 client_loop，与服务端 EventLoop 完全隔离——这个设计决策在文档里说清楚为什么这样做。

Day 21：端到端联调（第一个完整 RPC 调用）

OrderImpl 上线，客户端 Order_Stub 发起 makeOrder，std::promise/future封装同步调用接口，端到端跑通。这是整个课程的第二个里程碑时刻——你第一次看到自己写的 RPC 框架完成一次真实调用。

Day 22：ConnectionPool（连接池 + 性能对比）

演示无池版本每次 RPC 新建连接的开销，然后实现连接池：空闲队列 + mutex + 条件变量，acquire/release 接口，心跳探活剔除失效连接，RpcChannel 改造接入连接池。压测数据就是上面那张表——从 P99 10ms 压到 0.2ms，QPS 从 1.2 万涨到 13.3 万，同一套业务代码，只换了连接池。

Day 23：ZooKeeper 服务注册 + 心跳

IP 硬编码的问题在这天被彻底解决。ZooKeeper 临时节点即心跳——session 断开，节