远程配置拉取失败时需综合处理权限、超时、原子写和解析四类边界：用绝对路径+status检查替代exists；设双层超时并限制重试；缓存更新须临时文件+rename原子替换；json解析仅捕获parse_error/type_error，显式校验字段；首次启动依赖硬编码默认值。
远程配置拉取失败时，std::filesystem::exists 检查本地缓存前必须确认权限和路径有效性
很多同学一上来就写 std::filesystem::exists("config.json")，结果在容器或受限目录里返回 false，误判为“无缓存”而直接报错退出。这不是缓存不存在，是进程没权限读路径，或者路径是相对路径但工作目录已变。
- 始终用绝对路径：启动时通过
argv[0]或环境变量（如CONFIG_DIR）拼出完整路径，例如std::filesystem::path(config_dir) / "config.json" - 检查
std::filesystem::status()而非仅exists()，它能区分“不存在”“拒绝访问”“是目录不是文件” - Linux 下注意 SELinux/AppArmor 限制；Windows 下注意 NTFS 权限继承是否丢失
HTTP 请求超时与重试逻辑不能只靠 libcurl 默认设置
libcurl 的 CURLOPT_TIMEOUT 是总耗时上限，对慢网络+大配置文件容易误杀；而 CURLOPT_CONNECTTIMEOUT 不管 DNS 解析延迟。降级的核心是“快速失败”，不是“等死再兜底”。
- 设两层超时：连接阶段
CURLOPT_CONNECTTIMEOUT_MS≤ 800ms，整个请求CURLOPT_TIMEOUT_MS≤ 2500ms - 最多重试 1 次，且第二次用更激进的超时（比如连通时间压到 300ms），避免雪崩式重试
- 若 HTTP 状态码是
5xx或0（连接失败），才触发降级；404或401属于业务错误，不应读缓存
本地缓存文件的原子更新必须用 std::filesystem::rename + 临时文件
直接 std::ofstream 覆盖原文件，一旦写到一半进程崩溃，缓存就损坏了。下次启动读到半截 JSON，解析失败，降级失效——等于没兜底。
- 下载成功后先写入临时文件，如
"config.json.tmp" - 用
std::filesystem::rename("config.json.tmp", "config.json")原子替换（POSIX 和 Windows 10+ 均保证） - 替换前可选校验：计算临时文件的 SHA256，比对服务端
Etag或响应头里的X-Config-Hash
配置解析失败时，json::parse 异常不能吞掉，要区分语法错误和类型不匹配
用 nlohmann::json 时，try { json::parse(buf) } catch (...) { return fallback(); } 看似稳妥，实则把字段类型写错（比如 string 写成 number）也吞掉了——这属于配置发布错误，该报警，不该静默降级。
立即学习“C++免费学习笔记（深入）”；
- 只捕获
json::parse_error（非法 JSON）和json::type_error（null 访问、越界等运行时解析异常） - 对字段存在性、类型做显式检查：
if (!j.contains("timeout") || !j["timeout"].is_number_integer())，这类问题应记录 warn 日志并强制走缓存 - 首次启动无缓存时，降级逻辑必须提供硬编码默认值（如
default_config静态 const），不能依赖文件存在
fopen 就完事，真正的难点在边界交叉：权限 + 超时 + 原子写 + 解析语义，四者只要一个松动，兜底就变成单点故障。 
