nlohmann/json 是最稳妥的 JSON 解析选择，因其原生支持结构体自动映射、编译期字段校验、安全异常机制及良好兼容性，避免 rapidjson 等库的手动解析与类型隐患。
用 nlohmann/json 是目前最稳妥、最省心的选择，别自己手写解析器，也别硬套 rapidjson 的 DOM 模式来回转换。
为什么选 nlohmann/json 而不是其他库
它原生支持结构体自动映射（from_json/to_json），C++17 起还能靠 JSON_FOR_EACH_N 宏或 ADL 隐式推导，不用反复写样板代码。相比之下，rapidjson 需要手动遍历 Value、检查类型、取字段；jsoncpp 没有结构体绑定机制，全靠字符串键查值，易出错且无法编译期校验字段名。
常见错误现象：rapidjson::ParseError 报在第 0 行、类型不匹配却没提示具体字段——因为没做字段存在性检查和类型断言。
- 使用场景：HTTP 响应体、WebSocket 消息、RPC 返回数据等标准 JSON 封包
- 性能影响：
nlohmann/json默认是 SAX 解析 + 内存树构建，对千级字段封包无压力；若需极致性能（如百万 QPS 日志解析），才考虑simdjson+ 手动 schema 匹配 - 兼容性：头文件仅依赖 STL，C++11 可用，但结构体映射需 C++17（因需
if constexpr和折叠表达式）
如何定义结构体并实现双向映射
核心是重载 from_json 和 to_json 函数，放在结构体同名命名空间内，靠 ADL 自动触发。不要把它们塞进类内部，也不要用模板特化污染全局命名空间。
立即学习“C++免费学习笔记（深入）”；
struct User {
std::string name;
int age = 0;
bool active = true;
};
<p>void from_json(const json& j, User& u) {
j.at("name").get_to(u.name);
j.at("age").get_to(u.age);
if (j.contains("active")) j.at("active").get_to(u.active); // 可选字段
}</p><p>void to_json(json& j, const User& u) {
j["name"] = u.name;
j["age"] = u.age;
j["active"] = u.active;
}
-
j.at("key")抛异常（std::out_of_range）比j["key"]更安全，避免静默缺省值掩盖协议变更 - 可选字段必须显式用
contains()判断，否则at()会炸；get_to()自动处理类型转换（如int←"123"字符串） - 嵌套结构体同理：只要子结构也有对应
from_json，父结构里直接j.at("sub").get_to(u.sub)
网络封包解析时的典型陷阱
真实封包常带 HTTP 头、换行、BOM、多余空格，或被 gzip 压缩过。直接丢给 json::parse() 必崩。
- 先确认输入是干净 UTF-8 字符串：用
std::string_view截掉\r\n\r\n后的 body，或调用json::parse(buf.data(), buf.data() + buf.size())指定范围 - 遇到
parse_error at byte X: syntax error while parsing value，大概率是开头多了0xEF,0xBB,0xBF（UTF-8 BOM），得跳过前 3 字节 - 字段名大小写敏感：服务端返回
"UserName"，你写j.at("username")就挂；建议用json::parse(..., nullptr, false)关闭异常，改用try-catch捕获具体 key - 整数溢出：JSON 里
"id": 9999999999999999999超出int64_t，get<int>()会抛out_of_range；稳妥做法是先get<json::number_integer_t>()
如何应对字段动态增减和版本兼容
协议升级后加了新字段，旧客户端不能因为不认识就崩溃。别用 at() 强求所有字段存在，改用 value() 提供默认值，或用 get_ptr() 做空检查。
// 安全读取可选字段，带默认值
u.avatar_url = j.value("avatar_url", std::string{});
<p>// 或更严格：只在字段存在且类型正确时赋值
if (auto<em> ptr = j.get_ptr<const std::string</em>>("remark")) {
u.remark = *ptr;
}
-
value()适合简单默认值；get_ptr()适合需要区分“字段缺失”和“字段为 null”的场景 - 服务端若开始返回
null而不是省略字段，记得结构体成员用std::optional<T>，并为它写专用的from_json - 字段废弃不等于删代码：保留解析逻辑但忽略赋值，避免下次协议回滚时出问题
真正难的不是解析语法，而是处理字段语义变化、空值边界、整数精度丢失这些协议层细节。写完 from_json 后，一定要用真实封包样本跑一遍，别只测 happy path。
