in_avail() 返回0或负值是正常行为，因其仅报告缓冲区中已就绪可无阻塞读取的字节数，而非文件总长度；需用seekg(0, ios::end)配合tellg()获取真实大小。
为什么 rdbuf()->in_avail() 经常返回 0 或负值
这不是 bug，而是 in_avail() 的语义限制：它只报告**输入缓冲区中当前已就绪、可无阻塞读取的字节数**，不等于文件剩余长度，也不保证后续 read() 或 >> 一定能读到这么多。底层依赖流缓冲区（std::streambuf）是否已预加载数据——比如用 std::ifstream 打开文件后未做任何读操作，缓冲区通常是空的，in_avail() 就返回 0；若之前已触发过读取（如 get()、peek()），部分数据可能已在缓冲区，此时才可能返回正值。
in_avail() 在不同打开模式下的行为差异
关键看是否启用缓冲及缓冲策略：
-
std::ifstream f("a.txt");— 默认带缓冲，但初始in_avail()仍为 0，除非先调用peek()或sgetc()触发底层填充 -
std::ifstream f("a.txt", std::ios::binary);— 二进制模式不影响in_avail()逻辑，仅改变换行符处理 -
f.rdbuf()->pubsetbuf(nullptr, 0);— 禁用缓冲后，in_avail()几乎总返回 0（无缓冲区可查） - 对
std::cin调用in_avail()— 可能返回 0 即使终端有输入，因标准输入通常行缓冲且未回车前不提交
想真正获取文件总长度？别用 in_avail()，改用 seekg(0, std::ios::end)
in_avail() 不是文件长度接口，它的设计目标是辅助“试探性读取”，比如非阻塞检查是否有数据可立即消费。要获取文件大小，必须绕过缓冲区直接查文件系统：
std::ifstream f("data.bin", std::ios::binary);
if (f) {
f.seekg(0, std::ios::end);
std::streampos size = f.tellg(); // 这才是真实字节数
f.seekg(0, std::ios::beg);
}
注意：tellg() 在文本模式下对含 \r\n 换行的文件可能与字节长度不一致，务必用 std::ios::binary 模式。
立即学习“C++免费学习笔记（深入）”；
实际调试时怎么观察 in_avail() 的变化
最可靠的方式是配合 peek() 触发缓冲区填充，再查值：
std::ifstream f("test.txt");
std::cout << f.rdbuf()->in_avail() << "\n"; // 通常 0
f.peek(); // 强制从文件读至少 1 字节进缓冲区
std::cout << f.rdbuf()->in_avail() << "\n"; // 可能 > 0，取决于缓冲区大小（通常 8192）
但要注意：in_avail() 返回值受 libc 实现影响（如 libstdc++ 和 libc++ 缓冲策略不同），且多线程下不安全——同一 streambuf 被多个流共享时结果不可预测。
in_avail() 的不可靠性远大于便利性；文件长度走 seekg/tellg，实时可用数据量不如直接 read() 并检查 gcount() ——底层细节藏得深，暴露出来的接口从来不是万能钥匙。 
