iobuf 更安全因封装引用计数、内存生命周期与零拷贝拼接，避免 double free、use-after-free、数据覆盖及 malloc 压力；默认 1kb 预分配，clone() 增引用不拷贝，跨线程需 clone()。
为什么直接用 IOBuf 比自己管理 char* 缓冲区更安全
因为 IOBuf 把引用计数、内存生命周期、零拷贝拼接这些容易出错的逻辑全包了。你不用再纠结「这段内存谁 free」「这个指针是不是已经 dangling」「两个 buffer 合并要不要 memcpy」——它内部用链表 + 引用计数 + 可选的堆外内存池（如 NetworkSocketPool）来自动处理。
常见错误现象：double free、use-after-free、收到的数据被意外覆盖、小包频繁分配导致 malloc 压力大。这些问题在裸指针模式下几乎必然出现，尤其在异步网络回调里传 buffer 时。
- 每个
IOBuf节点默认带 1KB（可配置）预分配空间，避免小包反复申请 - 调用
clone()不复制数据，只增引用计数；pop()/trimStart()也不移动数据，只改偏移 - 跨线程传递前必须
clone()，否则其他线程可能提前reset()掉原始节点
IOBuf::create() 和 IOBuf::wrapBuffer() 怎么选
前者分配新内存并返回可写的 IOBuf；后者只是把已有 const void* 包一层只读视图，不接管内存所有权。
使用场景：收包时用 wrapBuffer() 把 socket recv() 返回的 char* 快速包成 IOBuf，避免拷贝；发包构造协议头/体时用 create() 或 createCombined() 分配可写空间。
-
wrapBuffer()的 buffer 如果是栈变量或生命周期短的堆内存，必须确保IOBuf生命周期不超过原 buffer -
create(1024)分配的内存由IOBuf管理，析构时自动free() - 想复用内存池？用
IOBuf::createWithPool()，但得先初始化folly::IOBufAllocator实例
拼接多个 IOBuf 时，prependChain() 和 appendChain() 的性能差异
两者都是 O(1) 链表拼接，不拷贝数据，但方向决定缓存友好性和后续读取效率。
典型场景：HTTP 头和 body 分两次到达，或者需要把 header + payload + trailer 组合成一个完整请求。如果先拿到 body 再补 header，用 prependChain() 更自然；反之用 appendChain()。
- 拼接后整个 chain 的
length()是各节点之和，但data()只返回第一个节点的起始地址 —— 所以别指望单指针遍历全部内容 - 想顺序访问所有数据？用
IOBuf::Iterator或coalesce()（注意：后者会触发 memcpy 合并到一块连续内存，慎用） - 避免深度嵌套 chain（比如上千个 1-byte 节点），会导致遍历变慢、元数据开销大；用
coalesceAsMuchAsPossible()控制合并粒度
从 IOBuf 提取数据给第三方库（如 protobuf、zlib）时的坑
第三方库通常要 const uint8_t* + size_t len，而 IOBuf 是链式的。不能直接传 buf->data() 和 buf->length()，除非你确定它是单节点（isChained() == false）。
错误现象：protobuf 解析失败、zlib 报 Z_DATA_ERROR、只读到第一个 chunk 的数据。
- 安全做法：先
buf->isChained() ? buf->coalesce() : buf，再取data()/length() - 追求零拷贝？传
IOBuf::Iterator给支持流式输入的库（如zlib-ng的deflateSetDictionary()变体），或自己实现分段 feed - 注意
coalesce()会分配新内存并 memcpy，如果 buffer 很大（几 MB），可能引发 minor GC 或延迟毛刺
真正麻烦的是跨模块边界传递 IOBuf：C++ 模块 A 生成的 IOBuf，传给模块 B 的 C 接口，B 又转给模块 C 的 Rust FFI —— 这时候引用计数和内存池对齐就很容易漏掉，建议在边界处明确 cloneAsValue() 或降级为 std::string。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
