不能直接继承 std::streambuf 做“虚文件”，因其仅提供 underflow()/overflow() 等底层I/O操作，缺失 open/close/seek/stat 等文件语义，需自行实现 seekoff()（区分读写位置与 end 语义）、xsputn() 回退机制等，否则导致读取为空、seek 失败等问题。
为什么不能直接继承 std::streambuf 做“虚文件”？
因为 std::streambuf 的虚函数接口设计极度精简，只暴露 underflow()、overflow()、sputn()、sgetn() 等底层操作，没有 open/close/seek/stat 等文件语义。所谓“内存模拟文件”，本质是你得自己补全这些行为——不是流缓冲区在模拟文件，而是你用缓冲区搭出一个能被 std::istream/std::ostream 消费的“假文件端点”。
常见错误现象：std::ifstream 构造时传入自定义 std::streambuf* 后读取为空、peek() 返回 EOF、seekg() 失败返回 -1。
- 根本原因：没重写
seekoff()和seekpos()，导致流位置不可控 -
showmanyc()返回负值或 0，会让流误判“无数据可读” - 未处理
xsputn()中n == 0或缓冲区满时的 fallback 行为，写入静默失败
std::streambuf::seekoff() 怎么写才不崩？
这是内存模拟文件最常翻车的点：C++ 标准对 seekoff() 的调用上下文很敏感，尤其当流处于 std::ios_base::in | std::ios_base::out 混合模式时，way 参数可能是 std::ios_base::beg、end 或 cur，而 which 可能是 std::ios_base::in、out 或两者（std::ios_base::in | std::ios_base::out）。
实操建议：
- 必须区分
which & std::ios_base::in和which & std::ios_base::out，分别维护读位置和写位置（即使底层共用同一块内存） -
std::ios_base::end的偏移要基于“逻辑文件大小”，不是当前缓冲区容量；比如你用std::vector存数据，文件大小是data.size()，不是data.capacity() - 返回值必须是新位置（成功）或
off_type(-1)（失败），不能返回 0 当作失败 - 如果支持随机写，
seekoff(0, std::ios_base::cur, std::ios_base::out)必须能返回当前写位置，否则ostream::tellp()会错
如何让 std::ifstream 和 std::ofstream 都能用你的缓冲区？
别试图用一个 streambuf 实例同时喂给 ifstream 和 ofstream——它们内部缓存策略不同，ifstream 默认只读，ofstream 默认只写，且构造后会调用 pubsetbuf(nullptr, 0) 清空缓冲区，导致你的自定义缓冲区被绕过。
正确做法是按使用场景拆开：
- 只读场景：继承
std::streambuf，重写underflow()和seekoff()（in分支），用std::istream is{&my_buf}初始化 - 只写场景：重写
overflow()、xsputn()和seekoff()（out分支），用std::ostream os{&my_buf} - 读写同存：必须支持双缓冲（read area / write area 分离），且
seekoff()要同步更新两个位置；std::fstream构造时传入缓冲区指针后，务必调用is.open(..., std::ios_base::in | std::ios_base::out)显式声明模式
性能影响：每次 seekoff() 都触发缓冲区重置（setg()/setp()），频繁 seek 会显著拖慢；若业务允许，预分配足够大的内存并避免反复 realloc 更稳。
为什么 std::stringbuf 不适合做“内存文件”？
std::stringbuf 是标准库提供的内存缓冲区，但它定位是“字符串序列的临时载体”，不是“文件抽象”。它不支持 seekoff() 对 std::ios_base::end 的语义（seekoff(0, std::ios_base::end) 返回的是缓冲区当前长度，而非“文件末尾”），也不保证 sgetn() 和 sputn() 的原子性与边界检查一致性。
容易踩的坑：
- 用
std::stringbuf+std::iostream后调seekg(0, std::ios_base::end)，再tellg()得到的值可能比实际数据少 1（因内部 null terminator 计入） -
str()返回的是拷贝，无法反映后续流操作对底层内存的修改 - 不支持 mmap-style 的零拷贝视图；所有读写都经过 string 内部的
std::char_traits拷贝路径
真要快速验证逻辑，可用 std::stringbuf 起步，但上线前必须换成手写 streambuf 子类——尤其是 seek、size、并发访问这三点，标准实现根本不为你负责。
底层细节藏得深：比如 std::streambuf::in_avail() 的返回值会影响 getline() 是否提前结束，而它的默认实现依赖 egptr() - gptr()，你得确保 underflow() 调用后 gptr() 和 egptr() 正确对齐，否则一行读半截就停了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
