unget() 失败了？别急着重写逻辑，先看 failbit 是怎么悄悄“放回失败”的

你有没有试过在 C++ 里用 std::istream::unget() 把刚读进来的字符“吐回去”，结果下一次 get() 却读到了意料之外的值？更诡异的是，流状态没报错，fail() 返回 false，可行为就是不对——字符没放回去，或者只放回去一半，甚至 unget() 后再 peek() 还是返回 EOF。这不是你的代码有 bug，而是 unget() 的“放回”本身就有隐性前提：它不是总能成功，而失败时，它默认不抛异常、不打印日志，只默默置位 failbit。

这恰恰是 pbackfail 被多数人忽略的真相：它不是 unget() 的底层实现细节，而是流缓冲区（std::streambuf）在“放回字符”操作真正卡壳时的最后一道防线。理解它，不是为了手写 streambuf 子类，而是为了读懂 unget() 为什么“突然不灵了”。

unget() 的行为其实分三步走：

1. 先查缓存区是否还有“放回槽”（通常是 1 字节的 putback buffer）；
2. *若有空位，直接塞进去，返回 `this`；**
3. 若没空位，才调用底层 rdbuf()->sputbackc(c)，后者最终可能触发 pbackfail(c)。

关键就卡在第三步。pbackfail 是 streambuf 的虚函数，标准库实现（比如 libstdc++ 或 libc++）通常会这样处理：

• 若当前 get area（读取区）尚未耗尽，且 c 恰好等于上一个已读字符（即“回退一步”合法），就把它塞回 gptr()-1；
• 否则，直接返回 EOF，并由 sputbackc 设置 failbit。

所以，“放回失败”从来不是随机事件——它往往暴露了你对输入流状态的误判。

最常见的三个“踩坑现场”：

场景一：连续 unget() 超过 1 次
C++ 标准只要求 unget() 至少支持 1 字节回退。哪怕你看到某编译器允许连 unget() 三次，那也只是实现红利，不可移植。一旦第二次 unget() 触发 pbackfail，流进入 failbit 状态，后续所有格式化输入（如 >>）都会跳过——但 get() 和 peek() 仍可能返回值，造成“看似正常实则失效”的假象。解决方法不是加 clear()，而是从设计上避免嵌套回退：用临时变量暂存字符，而非依赖多次 unget()。

场景二：从文件流读到末尾后强行 unget()
比如 ifstream f("data.txt"); char c = f.get(); // 读到 EOF，此时 f.unget() 必定失败。因为 gptr() == egptr()，缓冲区已空，pbackfail 无处可放。有人会写 if (f) f.unget();，但 f 的 operator bool() 检查的是 !fail()，而 unget() 失败前流还是“好”的——必须在 unget() 后立刻检查 if (!f)，而不是之前。

场景三：自定义 streambuf 未重载 pbackfail
如果你继承 std::streambuf 并重写了 underflow()，却忘了覆盖 pbackfail()，那么默认实现几乎总是返回 EOF。这时 unget() 表面调用成功，实际什么也没放回去。调试时不要只盯 unget() 返回值，要抓 rdbuf()->sputbackc(c) 的返回值——它才是 pbackfail 的直系出口。

那么，如何写出真正鲁棒的“可回退解析”逻辑？

第一，放弃“试探-回退”式写法。例如解析数字时，别写：

char c = is.peek();
if (isdigit(c)) {
    is.unget(); // 危险！peek 不消耗字符，但 unget 假设已 get
    is >> num;
}

peek() 不移动读指针，unget() 却试图把“还没读过的字符”放回去——这本身就是未定义行为的温床。正确做法是先 get()，再根据需要决定是否继续：

int c = is.get();
if (std::isdigit(c)) {
    is.putback(c); // 注意：putback 更安全，语义明确，且对单字节回退有更强保证
    is >> num;
} else {
    is.putback(c); // 即使不匹配，也要归还
}

第二，接受 unget()/putback() 的局限性。它们本质是“流状态的轻量级修补”，不是事务回滚。真正需要多步回退的场景（比如词法分析中的长匹配），应该用 std::string 缓存已读内容，用索引控制“逻辑位置”，而非依赖流自身的放回机制。

第三，调试时打开流的状态开关。std::cerr << "state: " << is.rdstate() << std::endl; 中的 ios_base::failbit 值为 4，badbit 为 2——unget() 失败只会设 failbit，不会动 badbit。 如果你发现 failbit 被置位却找不到原因，八成是某处 unget() 在缓冲区满或 EOF 时静默失败了。

pbackfail 不是一个待你征服的技术难点，而是一面镜子——照出我们常把流想象成“无限可逆”的惯性思维。C++ 的 I/O 设计始终带着系统级的克制：缓冲区大小有限、系统调用开销真实、EOF 是不可逾越的边界。理解 pbackfail，不是为了绕过它，而是学会在它的规则内，用更确定的方式组织输入逻辑。

下次 unget() 不按预期工作时，别急着翻文档找替代方案。停下来，is.clear() 之前先 std::cerr << is.rdstate()，看看 failbit 是什么时候亮起来的。那个瞬间，往往藏着你对数据流最真实的误解。