直接读取带BOM的UTF-8文件会导致BOM字节0xEF 0xBB 0xBF被当作普通字符读入，引发stoi失败、JSON解析错误、字符串比较不等及find失效等问题；C++标准库不自动识别或跳过BOM，必须以binary模式打开并手动检测跳过。
用 std::ifstream 直接读取带 BOM 的 UTF-8 文件会出什么问题
直接用 std::ifstream 以默认模式打开带 BOM 的 UTF-8 文件，头三个字节 0xEF 0xBB 0xBF 会被当作普通字符读入——比如你读第一行，line[0] 可能是 '\xEF'，导致 std::stoi 失败、JSON 解析报错、字符串比较不等，甚至 std::string::find("key") 找不到开头的字段。
这不是编码识别问题，而是原始字节被照单全收。C++ 标准库不解析 BOM，也不自动跳过它。
手动检测并跳过 UTF-8 BOM 的可靠写法
核心思路：先用 peek() 检查前三个字节是否为 0xEF 0xBB 0xBF，确认后调用 ignore(3) 跳过。注意必须用 std::ios::binary 模式打开，否则在 Windows 下换行符可能被误转，干扰 BOM 判断。
- 打开文件时务必加
std::ios::binary标志，避免文本模式对\r\n的隐式转换 -
peek()不移动读位置，但需确保流处于可读状态（未 EOF、无 failbit） - 跳过 BOM 后，后续按常规文本方式读取即可（如
std::getline），无需再设 locale 或 codecvt（已废弃且不可靠）
std::ifstream file("data.txt", std::ios::binary);
if (!file.is_open()) return;
// 检查 BOM
if (file.peek() == 0xEF) {
char bom[3];
file.read(bom, 3);
if (bom[0] == 0xEF && bom[1] == 0xBB && bom[2] == 0xBF) {
// BOM 存在，已读走，无需再 ignore
} else {
file.seekg(0); // 还原位置
}
} else {
file.seekg(0);
}
// 此时 file 已跳过 BOM，可切回文本模式读取（或继续 binary + 自行 decode）
std::string line;
std::getline(file, line); // line 不含 BOM
为什么不用 std::codecvt_utf8 或 std::locale
std::codecvt_utf8 在 C++17 中已被标记为 deprecated，GCC/Clang 新版本默认禁用，MSVC 实现有兼容性问题；即使启用，它也不处理 BOM 跳过逻辑，只负责字节 ↔ wchar_t 转换，且要求输入严格合法 UTF-8——而带 BOM 的流首部会破坏其内部状态机。
立即学习“C++免费学习笔记（深入）”；
更实际的问题是：你只是想“读文本”，不是做 Unicode normalization。引入 locale 机制反而让简单事情变复杂，还容易因 facet 注册失败导致 imbue() 静默失效。
Windows 上用 _getch() 或 cin.get() 做 peek 的陷阱
如果用控制台模拟读取或调试时手动 peek，注意：std::cin 默认是行缓冲，且受系统 locale 影响；_getch() 是 MSVC 特有、不回显、不等待换行，但完全绕过流状态，无法和 std::ifstream 统一处理。
- 不要混用
_getch()和std::ifstream对同一文件源 -
cin.get()在重定向输入时行为不稳定，尤其遇到0xFF等高位字节可能触发failbit - 坚持用
ifstream::peek()+read()组合，这是唯一可移植、可预测的方式
binary 标志，或在 peek 后没正确 reset，都会让看似正确的逻辑在某台机器上突然失效。 
