根本原因是 std::ifstream 默认按字节流打开，不识别 BOM，将 UTF-8 或 UTF-16 BOM 当普通字符读入导致解析失败；需二进制模式打开、手动检测并跳过 BOM，再转码处理。
读取时直接遇到乱码或空内容
根本原因是 C++ 标准库的 std::ifstream 默认按字节流打开，不识别 BOM；遇到 UTF-8 BOM（0xEF 0xBB 0xBF）或 UTF-16 BOM（0xFF 0xFE 或 0xFE 0xFF）时，会把它们当普通字符读入，导致后续解析失败——比如 std::getline 读出首行含不可见字节，JSON 解析器直接报 invalid character。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用二进制模式打开文件：
std::ifstream f("file.txt", std::ios::binary)，避免系统层面对换行符或编码的隐式转换 - 手动读前 3 字节判断 UTF-8 BOM，前 2 字节判断 UTF-16 BOM；别依赖
std::codecvt_utf8（已弃用）或平台 API 做自动探测 - UTF-16 小端和大端 BOM 必须区分：读到
0xFF 0xFE是 UTF-16LE，0xFE 0xFF是 UTF-16BE；混用会导致每两个字节被颠倒解析
std::wifstream 读 UTF-16 文件却只读出一半字符
这是最典型的坑：Windows 下 std::wifstream 默认用本地宽字符编码（通常是 UTF-16LE），但若没显式指定 locale，它不会跳过 BOM，也不会按 UTF-16 单位解析——而是把每个字节当一个 wchar_t 处理，结果一个汉字变成两个乱码宽字符。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 必须在打开前设置 locale：
f.imbue(std::locale(f.getloc(), new std::codecvt_utf16<char16_t std::little_endian>));</char16_t> - 改用
char16_t流而非wchar_t流，避免 Windows 上wchar_t是 16 位但语义模糊的问题 - 更稳妥的做法是：先用
std::ifstream读原始字节，检测 BOM 后，用std::mbrtoc16或std::from_bytes（C++20）转成std::u16string
跨平台读 UTF-8 文件时 BOM 导致 std::stoi 失败
Linux/macOS 下很多工具生成的 UTF-8 文件带 BOM，而 std::stoi、std::stod 等函数遇到开头的 0xEF 0xBB 0xBF 会立即返回 0 并设 failbit，不是抛异常，容易被忽略。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 解析数字前，对字符串做 BOM 清洗：
s.erase(0, s.starts_with("\xEF\xBB\xBF") ? 3 : 0);（C++20）或手写 memcmp 判断 - 别用
std::istringstream直接读数字——它不跳过 Unicode 空格类字符，BOM 不属于std::isspace范围 - 如果文件由你控制生成，干脆禁用 BOM：VS Code 保存时选 “UTF-8” 而非 “UTF-8 with BOM”，Python
open(..., encoding="utf-8-sig")会自动剥离，但 C++ 不会
用 std::filesystem::path 处理含中文路径时 BOM 没影响？
有影响，但不在读取环节——std::filesystem::path 本身不碰文件内容，BOM 对它完全透明。真正出问题的是你用这个 path 构造 std::ifstream 后的读取逻辑。很多人误以为路径没问题就等于内容能读对，结果在解析阶段崩溃。
实操建议：
立即学习“C++免费学习笔记（深入）”；
-
std::filesystem::path只负责路径拼接与存在性检查，BOM 处理必须延后到流打开之后、首次读取之前 - Windows 下路径含中文时，确保编译器用 UTF-8 源码（加
// clang-format off和 BOM 无关，但影响源文件本身），否则u8"中文.txt"字面量可能被错误编码 - 调试时用十六进制查看器确认文件真实开头字节，别只信编辑器右下角写的“UTF-8”——很多编辑器显示的是声明，不是实际内容
