配置读取应由独立的ConfigLoader组件负责，业务对象只接收已解析参数；它统一处理多源配置、类型转换、默认值及错误容错，通过依赖注入提升可测性与可维护性。
配置读取不该由业务对象自己负责
业务类（比如 UserManager、DatabaseConnection）直接去打开文件、解析 JSON 或调用 std::getenv()，会导致职责混杂、测试困难、复用性差。它本该只关心“怎么管理用户”，而不是“配置从哪来、格式对不对、环境变量有没有 fallback”。
常见错误现象：UserManager 构造函数里硬编码读取 "config.json"，导致单元测试无法注入模拟配置；或不同模块各自重复实现 INI 解析逻辑，版本一升级就全崩。
- 配置读取是跨模块的基础设施行为，应下沉为独立组件
- 业务对象只接收已解析好的参数（如
int timeout_ms、std::string db_host），不碰原始数据源 - 若强行让业务对象读配置，后续想切到 Consul 或 etcd 就得改遍所有类
推荐用 ConfigLoader 或 ConfigProvider 类统一接管
新建一个轻量级、无状态的 ConfigLoader 类（或命名成 ConfigProvider），专门处理路径查找、格式解析、类型转换、默认值填充和错误提示。它的接口应该像这样：
class ConfigLoader {
public:
explicit ConfigLoader(std::string_view config_path);
std::string get_string(std::string_view key, std::string_view def = {});
int get_int(std::string_view key, int def = 0);
bool get_bool(std::string_view key, bool def = false);
private:
nlohmann::json data_; // 或其他解析后结构
};
使用场景：程序启动时初始化一次 ConfigLoader，然后把实例传给需要配置的模块（通过构造函数注入，或作为单例——但后者要小心生命周期）。
立即学习“C++免费学习笔记（深入）”；
- 避免全局变量式单例（如
ConfigLoader::instance()），否则单元测试难隔离 - 支持多格式：优先尝试
config.json，失败则 fallback 到config.yaml，再 fallback 到环境变量前缀APP_ -
get_int()等方法内部应捕获nlohmann::json::type_error并返回默认值，不抛异常（配置错误不该让服务 crash）
依赖注入比单例更可控，尤其在测试中
把 ConfigLoader 当作依赖传入业务对象，而不是让它自己去拿。例如：
UserManager um{ConfigLoader{"./etc/app.json"}};
而不是：
UserManager um{}; // 内部调用 ConfigLoader::instance()->get_int("timeout")
性能影响几乎为零，但可测性提升巨大。
- 单元测试时可传入一个 mock
ConfigLoader，返回预设值，无需真实文件或环境变量 - 集成测试可换用不同路径的实现实例，验证 fallback 行为
- 如果某模块临时需要另一套配置（如灰度流量专用 DB 参数），只需传另一个
ConfigLoader实例，不用改任何逻辑
环境变量和命令行参数建议由 ConfigLoader 统一合并，而非分散处理
别让 main() 把 argv 拆开塞进十几个对象，也别让每个模块都调用 std::getenv()。统一入口能保证优先级清晰：命令行 > 环境变量 > 配置文件 > 内置默认值。
容易踩的坑：std::getenv() 返回 char*，直接赋给 std::string 可能悬空（环境变量被覆盖后）；还有大小写问题（Linux 环境变量区分大小写，Windows 不区分）。
-
ConfigLoader应在构造时一次性读取并拷贝所有环境变量值，避免后续getenv()调用失效 - 命令行参数建议用
boost::program_options或CLI11解析后，转成键值对喂给ConfigLoader的内存层 - 合并策略用“后写入覆盖前写入”，比手动 if-else 判断更可靠
ConfigLoader 这一层。 
