热更新配置的核心是原子切换：用std::shared_ptr加载新配置并校验，再以std::atomic指针一次性替换；配置对象必须const不可变，监听应使用inotify/ReadDirectoryChangesW并校验mtime，解析失败需降级而非中断。
热更新配置的核心不是“重载”，而是“原子切换”
直接 std::filesystem::last_write_time 轮询 + 重新解析文件，90% 的项目会出竞态：读取中文件被写入一半、解析失败时旧配置丢失、多线程访问时看到半新半旧状态。真正可行的路径只有一条：把新配置加载到独立内存结构里，校验通过后，用原子指针（std::atomic<:shared_ptr config>></:shared_ptr>）一次性切换生效。旧配置对象等所有使用者自然释放——这才是安全热更新的底层逻辑。
用 std::shared_ptr + std::atomic 管理配置生命周期
别用裸指针或全局引用。配置对象必须是 const、不可变的，所有字段在构造后冻结。每次 reload 创建全新 std::shared_ptr<const config></const>，然后用 store() 原子替换当前句柄。使用者通过 load() 获取当前快照，天然线程安全且无锁。
常见错误现象：std::shared_ptr 指向可变对象，或 reload 时复用已有对象并修改字段——这会让正在读取的线程看到撕裂状态。
- Config 类所有成员变量声明为
const或用std::optional初始化后不再赋值 - reload 函数内部必须 new 出新对象，不能
reset()复用旧对象 - 业务代码每次访问配置前，先调用
current_config.load()拿最新快照，不要缓存指针
文件变更监听别自己轮询，用 inotify（Linux）或 ReadDirectoryChangesW（Windows）
轮询消耗 CPU，且有延迟窗口（比如 100ms 间隔内改两次，只触发一次 reload）。系统级事件通知才是低开销、准实时的选择。但注意：这些 API 不保证事件顺序，也不合并重复事件，所以仍需配合文件 mtime 和 size 双校验，避免误触发。
立即学习“C++免费学习笔记（深入）”；
使用场景：配置文件在容器里被 kubectl cp 替换、运维手动 echo 写入、或 CI/CD 自动下发时，轮询可能错过变更或反复触发。
- Linux 下优先用
inotify_add_watch(fd, path, IN_MODIFY | IN_MOVED_TO)，收到事件后检查stat(path).st_mtime是否变化 - Windows 下用
ReadDirectoryChangesW监听FILE_NOTIFY_CHANGE_LAST_WRITE，同样需校验 mtime - 跨平台封装层建议用
boost::asio::io_context+boost::asio::windows::object_handle/boost::asio::posix::stream_descriptor统一事件分发
JSON/YAML 解析失败必须降级，不能中断 reload 流程
配置文件语法错误是高频问题。一旦解析失败就卡住、报错、或回退到空配置，会导致服务行为突变甚至崩溃。正确做法是：保留当前有效配置，记录错误日志（含行号和原始内容片段），继续监听下一次变更。
性能影响：解析本身不重，但错误日志若每秒刷几十次，会压垮日志系统。应加限流（如 5 分钟内同错误最多记 3 条）。
- 用
nlohmann::json::parse()时捕获nlohmann::json::parse_error，提取e.byte定位位置 - YAML 用
yaml-cpp时检查node.IsDefined() && node.IsMap()，再取字段，避免operator[]抛异常 - reload 函数返回
std::expected<void std::string></void>（C++23）或自定义结果类型，让上层决定是否告警，而非终止流程
最难的不是监听或解析，是让所有模块都接受“配置可能随时切换”这个事实——比如网络超时参数改了，正在发包的连接不会立刻生效，得等下次建连；比如日志级别变了，已打开的 std::ofstream 不会自动 flush。这些边界要靠文档和代码注释钉死，而不是指望配置系统替你兜底。
