at()更安全，因键不存在时直接抛json::out_of_range异常并明确提示“key not found”，而[]会静默插入null导致后续get()抛type_error；实操须链式at()调用并配合contains()预检空数组。
用 nlohmann/json 读取多层嵌套 JSON 对象时，为什么 at() 比 [] 更安全？
因为 [] 在键不存在时会自动创建空对象或 null 值，后续调用 get<int>()</int> 等会抛 nlohmann::detail::type_error；而 at() 直接抛异常并明确提示“key not found”，便于定位哪一层缺失。
实操建议：
- 所有中间层级都用
at()链式调用，例如：root.at("data").at("items").at(0).at("config").at("timeout") - 如果某层可能为空（如
"items"是空数组），先用contains()判断再at()，否则直接崩溃 - 不要对
json::array_t用at("key")，数组只能用整数索引，否则触发out_of_range
写入含 vector
nlohmann/json 支持隐式类型转换，std::vector 和 std::map 可直接赋值给 json 对象，无需手动生成 json::object_t 或 json::array_t。
常见错误现象：把 std::map<:string std::string></:string> 直接塞进 json["props"] 后，发现值全变成 null —— 这是因为 map 的 value 类型是 std::string，但 JSON 要求 value 是 json 类型，需显式构造或依赖隐式转换。
正确做法：
- 确保容器元素类型能被 json 自动识别（
std::string、int、double、bool、其他json对象、或已定义to_json/from_json的结构体） - 写入嵌套数组时，优先用 initializer list 构造：
j["list"] = {{"a", 1}, {"b", 2}};，而不是先建空 array 再 push_back - 若结构体字段含非基本类型（如
std::optional<int></int>），必须为它特化to_json，否则编译失败
解析失败时只报 “parse error” 而没有行号，怎么快速定位？
nlohmann/json 默认不记录原始位置，json::parse() 抛出的异常里只有消息字符串，不含偏移量。靠肉眼数大文件里的括号几乎不可行。
解决方法很简单：启用 json::parser_callback 或改用带位置信息的解析模式。
推荐做法：
- 用
json::parse(str, nullptr, false)第三个参数设为false禁用异常，返回 optional，再配合json::accept()预检 - 更实用的是加一行调试输出：
std::cout - 真正要精确定位时，改用
json j = json::parse(str, &callback);，在 callback 里记录当前 depth 和字符位置，异常时打印 last_pos
跨平台写 JSON 文件后，Windows 上读出来字段顺序乱了，是 bug 吗？
不是 bug。JSON 标准本身不要求对象字段顺序，nlohmann/json 在序列化时默认使用 std::map 存储 key，而 std::map 按字典序排序 —— 这在 Linux/macOS 和 Windows 上行为一致，但如果你用了自定义 comparator 或启用了 JSON_USE_IMPLICIT_CONVERSIONS，可能触发不同实现路径。
影响场景：
- 做 diff 比对（如 git 提交前后 JSON 文件）时顺序不同导致大量假差异
- 某些老旧系统依赖字段顺序解析（虽不符合标准，但现实存在）
- 单元测试里 assert JSON 字符串相等，因顺序不同而失败
解决方案：
- 生成时用
json::ordered_map替代默认 map（需定义JSON_USE_ORDERED_MAP宏） - 读取后再用
dump(2)格式化输出，至少保证缩进一致，减少 diff 噪声 - 测试中别比原始字符串，改用
json::parse(a) == json::parse(b)做语义比较
最常被忽略的一点：即使启用了 ordered_map，如果输入 JSON 本身字段顺序混乱（比如由其他语言生成），你读进来再 dump 出去也不会“修复”顺序 —— 顺序只在你主动构造或修改时生效。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
