必须以 binary 模式打开文件，用 peek() 检测前3字节是否为 \xEF\xBB\xBF，若是则调用 ignore(3)，再读取内容；否则 JSON 等解析会因 BOM 失败。
读文件前先检测并跳过 UTF-8 BOM
UTF-8 文件开头的 \xEF\xBB\xBF 是 BOM，C++ 标准库不自动处理它，直接用 std::ifstream 读会导致首行乱码或解析失败（比如 JSON 解析器报 invalid character at offset 0）。不能靠“猜编码”或事后替换，得在打开流后、读内容前主动跳过。
- 用
peek()或read()检查前三个字节是否等于\xEF\xBB\xBF - 确认是 BOM 后调用
ignore(3)，而不是seekg(3)—— 后者在某些编译器+文件模式下可能失效（尤其 Windows 下以文本模式打开时） - 必须在设置
std::ios::binary模式下检测，否则 Windows 上换行符转换可能干扰字节判断
fstream 打开方式必须用 binary 模式
文本模式会触发隐式换行符转换（\r\n → \n），导致实际读到的前几个字节偏移、错位，BOM 检测必然失败。这不是可选项，是硬性前提。
- 打开时写
std::ifstream f("file.txt", std::ios::binary)，别省略std::ios::binary - 即使你后续按文本处理内容，BOM 检测阶段也必须 binary；检测完可以再切回文本逻辑（比如用
std::getline），但开头这三字节必须 binary 下抓 - Linux/macOS 下看似不敏感，但跨平台代码必须统一按 binary 处理，否则 CI 环境或客户机器上容易突然出问题
std::string 构造时别直接用流迭代器
像 std::string s{std::istreambuf_iterator<char>(f), {}};</char> 这种写法会把 BOM 当成正文塞进字符串，后面所有解析都带着脏数据。必须确保跳过 BOM 后，再开始读内容。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 检测 +
ignore(3)必须在构造std::string或首次getline之前完成 - 如果用
std::vector<char></char>缓存整个文件，也要先f.seekg(0, std::ios::end)得长度，减去 3（如果是 BOM），再read() - 注意：
ignore(3)后要检查f.good()，万一文件不足 3 字节（比如空文件），ignore会设 failbit
第三方库（如 nlohmann/json）不自动跳 BOM
很多人以为 JSON 库会容错处理 BOM，其实不会。nlohmann::json::parse() 遇到开头 \xEF\xBB\xBF 直接抛 parse_error，错误信息是 [json.exception.parse_error.101] parse error at line 1, column 1: syntax error while parsing value - invalid literal。这不是库的 bug，是设计使然 —— BOM 不属于 JSON 语法。
立即学习“C++免费学习笔记（深入）”；
- 必须在传给
parse()前，确保输入字符串/字符数组已剔除 BOM - 如果用
std::ifstream直接传流给parse()，同样要先跳过 BOM，否则流位置还在开头 - 用
std::string_view做中间层更安全：读全文件后，检查开头是否为 BOM，然后用sv.substr(3)构造无 BOM 的 view 再 parse
真正麻烦的不是跳三字节，而是所有环节——打开模式、检测时机、后续解析入口——必须严格串在一起。漏掉任意一环，BOM 就会以不同形态冒出来：有时是乱码，有时是解析失败，有时只在某台机器上复现。
