不能直接用 std::string 传结构体，因结构体含指针、虚表、对齐差异、大小端不一致，需序列化为跨平台中间格式（如 Protobuf）；手写协议须用固定宽类型、长度前缀字符串、magic+version 校验。
为什么不能直接用 std::string 传结构体
很多初学者尝试把 C++ 结构体对象直接 reinterpret_cast 发给 socket，结果在另一端读出来全是乱码或崩溃。这不是传输问题，而是序列化缺失：结构体可能含指针、虚函数表、字节对齐差异、平台大小端不一致。二进制内存布局 ≠ 可跨进程/跨机器传输的数据格式。必须先转成与语言、平台、编译器无关的中间表示，比如 Protocol Buffers 的 .proto 编码，或手写紧凑二进制协议。
用 protobuf + socket 实现最小 RPC 调用流程
跳过所有框架封装，只保留最核心三步：序列化请求 → 发送 → 反序列化响应。关键不是“怎么写服务端”，而是“怎么让调用看起来像本地函数”。例如定义一个 CalculateRequest 和 CalculateResponse，客户端填好字段，发过去，等回包解析。
- 先写
calc.proto，用protoc --cpp_out=. calc.proto生成calc.pb.h和calc.pb.cc - 客户端构造
CalculateRequest req，调用req.SerializeAsString()得到std::string字节流 - 发送前加 4 字节小端长度头（
htonl(len)），避免粘包；服务端先 recv 4 字节，再按长度 recv 完整 body - 服务端用
CalculateRequest::ParseFromString()解析，计算后填CalculateResponse并同样带长度头返回
// 示例：发送带长度头的 protobuf 消息
void send_protobuf(int sock, const google::protobuf::Message& msg) {
std::string data;
msg.SerializeToString(&data);
uint32_t len = htonl(data.size());
send(sock, (char*)&len, 4, 0);
send(sock, data.c_str(), data.size(), 0);
}
std::memcpy 直接拷贝结构体的风险点
即使你确认两端结构体定义完全一致、用相同编译器和 ABI，仍可能出错：
-
#pragma pack(1)忘了加，导致 struct 在 x86_64 上默认 8 字节对齐，但网络字节流是紧凑排列 - 成员含
std::string或std::vector—— 它们内部是堆地址，memcpy 只复制指针，对方解包即野指针 - Windows vs Linux 下
time_t是 4 字节还是 8 字节？long在不同平台宽度不同 - 没有版本兼容机制：v1 协议加了个字段，v2 客户端发过来，v1 服务端反序列化失败或静默截断
不用第三方库时，手写二进制协议要注意什么
如果坚持不用 protobuf、capnproto 等，至少保证以下底线：
立即学习“C++免费学习笔记（深入）”；
- 所有整数字段显式用固定宽类型：
int32_t、uint64_t，绝不用int或size_t - 字符串统一用“长度前缀 + UTF-8 字节”方式编码，长度本身用
uint16_t（小端） - 每个消息开头放 1 字节 magic number（如
0xCA）和 1 字节 version，便于快速识别非法数据或协议升级 - 接收端必须做完整校验：magic 正确 → version 支持 → 长度在合理范围（防放大攻击）→ 实际 recv 字节数匹配
RPC 不是拼功能，是控边界。真正难的从来不是“怎么调通”，而是“对方进程崩溃、网络中断、序列化失败、字段被删”时，你的调用逻辑是否不崩、可诊断、能降级。
