根本原因是未正确重载underflow()和overflow()且忽略setg()/setp()初始化：构造时需用setg()设输入三指针，underflow()返回eof()而非留空，overflow()对eof()做flush处理；读写缓冲区须分离，sync()统一提交状态；禁用拷贝并确保缓冲区内存生命周期长于stream实例。
为什么直接继承 std::streambuf 容易读写错位或返回 -1？
根本原因是没正确重载 underflow() 和 overflow()，且忽略了 setg()/setp() 对内部指针的初始化逻辑。标准流在构造后默认不预设缓冲区，sgetc()、sputn() 等函数会触发虚函数调用，但若 egptr() ≤ gptr() 或 pptr() ≥ epptr()，就会立即返回 EOF（-1）或丢弃数据。
常见错误现象：std::istream 构造后调用 >> 读不出任何内容；std::ostream 写入后缓冲区无变化；str() 返回空字符串。
- 必须在派生类构造时用
setg()显式设置输入缓冲区三指针（gbeg,gcurr,gend），哪怕只支持输出 - 仅支持只写流时，
underflow()必须返回traits_type::eof()，不能留空或抛异常 -
overflow(int c)中若c == traits_type::eof()表示 flush，此时应忽略或同步底层（如 memcpy 到目标 buffer）
如何让自定义 streambuf 同时支持读写且不冲突？
关键在于分离输入/输出缓冲区指针，并在 sync() 中统一提交状态。不要复用同一块内存做双工缓冲——std::streambuf 的 g/p 指针体系天然倾向单向缓冲，强行共享极易因 seekoff() 或 xsputn() 调用导致指针越界。
典型使用场景：将一段 std::vector<char> 封装为可读可写的流，用于单元测试中模拟文件 I/O 或协议编解码中间态。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 输入缓冲区（
setg(buf, buf, buf + size)）只用于sgetn()类读操作，gptr()移动即消费 - 输出缓冲区（
setp(buf, buf + size)）只用于sputn()类写操作，pptr()移动即生产 -
sync()不必刷新到外部设备，但需更新已写入长度（如记录pptr() - pbase()），供后续size()或data()方法使用 - 若需随机访问，重载
seekoff()并维护一个独立的偏移量变量，而不是依赖gptr()/pptr()
std::istream 绑定后调用 rdbuf() 读不到数据？检查 in_avail() 返回值
in_avail() 返回的是当前输入缓冲区中“已加载且未消费”的字符数，不是底层 buffer 总长度。如果派生类没在构造或 underflow() 中填充缓冲区（即没调用 setg() 更新 gptr()），它永远返回 0，>> 运算符就会跳过缓冲直奔 uflow()——而你的 uflow() 若又没正确实现，就读不到东西。
性能影响：每次 in_avail() 调用都会触发 showmanyc()（默认返回 -1），进而可能引发不必要的 underflow() 调用。所以建议在缓冲区就绪后显式调用一次 sbumpc() 或 sgetn() 来“激活”缓冲。
- 调试时加日志：在
underflow()开头打印gptr()、egptr()、in_avail() - 若底层是固定内存块，可在构造时一次性
setg(buf, buf, buf + len)，再在underflow()中只移动gptr()并检查边界 - 不要依赖
std::istream::peek()判断是否有数据——它内部也走in_avail()+sgetc()，同样受缓冲区初始化影响
如何避免 streambuf 派生类被误拷贝或生命周期错配？
std::streambuf 不可拷贝（禁用了拷贝构造/赋值），但它的派生类若没显式删除，编译器会生成默认拷贝函数，导致两个 stream 共享同一缓冲区指针，一读一写立刻 UB。更隐蔽的问题是：buffer 生命周期短于 stream ——比如用栈上 std::array<char, 1024> 初始化 streambuf，然后把 stream 传给异步回调，回调执行时 buffer 已析构。
- 在派生类中显式声明
streambuf(const streambuf&) = delete;和operator=(const streambuf&) = delete; - 缓冲区内存尽量用
std::vector<char>或std::unique_ptr<char[]>管理，绑定到派生类成员，而非裸指针 + 外部生命周期 - 若必须用裸指针（如对接 C API），在
sync()或析构中不释放内存，改由用户保证 buffer 存活时间 ≥ stream 实例 - VS2019+ / GCC11+ 下开启
-D_GLIBCXX_DEBUG或_GLIBCXX_DEBUG可捕获部分指针越界访问
最常被忽略的一点：派生类析构函数里必须确保 pubsync() 已调用，否则未 flush 的输出数据会静默丢失——这不是 bug，是标准规定的行为。
