用std::ifstream读纯文本配置最直接，需手动处理空行、注释、等号分割；json优先用nlohmann/json；检查文件存在用std::Filesystem::exists；环境变量应优先于配置文件；错误处理策略须明确。
用 std::ifstream 读纯文本配置最直接，但别指望它自动解析结构
纯 key=value 或行注释风格的配置（比如 host=localhost），std::ifstream 配合 std::getline 和字符串切分就能搞定。它不解析语法、不处理嵌套、不校验类型——你得自己跳过空行、识别 # 开头的注释、拆分等号左右。这不是缺陷，是设计使然：c++ 标准库不内置配置解析器。
- 常见错误：直接用
operator>>读取整行，遇到带空格的 value（如path=/var/log/app.log）会截断 - 正确做法：用
std::getline读整行，再用find+substr手动拆解 - 注意
std::String::find返回std::string::npos时必须检查，否则substr可能越界
JSON 配置优先选 nlohmann/json，别手写解析器
只要配置里有对象、数组、布尔或 NULL，硬用字符串切分很快失控。第三方库 nlohmann/json 是事实标准：头文件即用、API 直观、错误提示清晰。它把 JSON 文本转成 json 类型变量后，用 ["key"] 或 .at("key") 访问，支持类型转换（.get<int>()</int>）。
- 常见错误：用
operator[]访问不存在的 key——返回空json对象，后续.get<int>()</int>抛异常；改用.at("key")可提前捕获std::out_of_range - 路径差异：
json j = json::parse(input_string);接受字符串，json j = json::parse(std::ifstream("config.json"));也合法，但后者不报告具体行号错误 - 性能影响：解析本身不慢，但频繁调用
.get<t>()</t>做类型检查有开销；若配置不变，解析一次缓存结果即可
std::filesystem::exists 检查配置文件是否存在，别只靠 ifstream::is_open()
ifstream 构造后调 is_open() 返回 false，原因可能是：文件不存在、权限不足、路径是目录而非文件、磁盘已满。仅靠这个判断无法区分“找不到”和“打不开”。先用 std::filesystem::exists 确认路径存在且是常规文件，再尝试打开，能快速定位问题。
- 兼容性注意：C++17 起才支持
std::filesystem，编译需加-std=c++17和链接-lstdc++fs（GCC）或无需额外链接（Clang/macos） - 容易踩的坑：传入相对路径时，
std::filesystem::exists按当前工作目录解析，而 ide 启动程序的工作目录未必是项目根目录 - 建议组合使用：
if (!fs::exists(path) || !fs::is_regular_file(path)) { /* 处理缺失 */ }
环境变量覆盖配置值时，别在读取前就硬编码默认值
生产环境常通过 ENV=prod ./app 控制行为，这时应让环境变量优先于配置文件。典型错误是：先从文件读出 port=8080，再用 getenv("PORT") 覆盖——但如果环境变量未设置，getenv 返回 nullptr，直接传给 std::stoi 会崩溃。
立即学习“C++免费学习笔记（深入）”；
- 安全写法：用
auto env_val = std::getenv("PORT"); if (env_val != nullptr) port = std::stoi(env_val); - 类型转换风险：
std::getenv返回char*，不能直接用std::string(env_val)构造，除非确认非空；否则触发未定义行为 - 注意顺序：环境变量 → 配置文件 → 编译期默认值，这个优先级要写死在代码逻辑里，别靠注释说明
配置最难的不是读，是统一错误处理路径：文件缺失、格式错误、字段缺失、类型错配、环境变量冲突……这些错误该抛异常？返回错误码？还是记录日志后静默降级？选哪种取决于你的服务是否允许启动失败。没想清楚这点，前面所有解析逻辑都可能变成线上故障的放大器。