标准C++读取INI文件应使用std::ifstream逐行读取并手动解析，关键步骤为跳过注释、识别节名、提取键值对，配合自定义trim函数和UTF-8编码统一处理。
INI 文件读取该用什么 C++ 方式
标准 C++ 没有内置 INI 解析器，std::ifstream 逐行读 + 手动解析是最轻量、最可控的选择。第三方库（如 inih、SimpleIni）虽省事，但引入依赖、增加构建复杂度，小项目反而拖慢迭代节奏。
常见错误是直接套用 Python 思维——试图找“一行代码加载整个配置”，结果卡在编码（Windows 默认 ANSI/GBK）、注释识别、节名嵌套或空格处理上。
- Windows 下记事本保存的 INI 很可能是
GBK编码，std::ifstream默认按本地 locale 解码，Linux/macOS 下会乱码；统一转成 UTF-8 存储是最省心的解法 - 节名格式必须是
[section]，前后空格会被当作非法字符；[ section ]不被多数手写解析器识别 - 键值对中的等号两侧允许空格，但有些旧工具（如 Windows API 的
GetPrivateProfileString）会截断左侧空格，自己解析时建议用find_first_of('=')定位而非split('=')
手动解析的关键三步：跳过注释、识别节、提取键值
核心逻辑就三类正则式匹配：以 ; 或 # 开头的行是注释；方括号包裹的是节名；含等号且不在注释行里的，是键值对。别用 std::regex——它在 MSVC 上编译慢、运行慢，还容易因换行符不一致漏匹配。
实操建议用 std::string::find 和 std::string::substr 组合：
立即学习“C++免费学习笔记（深入）”；
std::string line;
while (std::getline(file, line)) {
auto comment_pos = line.find_first_of(";#");
if (comment_pos != std::string::npos) {
line.erase(comment_pos);
}
trim(line); // 自己写个去首尾空格的函数
if (line.empty()) continue;
if (line.starts_with("[") && line.ends_with("]")) {
current_section = line.substr(1, line.length() - 2);
} else if (auto eq_pos = line.find('='); eq_pos != std::string::npos) {
std::string key = trim(line.substr(0, eq_pos));
std::string value = trim(line.substr(eq_pos + 1));
config[current_section][key] = value;
}
}-
trim()必须自己实现，std::string没有原生版本；别忘了处理\r\n和\n - 节名和键名大小写敏感与否，由业务决定——Windows 系统 API 默认不区分，但你自己解析时默认应区分，避免隐式行为
- 值中若含等号（如
url=http://a=b&c=d），这种属于非标准用法，解析器应以第一个等号为界，后续内容全作 value；强行支持“最后一个等号”反而破坏兼容性
读取整数/布尔值时为什么总出错
INI 是纯文本，所有值都是字符串，std::stoi、std::stob 这类转换函数抛异常不是因为写错了，而是因为没做前置校验。
典型错误现象：std::stoi("off") 崩溃、std::stoi(" 42 ") 成功但 std::stoi("42px") 也成功（只转前缀数字），导致静默错误。
- 用
std::from_chars（C++17 起）替代std::stoi：它返回解析终点指针，能明确判断是否整行都参与转换 - 布尔值别依赖字符串相等比较（如
value == "true"），Windows INI 常见1/0、yes/no、on/off，建议统一映射表：std::map<:string bool> bool_map = {{"1",true},{"true",true},{"on",true},{"0",false},{"false",false},{"off",false}}; - 数值型配置项缺失时，
std::stoi抛std::invalid_argument，但程序不该因此崩溃——必须用try/catch或先检查 key 是否存在
跨平台路径和编码问题怎么绕过去
根本解法不是“适配所有编码”，而是让配置文件本身符合最小公约数：UTF-8 编码 + Unix 换行符（\n）+ 路径分隔符统一用 /（C++ 标准库和大多数系统都接受）。
Windows 用户用记事本保存 UTF-8 会加 BOM，导致第一行读出来是 \xEF\xBB\xBF[section]；VS Code、Notepad++ 默认无 BOM UTF-8，更安全。
- 读文件前先检测 BOM：若前三个字节是
\xEF\xBB\xBF，file.ignore(3)跳过 - 路径配置项（如
log_path=./logs/）不要在代码里拼接\\，一律用std::filesystem::path构造，它自动处理分隔符 - 如果必须读系统生成的带 BOM 或 GBK 的旧 INI，优先用
iconv或Windows API MultiByteToWideChar转 UTF-8 再解析，别在解析逻辑里混编码转换
最易被忽略的是：不同编译器对宽字符流（std::wifstream）的 locale 支持差异极大，MSVC 和 GCC 行为不一致，硬上宽字符反而增加不可控因素。老老实实用 UTF-8 + std::string，兼容性反而最好。
