直接说结论：用 std::getline 是 C++ 按行读取文本文件最可靠、最常用的方式，但必须注意流状态、换行符兼容性和编码边界问题。
为什么不能用 operator>> 代替 getline
operator>> 遇到空格、制表符或换行就停止，根本读不到完整一行；而 std::getline 默认以 'n' 为分隔符，能读取含空格的整行（不含换行符本身）。常见错误是混用两者后导致第一行“消失”——因为 operator>> 留下的换行符被下一次 getline 立即读作空行。
- 先调
cin >> x再调getline(cin, s)→s极大概率为空，需加cin.ignore() - 文件开头有 BOM（如 UTF-8 with BOM），
getline会把0xEF 0xBB 0xBF当作普通字符读入首行 -
getline不跳过前导空白，但operator>>会——这点常被误认为“getline有问题”
getline 的三个重载版本怎么选
实际开发中几乎只用两个：std::getline(std::istream&, std::String&) 和带分隔符的三参数版本。第三个（C 风格字符数组版）已基本淘汰，不安全且难控制缓冲区大小。
- 默认版：
std::getline(file, line)—— 适合绝大多数纯文本，自动处理n、rn（windows）和r（旧 mac） - 自定义分隔符：
std::getline(file, line, 't')—— 用于 TSV 解析，但注意它不会跳过连续分隔符，"attb"会读出空字符串 - 别用
std::getline(std::istream&, char*, int)：缓冲区溢出风险高，C++11 后无正当理由不用
读取循环里最容易忽略的流状态检查
while (getline(file, line)) 看似简洁，但掩盖了 EOF 和读取失败的区别。真正健壮的写法要区分：是文件结束？还是磁盘错误？还是编码损坏导致无法解析？
立即学习“C++免费学习笔记（深入）”；
-
getline成功时返回file（转为true），失败时设failbit或badbit - 循环结束后应检查
if (file.eof())判断是否正常结束，否则可能是file.fail()导致的异常中断 - UTF-8 文件含非法字节序列时，某些标准库实现（如 libstdc++）可能静默截断，而非报错——需额外验证
line是否包含孤立的0xC0–0xFF
跨平台换行与性能小陷阱
windows 下文本模式文件流会自动将 rn 转为 n，linux/macOS 下则原样保留。这通常没问题，但若你手动拼接字符串或做行号统计，要注意 r 可能残留在行尾（尤其从网络或剪贴板读入时）。
- 用
line.erase(std::remove(line.begin(), line.end(), 'r'), line.end())清理杂散r（仅当确定不需要保留时） - 频繁读小文件时，
std::string的反复分配会影响性能；可复用同一string对象，或预分配容量：line.reserve(1024) - 二进制模式打开文件（
ios::binary）后，getline仍可用，但不再自动转换换行符——此时rn会被当作两个字符，line末尾会多出r
真正麻烦的从来不是函数怎么调，而是你不知道它在什么情况下不按预期工作——比如 BOM、混合换行、流状态残留、编码异常，这些细节往往要等到线上日志乱码或某台机器上循环少读一行时才暴露出来。