读文件前必须手动跳过BOM，因C++标准库不处理它；std::ifstream和std::getline将其视为普通字节，导致解析静默失败，需用peek()和read()检测并跳过UTF-8/16的BOM。
读文件前必须手动跳过 BOM，C++ 标准库不处理它
C++ 的 std::ifstream 和 std::getline 完全无视 BOM —— 它就当普通字节读进来。如果你用 std::string 接收 UTF-8 文件开头的 \xEF\xBB\xBF，那第一个字符串会以这三个字节开头，后续所有解析（比如 std::stoi、== "key"）都可能静默失败。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 打开文件后立刻用
peek()或read()检查前 1–3 字节，比对常见 BOM：UTF-8（\xEF\xBB\xBF）、UTF-16 BE（\xFE\xFF）、UTF-16 LE（\xFF\xFE） - 不要依赖
std::codecvt_utf8—— 它在 C++17 被弃用，且不自动跳过 BOM - 如果用
std::wifstream，需显式调用imbue+std::locale并设置std::codecvt_utf16，但它仍不会跳 BOM，只是能解码后续内容
std::ifstream 读取时怎么安全跳过 UTF-8 BOM
最常用场景是读配置、日志、CSV 等纯文本，且你明确知道文件是 UTF-8 编码（但不确定有没有 BOM）。直接 ignore() 最保险。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
peek()查看第一个字节，避免移动读取位置出错：std::ifstream f("data.txt", std::ios::binary); if (f.peek() == 0xEF) { char bom[3]; f.read(bom, 3); if (bom[0] == 0xEF && bom[1] == 0xBB && bom[2] == 0xBF) { // 跳过成功 } else { f.seekg(0); // 恢复位置，BOM 不匹配 } } - 别用
seekg(3)直接跳 —— 如果文件小于 3 字节会进入 failstate - 如果后续要用
std::getline，确保跳过 BOM 后流状态是good()，否则第一行读不到
为什么 fopen + fgets 在 Windows 上有时“看起来”能跳 BOM
这不是标准行为，而是某些 CRT 实现（如 MSVC）在以文本模式（"r"）打开文件时，悄悄做了 BOM 检测和跳过 —— 但仅限 UTF-8 BOM，且不保证跨平台。Linux 下 fopen("file.txt", "r") 完全不碰 BOM。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 永远不要依赖这个行为，尤其当代码要跑在 Linux/macOS 或不同编译器上
- 若坚持用 C 风格 I/O，务必加
"rb"模式，并自己检查 BOM 字节 - 注意：
fgets读到\xEF\xBB\xBF后，返回的字符串长度会多出 3，strlen结果不准，strcmp必然失败
用 std::filesystem::path 判断编码？不行，别试
std::filesystem::path 只处理路径名，和文件内容编码零关系。有人误以为 path.extension() == ".utf8" 就能跳 BOM，这是典型混淆概念。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 文件编码信息不在路径里，也不在文件系统元数据中（除非你自己写了个约定并维护）
- 如果项目有固定规范（比如所有
.cfg都是带 BOM 的 UTF-8），那就硬编码跳过逻辑，别试图“自动检测编码”——没有可靠、轻量的方法 - 真要检测编码，得用 ICU 或
uchardet这类库，但它们开销大、依赖重，且对短文本（
真正麻烦的不是怎么跳，而是很多人根本没意识到自己正在读 BOM —— 它让第一行数据开头多了几个不可见字节，而错误常出现在下游：JSON 解析失败、数字转换为 0、正则匹配不上。盯住 std::string 的 data()[0] 和 size()，比任何文档都管用。
