cin.clear()仅重置错误标志，不清理输入缓冲区；必须配合cin.ignore()（如cin.ignore(numeric_limits<streamsize>::max(), '\n')）才能清除残留字符并恢复正常输入。
cin.clear() 只是重置错误状态，不清理缓冲区
很多人以为 cin.clear() 能“清空输入”，结果发现输错后连续调用 cin >> x 还是立刻失败——因为 cin.clear() 只把 failbit 或 badbit 清掉，缓冲区里残留的非法字符（比如字母卡在数字输入前）根本没动。
典型现象：cin >> num 输入 abc 后失败，再调 cin.clear() 然后又 cin >> num，依然失败，且不等待新输入。
-
cin.clear()必须配合cin.ignore()才算真正“恢复输入” - 只调
cin.clear()是半截操作，就像拧开瓶盖却不倒水 - 如果之前是
cin.fail()导致的阻塞，不清缓冲区，下次读取会立刻再次失败
用 cin.ignore() 跳过缓冲区残留字符
cin.ignore() 才是真正处理缓冲区的函数。它默认跳过 1 个字符，但实际几乎总是要跳过“直到换行符为止”的所有内容，否则残留的 \n 会影响后续 getline()。
常见写法：
立即学习“C++免费学习笔记（深入）”；
cin.clear(); cin.ignore(numeric_limits<streamsize>::max(), '\n');
-
numeric_limits<streamsize>::max()表示“尽可能多”，不是字面最大值，而是流能接受的最大计数 - 第二个参数
'\n'是定界符：遇到换行就停，避免无限阻塞（哪怕缓冲区真有上万字符） - 如果确定只需丢弃一个非法字符（如单个字母），可写
cin.ignore(1)，但极少适用 - 注意头文件：
#include <limits>不可少，否则numeric_limits报错
混合使用 >> 和 getline() 时缓冲区最易出问题
这是最常踩坑的场景：先用 cin >> x 读整数，再用 getline(cin, s) 读一行字符串，结果 s 直接为空——因为 >> 留下了 \n，getline() 遇到它立刻返回。
这不是 bug，是设计行为：>> 跳过开头空白，但停在第一个非数字字符（含 \n）前；getline() 则从当前位置开始读，碰到 \n 就结束。
- 只要用了
>>，之后紧跟getline()前必须插一次cin.ignore() - 哪怕前面没出错，也要清掉那个残留的
\n，否则getline()拿不到用户真实输入 - 别依赖
cin.sync()：它在标准中未定义行为，GCC/Clang 可能清缓冲区，MSVC 常无效，已不推荐
cin.peek() 和 cin.gcount() 可帮你确认缓冲区状态
调试时不确定缓冲区里还有啥？cin.peek() 能看下一个字符（不提取），cin.gcount() 能查上次 ignore() 或 read() 实际跳过了多少字符。
例如：
cin.clear();
cin.ignore(numeric_limits<streamsize>::max(), '\n');
cout << "ignored " << cin.gcount() << " chars\n";
if (cin.peek() != EOF && cin.peek() != '\n') {
cout << "still has: '" << (char)cin.peek() << "'\n";
}
-
cin.peek()返回int，EOF 时为EOF，否则是字符 ASCII 值，记得转char才好观察 -
cin.gcount()只对ignore()、read()、getline()等有计数的函数有效，clear()不影响它 - 生产代码不用检查这些，但调试输入逻辑混乱时，它们比加断点更快定位残留字符位置
ignore() 或传错参数，问题就会在下一次读取时突然冒出来——而且往往不在出错的那一行。 
