最稳妥的行数统计方法是用 std::getline 逐行读取，它自动处理 \r\n、BOM 和末行无换行符等情况；需检查文件是否成功打开，循环中用 getline 成功则计数加一，失败时区分 EOF 与异常；对超大文件可优化为逐字节或批量读取统计换行符。
用 std::getline 逐行读取最稳妥
直接用 fseek + ftell 统计换行符容易出错，尤其文件含 \r\n、BOM 或最后一行无换行符时。C++ 标准库推荐方式是靠 std::getline 实际读取——它自动处理不同平台换行，且不依赖字符编码假设。
实操建议：
- 用
std::ifstream打开文件，检查.is_open()，避免空文件或权限错误导致行数为 0 却无提示 - 循环调用
std::getline，每次成功即++line_count；失败时需区分「读到 EOF」和「读取异常」（如磁盘错误），后者应检查!ifs.fail()而非只看eof() - 若文件极大（>100MB），别把整行存进
std::string再丢弃——用临时std::string对象，让移动语义或短字符串优化减少分配开销
int count_lines(const std::string& path) {
std::ifstream ifs(path);
if (!ifs.is_open()) return -1;
std::string line;
int n = 0;
while (std::getline(ifs, line)) ++n;
return n;
}
Windows 下 \r\n 不影响 std::getline 计数
std::getline 默认以 \n 为分隔符，但在文本模式下（默认），C++ 运行时会自动将 \r\n 视作单个换行，不会多算一行。这点和手动扫描 \n 字符完全不同。
注意陷阱：
立即学习“C++免费学习笔记（深入）”；
- 若用二进制模式打开（
std::ios::binary），\r\n就变成两个字符，std::getline仍只认\n，但前导\r会留在上一行末尾——此时行数没错，但内容脏了 - UTF-8 BOM（
\xEF\xBB\xBF）不影响行计数，因为 BOM 在首行开头，std::getline读第一行时照常吞掉换行符，BOM 只是字符串开头几个字节 - Linux 文件在 Windows 上用记事本另存过，可能混入孤立
\r，这时std::getline会把\r当普通字符，不触发换行——行数依然准确，只是某行末尾多出\r
想快一点？别用 std::getline 读完整行
如果只关心行数，不关心内容，可以跳过解析整行：用 std::istream::get() 逐字节读，只统计 \n（和可选的 \r\n 逻辑）。速度能提升 2–3 倍，尤其对宽字符或长行文件。
但必须手动处理换行差异：
- 跨平台安全做法：遇到
\r时，peek 下一个字符，如果是\n就跳过并计 1 行；否则只计 1 行（兼容 Mac\r旧格式） - 不要假设文件是文本——二进制文件里随机出现
\n也会被当换行，这属于预期行为，不是 bug - 用
std::istream::readsome或read批量读缓冲区（如 8KB），比单字节 get 快得多；记得处理缓冲区末尾的截断换行（如最后字节是\r，下一批开头是\n）
大文件别用 std::filesystem::file_size 估算行数
有人试过用文件字节数除以平均行宽来“预估”行数，这完全不可靠。代码注释长度、空行、超长日志行、混合中英文宽度都会让误差超过 ±50%。更糟的是，std::filesystem::file_size 在某些 NFS 或容器挂载路径下可能抛异常或返回 0。
真实场景该怎么做：
- 如果必须快速反馈（比如进度条），先用
stat或std::filesystem::file_size获取总大小，再流式读取同时更新“已读字节数 / 总字节数 × 预估总行数”，但最终行数仍以getline实际计数为准 - 对 >1GB 的日志文件，考虑用内存映射（
mmapon Linux /CreateFileMappingon Windows）+ 手动指针扫描\n，避开 iostream 的锁和缓冲开销 - 别在主线程里同步读大文件统计行数——用户点击“加载”就卡住 5 秒，体验比没数字还差
std::ifstream 默认按本地 locale 解码，遇到非法 UTF-8 字节序列可能使 getline 提前失败。真要健壮，得用无 locale 的二进制读 + 自己判断换行，或者引入 std::codecvt_utf8（C++17 已弃用）这类麻烦货——多数情况，接受“非 UTF-8 文件可能少计几行”，比硬扛编码问题更务实。 
