std::streambuf派生类必须重写underflow()和seekoff()/seekpos()（若需seekg），建议实现uflow()和showmanyc()；构造时须关联文件句柄，析构须显式释放资源，否则读取失败或资源泄漏。
std::streambuf 派生类必须重写哪些虚函数才能让 std::ifstream 正常读取
只重写 underflow() 不够，std::basic_filebuf 的行为依赖多个虚函数协同。不补全关键函数，流会静默失败或卡死。
-
underflow()：必须实现，提供至少 1 字节数据（返回traits_type::not_eof()对应的字符），否则get()、>>等操作直接返回 EOF -
uflow()：建议实现，否则每次读单字节都会反复调用underflow()，性能差；它负责“消费并返回”，应推进内部指针 -
showmanyc()：可选但强烈建议，返回当前缓冲区可用字节数；若返回 -1（默认），readsome()和部分getline()行为异常 - 不要碰
overflow()或sputn()—— 这是输出方向，对只读文件流无意义，误实现反而触发未定义行为
用 rdbuf() 替换后，为什么 is_open() 返回 true 但 read() 读不到任何数据
常见原因是派生 std::streambuf 的构造/初始化没关联底层文件，或 underflow() 始终返回 traits_type::eof()。
- 检查构造函数：是否调用了
open()或手动mmap()/fopen()并保存了有效句柄；C++20 前不能依赖std::filebuf的私有成员 - 调试
underflow()：在开头加日志，确认是否被调用、返回值是否为有效字符（如(unsigned char)'A'），不是traits_type::eof() - 注意 locale 影响：如果自定义
std::codecvt或绑定了非默认 facet，imbue()后可能拦截读取路径，绕过你的underflow() - 避免在
underflow()中抛异常 —— 标准流不保证异常安全，多数情况转为设置failbit，后续操作直接跳过
自定义 streambuf 在 std::ifstream 中如何支持 seekg() 和 tellg()
默认不支持，因为 seekoff() 和 seekpos() 是空实现（返回 pos_type(off_type(-1))）。要支持定位，必须重写这两个函数，并维护内部偏移状态。
-
seekoff(off_type off, std::ios_base::seekdir way, std::ios_base::openmode = std::ios_base::in)：根据way（beg/cur/end）计算目标位置，更新内部读取指针；返回新位置，失败返回pos_type(off_type(-1)) -
seekpos(pos_type sp, std::ios_base::openmode = std::ios_base::in)：直接跳转到绝对位置sp，通常只需转换sp并调用seekoff() - 关键点：所有读取逻辑（
underflow()等）必须基于当前内部偏移，而不是固定从头开始；若底层是内存映射，lseek()可能无效，得用指针算术 - 注意线程安全：标准流本身不保证多线程读取安全，自定义
streambuf若共享状态（如全局偏移变量），需加锁或用thread_local
std::streambuf 子类里缓存区大小和分配方式对性能的实际影响
缓冲区不是越大越好，也不是越小越灵活；实际吞吐量取决于 I/O 模式和系统页大小。
立即学习“C++免费学习笔记（深入）”；
- 小于 4KB（典型页大小）：频繁触发
underflow()，函数调用开销主导，尤其在小块读取（如逐行解析）时明显拖慢 - 4KB–64KB：多数场景最优，平衡系统调用次数与内存占用；Linux
read()在此范围有良好预读行为 - 超过 1MB：内存分配可能失败（尤其嵌入式或限制 RLIMIT_AS）；且大缓冲区导致
seekg()后丢弃大量已读数据，浪费带宽 - 避免
new char[N]：优先用std::vector<char></char>或静态数组（若大小编译期可知），防止异常时streambuf析构不清理 - 别忘了重写
setbuf(char*, std::streamsize)：虽然标准库很少调用，但某些平台（如 MSVC）在tie()或sync_with_stdio()时会试探性调用，留空实现可避免意外覆盖缓冲区
最易被忽略的是：自定义 streambuf 的析构函数必须显式关闭文件句柄或释放 mmap 区域 —— std::ifstream 的析构只调用 rdbuf()->pubsync()，不负责资源回收。
