应使用现代C++特性（std::optional、std::variant、std::string_view）构建健壮INI解析器，避免手写状态机；优先选用std::map而非unordered_map以保障顺序与可预测性；parse接受std::istream&实现零拷贝流式解析；读写职责分离，不内置序列化；不自动推断类型或结构，严格遵循INI语义。
INI 解析为什么别手写 std::getline + std::string::find 拼凑
手撕解析器看似轻量，实际很快会卡在边界 case 上：BOM 头、混合空格缩进、引号包裹的值、注释嵌套、等号前后空白、空节名、重复 key 覆盖策略……这些不是“可选功能”，而是真实 INI 文件里天天见的现实。
Modern C++ 的优势不在语法糖，而在用 std::optional 表达缺失值、用 std::variant 统一处理字符串/整数/布尔等类型、用 std::string_view 避免无谓拷贝。别让解析器变成状态机调试现场。
- Windows 记事本保存的 INI 常带 UTF-8 BOM，
std::ifstream默认不跳过，会导致第一节名开头是[Section] -
key = value和key=value必须等价，但key = value # comment里的#不能被当成值的一部分 - 若允许
path=C: ooar，反斜杠不能被误认为转义 —— INI 标准本身不定义转义，硬加反而破坏兼容性
用 std::unordered_map 套两层不如用 std::map<:string std::map std::string>></:string>
直觉上哈希更快，但 INI 文件通常就几十行，std::map 的有序性和可预测迭代顺序反而更实用：遍历时节和 key 自然按文件顺序排列，调试打印、配置导出、UI 下拉填充都省去额外排序。
更关键的是，std::map 支持 lower_bound 快速定位节起始位置；而哈希表一旦需要“获取所有节名”或“按顺序列出第 3 个节下的所有 key”，就得先 collect 再 sort，徒增开销。
立即学习“C++免费学习笔记（深入）”；
- 节名区分大小写？标准 INI 不区分，但 Windows API（
GetPrivateProfileString）默认不区分 —— 你的解析器若用std::map，只需传std::less（C++14 起支持透明比较），无需手动tolower - 避免用
std::unordered_map<:string std::any></:string>：std::any查值要std::any_cast，失败抛异常，且无法静态推导类型；不如暴露get_string()/get_int()等明确接口 - 值默认存
std::string，转换由使用者决定 —— 解析器不该替用户做类型猜测（比如把123自动当int，但007就该是字符串）
parse() 函数必须接受 std::istream& 而非 const std::string&
传字符串意味着调用方得先把整个文件读进内存再切分 —— 这不仅浪费，更导致无法处理超大配置（如含 Base64 片段的 INI）、无法从网络流或管道读取、无法复用同一份缓冲区多次解析。
用 std::istream& 是唯一能兼顾测试（std::istringstream）、文件（std::ifstream）、甚至内存映射（std::istreambuf_iterator）的方式。配合 std::string_view 提取 token，零拷贝解析完全可行。
- 测试时直接传
std::istringstream{"[a]\nkey=val\n"}，不用建临时文件 - 若需支持 BOM，统一在构造函数里 peek 前三字节，匹配
后调用is.seekg(3)，而不是让parse()自己处理编码逻辑 - 错误位置信息（行号）必须基于
is.tellg()和换行计数，而非字符串下标 —— 流式读取下标无意义
别在类里硬塞写入功能，serialize() 单独抽成自由函数
读和写关注点完全不同：读要考虑容错、兼容、模糊匹配；写只要严格遵循格式、保证可被重新读取即可。把二者塞进一个类，要么让 parse() 依赖序列化逻辑，要么让 serialize() 被迫理解解析时的脏数据修复策略 —— 这是设计污染。
更现实的问题是：用户常需要“读取 → 修改部分值 → 写回”，但写回时往往要求保留原文件注释、空行、键顺序。你没法在解析阶段完美还原这些信息，硬塞写入只会让用户掉坑里。
- 提供
to_string(const IniData&)自由函数，输入是只读的解析结果，输出是干净、规范、无注释的 INI 文本 - 真要保留格式？交给专门的格式保持型库（如
inih的 C++ 封装），或者让用户自己用正则替换 —— 别让轻量级解析器背这个锅 - 如果用户坚持要“改完立刻写”，明确文档里写清：此操作丢弃所有注释与空白，仅保证语义等价
最易被忽略的一点：INI 没有标准定义数组或嵌套结构。看到 item[0]=a、item[1]=b 就自动聚合成 vector？那是业务逻辑，不是解析器该干的活。解析器只负责把每行变成 {section, key, value} 三元组，剩下的，交给调用方判断。
