优先选 INI，因其轻量、易读且满足多数两层配置需求；若需任意深度嵌套才用 YAML；避免 JSON 因手动编辑容错性差；推荐扁平键存储+前缀视图折中方案。
配置文件格式选 YAML 还是 INI？先看需求再定
YAML 看起来优雅，但引入 yaml-cpp 会增加构建依赖和二进制体积；INI 更轻量，标准库就能解析（逐行 + 字符串分割），适合层级不深、无嵌套数组的场景。如果配置里要写 database.host 或 logging.level 这类点分路径，INI 配合节（section）+ 键值对就能模拟两级结构，再深就容易歧义——比如 [user.profile] 是节名还是嵌套路径？实际项目中，多数“带层级”需求其实止于两层，用 INI 足够，且调试时打开文件一眼能懂。
- 若需真正任意深度嵌套（如
api.v1.endpoints[0].timeout），直接上 YAML，别自己造树形解析器 - 不要用 JSON：C++ 原生无标准解析器，第三方库（如
jsoncpp或nlohmann/json）虽好，但配置文件被人手改错括号/逗号的概率远高于 INI - 纯文本解析时，
std::getline读行后务必用std::string::find_first_not_of(" \t")跳过空白行和注释，否则空指针或越界访问很常见
用 std::map<:string std::string> 存扁平键，还是嵌套 map？
存扁平键（如 "server.port"、"database.url"）最简单，查的时候直接 config_map.at("server.port")，不用递归遍历。但缺点是无法天然支持“获取所有 server.* 下的键”。嵌套 std::map<std::string, std::any> 能自然表达树，可写 get<int>("server.port")</int>，但 C++17 以前没 std::any，得自己写类型擦除或用 boost::variant——这会让代码变重，且运行时类型检查成本不可忽略。
- 推荐折中方案：内部用扁平
std::unordered_map存键值，对外提供get_child("server")方法，返回一个只含"port"、"host"等子键的视图（不拷贝，用std::string_view做前缀匹配） - 避免在构造函数里做深度解析：把解析逻辑拆成
load_from_file()和parse_line(const std::string&)，方便单元测试单行行为 - 键名统一转小写或保留大小写？建议保留——
HTTP_PROXY和http_proxy在某些环境语义不同
如何安全地从配置取 int/double/bool？别直接 std::stoi
std::stoi 遇到非数字字符串会抛 std::invalid_argument，而配置文件被手动改错太常见。更稳的做法是：先用 std::from_chars（C++17）尝试解析，它不抛异常、只返回状态；或者用 std::istringstream + failbit 检查：
int value;
std::istringstream iss(str_value);
iss >> value;
if (iss.fail() || !iss.eof()) {
throw std::runtime_error("invalid int: " + str_value);
}
-
bool解析尤其麻烦："1"、"true"、"yes"、"on"都可能被接受，必须明确定义支持哪些字符串，别依赖库默认行为 - 默认值机制要显式传参，而不是在
get_int("port", 8080)里硬编码——否则测试时没法覆盖默认值 - 所有
get_*方法最后都应调用一次exists(key)，避免静默返回 0 或 false（比如端口配成空字符串，std::stoi("")抛异常，但get_int("port", 8080)若没检查存在性，可能误用默认值）
线程安全怎么加？多数情况根本不需要
配置加载通常在程序启动时完成，之后只读。若真需要运行时热重载，才考虑加锁。但锁粒度很重要：全局 std::shared<em>mutex</em> 可以，但别在每个 get* 里加独占锁——读多写少场景下，用共享锁（std::shared_lock）更合理。
立即学习“C++免费学习笔记（深入）”；
- 如果配置类实例是全局单例，确保静态初始化顺序安全：别在其他静态对象的构造函数里调用
Config::instance().get(...) - 热重载时，新旧配置切换要原子：先解析到临时对象，再用
std::atomic_store替换指针（配合std::shared_ptr），而不是原地修改字段 - 日志里打印配置时，别直接
std::cout << config_map——map 里可能有密码字段，得白名单过滤键名，比如跳过含"password"或"key"的键
配置层级真正的复杂点不在解析逻辑，而在“用户以为的层级”和“代码实现的层级”之间存在认知差。比如运维写 [cache] 节，开发却按 cache.ttl 去读，结果找不到——这时候不是代码问题，是文档和约定问题。
