最稳妥做法是直接用nlohmann::json::parse(const char, const char)传指针和长度解析原始字节流，避免std::string中间转换导致截断或乱码，并严格校验空响应、HTML错误页、编码及结构合法性。
直接用 nlohmann::json::parse() 解析网络返回的原始字节流最稳妥，但必须先确认编码是 UTF-8、内容非空、且已做异常捕获——跳过任意一步都可能在上线后突然崩溃。
网络响应体怎么传给 nlohmann::json
别把 HTTP 响应体当字符串拼接后再 parse，尤其不能用 std::string 中间转一次再传给 json::parse()。HTTP body 是 raw bytes，如果里面含 \0 或非 UTF-8 字节（比如服务端误发 GBK），std::string 构造时会截断或乱码。
- 正确做法：用
std::istringstream包一层，直接喂给json::parse() - 更推荐：用
json::parse(const char*, const char*)重载，传指针和长度，完全绕过std::string的隐式转换 - 如果用的是 cpr、libcurl 等库，确保拿到的是
std::vector<uint8_t></uint8_t>或std::string_view，检查.data()和.size()再解析
json::parse() 报 parse_error.101 怎么快速定位
这个错误几乎全是格式问题，不是逻辑 bug。常见原因按发生频率排序：
- 响应体为空（HTTP status 204 或服务端写错）——先检查
response.text().empty() - 服务端返回了 HTML 错误页（比如 502/404 页面）混在 JSON 里——打印前 200 字节看开头是不是
/code> - JSON 含尾随逗号（
"name": "a",）、单引号、注释——nlohmann/json默认不认，得手动开扩展（不建议） - 前端用了
JSON.stringify()但后端没设Content-Type: application/json，导致某些代理加了 BOM 或换行头
调试时加一句：std::cerr
立即学习“C++免费学习笔记（深入）”；
解析嵌套数组时怎么避免 std::out_of_range 或静默返回 null
链式调用 j["data"]["items"][0]["id"].get<int>()</int> 在任意一级缺失时，nlohmann::json 默认返回 json::value_t::null，但 .get<int>()</int> 会抛 type_error，不是越界异常。
- 安全写法：用
.value("key", default)——它自动处理 key 不存在、类型不匹配、null 值三种情况，返回默认值 - 数组访问前必须检查
.is_array()和.size() > index，j[100]不报错，但后续取值会崩 - 如果结构固定，定义 C++ struct +
NLOHMANN_DEFINE_TYPE_INTRUSIVE，用j.get<yourstruct>()</yourstruct>，解析失败直接 throw，比手动校验更早暴露问题
为什么不用 JsonCpp 解网络数据
不是不能用，而是它对非法输入更“宽容”，反而掩盖问题。比如服务端多传一个字段、少传一个字段、字段类型从 string 变成 number，JsonCpp 默认静默忽略或转成 0/空串，等你发现数据不对时，bug 已经进到业务层了。
-
nlohmann/json的.at("key")强制存在检查，.get<t>()</t>强制类型匹配，更适合网络这种不可信输入源 -
JsonCpp的get("key", defaultValue)虽然安全，但 defaultValue 类型必须严格匹配，否则静默转成 0 或空，排查困难 - 所有主流 HTTP 客户端（cpr、restinio、boost.beast）返回的都是 raw bytes，
nlohmann/json的 parse 接口设计更贴合这一事实
真正容易被忽略的点是：网络响应没有“一定合法”的假设。哪怕文档写死了字段名和类型，线上也可能因版本错配、中间件改写、CDN 缓存脏数据而出现意外。每次解析都要当成第一次，别省那几行校验代码。
