最可靠方法是二进制模式扫描前1–2KB内换行符前字节：遇\r\n记CRLF，遇孤立\n记LF，取前5个换行中多数类型；无换行则按平台fallback。
怎么判断文件里用的是 \r\n 还是 \n
直接读前几个换行位置的字节最可靠，别依赖文件扩展名或系统默认值。Windows 上新建的文本文件大概率是 \r\n，Linux/macOS 一般是 \n，但用户手动改过、跨平台传输过、编辑器设过“Unix 换行”就完全不可信。
实操建议：
- 打开文件为二进制模式（
std::ios::binary），避免std::getline自动吃掉\r导致误判 - 扫描前 1–2KB 内所有
\n前一个字节：如果是\r，记一次 CRLF；如果是其他字节（或开头就是\n），记一次 LF - 遇到第一个完整换行就停——多数情况下前几行已足够判断，不用扫全文件
- 如果没找到换行符（比如单行纯文本），按目标平台默认值 fallback，比如 Windows 用
\r\n，其余用\n
std::getline 为啥读不到 \r，还能不能用
它默认把 \r\n 当作一个换行处理，丢掉 \r 只留 \n 作为分隔符边界，所以你永远拿不到原始的 \r\n 字节序列。这不是 bug，是标准行为。
如果你只是想逐行处理内容，std::getline 完全够用；但如果你想保留原始换行符、做格式转换、或验证文件一致性，就不能靠它。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 要保留换行符原样：用
std::istream::read或std::istream::get逐字节读，自己识别\r\n/\n - 要兼容两种换行并统一处理：先用上面方法探测类型，再用
std::getline读取，最后按需补回\r - 注意
std::getline在不同 locale 下对\r的处理一致，不依赖本地化设置
探测逻辑写成函数，要注意哪些边界情况
真实文件里可能混用换行符，比如 Git checkout 后 Windows 文件在 WSL 里被改了一行，或者日志拼接时出错。不能只看第一个换行就下结论。
实操建议：
- 至少检查前 5 个换行位置（不是前 5 行，是前 5 次
\n出现的位置） - 如果发现
\r\n和\n同时存在，优先按多数派判断；若平票，选第一个出现的类型 - 跳过空行和纯空白行（只含
\r、\n、\t、 - 读到 EOF 前没找到任何
\n？返回unknown枚举值，由调用方决定 fallback 策略
用 fopen + fgets 会更简单吗
不会。C 风格 IO 在文本模式下同样会把 \r\n 映射成 \n，且 fgets 会把 \n 保留在缓冲区里，行为反而更难预测。二进制模式下倒是能拿到原始字节，但你要自己处理缓冲区、长度截断、重叠读等问题，比 C++ 流还容易出错。
实操建议：
- 坚持用 C++ 流 + 二进制模式 +
peek()/get()组合，控制力强、异常安全、无需手动管理内存 - 别为了“少写几行”换成 C API，换来的是隐式转换、无符号 char 陷阱、和
feof判定时机的经典坑 - 如果项目已重度使用 Boost，
boost::iostreams::mapped_file_source可直接内存映射，随机访问换行位置更快，但小文件没必要
真正麻烦的不是第一次探测，而是后续写入时要不要保持原换行风格——很多人只读不写，就忽略了写回时该用哪种换行符。这个决策点一旦漏掉，跨平台协作时 diff 会炸出几百行无意义变更。
