因为需控制序列化（如cereal）、网络模型（asio异步/连接复用）和错误路径，手写轻量RPC更透明；请求响应须为POD、无虚函数、字段public或提供serialize，用长度前缀防粘包，超时靠steady_timer cancel socket，多方法用enum分发并捕获异常。
为什么不用现成的 gRPC 或 Apache Thrift？
因为你要控制序列化方式、网络模型和错误传播路径——比如想用 cereal 做 header-only 的二进制序列化，又希望连接复用、支持异步调用、不引入 protobuf 代码生成。这时候手写一个轻量 RPC 框架反而更透明，也更适合学习或嵌入已有 asio 项目。
如何定义可序列化的请求/响应结构？
cereal 要求类型显式声明序列化逻辑，且必须是 POD 或满足特定构造要求。RPC 的 request/response 类不能带虚函数、不能有非默认构造的成员（除非你手动实现 load/save），也不能含裸指针。
- 所有字段必须 public，或提供
serialize成员函数 - 避免
std::shared_ptr直接嵌套在消息体里；改用std::optional或原始值 - 函数名、参数类型、返回值类型需在 client/server 两端完全一致（cereal 不校验语义）
struct AddRequest {
int a = 0;
int b = 0;
template
void serialize(Archive& ar) { ar(a, b); }
};
struct AddResponse {
int result = 0;
bool success = true;
template
void serialize(Archive& ar) { ar(result, success); }
};
如何用 asio 封装一次带超时的二进制 RPC 调用？
核心是把「发请求 → 等响应 → 解析」串成 asio 的异步流程。不能直接用 boost::asio::write + read，因为没长度头会导致粘包。必须自己加 4 字节长度前缀，server 才能分帧。
- client 发送前：先用
cereal::BinaryOutputArchive序列化到std::vector，再前置写入 size_t（转为 network byte order） - server 接收时：先读 4 字节，再按该长度读 payload，最后用
cereal::BinaryInputArchive反序列化 - 超时靠
boost::asio::steady_timer+cancel()配合：timer 触发时主动 close socket，触发 async_read 的 error_code ==boost::asio::error::operation_aborted
关键点：async_read 必须配合 boost::asio::dynamic_buffer 或预分配 buffer，否则无法处理变长消息；cereal 的 binary archive 对齐敏感，client/server 编译器/平台需一致（比如都用 little-endian）。
立即学习“C++免费学习笔记（深入）”；
如何让 server 支持多方法注册而不写 if-else？
用 std::unordered_map<:string std::function request response>> 存方法分发表。但注意：cereal 本身不携带类型名，所以你需要在 request 结构里加一个 std::string method_name 字段，或者用 enum + switch（更安全）。
- 推荐用 enum：避免字符串拼错、无编译检查；序列化时用
CEREAL_ENUM宏 - 每个 handler 函数必须捕获异常并写入
Response::success = false，否则 server 会 crash - handler 内不要阻塞，如需 IO，请用 asio 异步操作并把结果通过
post回原 io_context
最易被忽略的是内存生命周期：cereal 反序列化出的对象只在 handler 栈上存在，不能存裸指针、不能跨 async callback 引用其成员。response 对象必须由 handler 全权 new/delete 或用 value semantics 传递。
