优先用std::getline配std::string，cin.getline仅用于char[]；前者无溢出风险，后者需注意size为数组总长且留\0，混用会编译失败，cin>>后需cin.ignore()清理换行符。
用 std::getline 还是 cin.getline，取决于你存到哪
选哪个根本不用“权衡”，只看变量类型：std::getline 必须配 std::string，cin.getline 只能配 char[] 或 char*。混用会编译失败。
常见错误现象：
-
cin.getline(str, 20)传入std::string str→ 编译报错：no matching function -
getline(cin, buf)传入char buf[100]→ 同样编译失败，因为没重载该组合
所以第一步不是查文档，而是看手头的变量声明：
- 写的是
std::string name;→ 无条件用getline(cin, name) - 写的是
char name[64];→ 只能用cin.getline(name, 64)
cin.getline 的缓冲区长度参数容易算错
cin.getline(buf, size) 的 size 是整个数组大小，不是“最多读几个字符”。它最多读 size - 1 个有效字符，末尾自动补 \0。
立即学习“C++免费学习笔记（深入）”；
比如：
-
char buf[10]; cin.getline(buf, 10);→ 实际最多存 9 个字符 + 1 个\0 - 如果用户输入 12 个字符，前 9 个进
buf，第 10 位是\0，剩下 2 个（含换行符）留在输入流里 → 后续读取可能直接拿到空行或错乱数据
这不是 bug，是设计行为。但后果严重：缓冲区溢出风险低了（不会越界写），可残留数据会导致逻辑错乱，尤其在循环读取时。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
混合使用 cin >> 和 getline 时，换行符残留是高频坑
cin >> 遇到空格/换行就停，但不取走换行符；而 getline（无论哪个）一上来就找换行符——如果上一个 cin >> 留了个 \n 在缓冲区，getline 会立刻读到空行。
典型场景：
-
int age; cin >> age;→ 用户输25\n，age得到 25，\n还在缓冲区 - 紧接着
getline(cin, name);→ 立刻读到空字符串，name为空
修复方式统一且简单：cin >> age; cin.ignore();。不需要改用 cin.get() 或别的函数。cin.ignore() 默认跳过 1 个字符（刚好是那个残留的 \n）。
性能和安全：优先用 std::getline，除非有明确 C 兼容需求
std::getline 内部动态扩容，无缓冲区溢出风险，语义清晰，现代 C++ 推荐路径。它的开销几乎可以忽略——一次堆分配（后续复用）远小于手动管理 char[] 带来的维护成本和出错概率。
cin.getline 唯一合理使用场景是：
- 对接 C API（如
fopen、printf）必须传char* - 嵌入式等极端内存受限环境，需严格控制栈空间（但此时更该考虑是否真该用 C++）
- 已有大量遗留代码基于
char[]，短期无法重构
除此之外，硬写 cin.getline 就是给自己埋雷：长度算错、残留数据、类型不匹配，三者任一都可能让程序在某个输入下静默失败。
