std::stod解析科学计数法丢精度是因double仅约15~17位有效十进制数字，而JSON字符串可能含更多位；nlohmann/json默认转double会丢失原始字符串，需用parser_callback或SAX handler保留；高精度计算应改用cpp_dec_float_50等类型，序列化时须手动转字符串避免再失真。
为什么 std::stod 解析科学计数法会丢精度？
直接用 std::stod 或 atof 解析 JSON 中类似 "1.2345678901234567e-10" 这样的字符串，结果常是 1.2345678901234568e-10 —— 最后一位变了。这不是 bug，而是 double 本身只有约 15~17 位有效十进制数字，而 JSON 字符串可能含更多位（比如 IEEE 754 binary64 能精确表示的十进制小数非常有限）。
关键点：JSON 规范不规定数值精度，但解析器有责任尽量保留原文本信息；标准库转换函数只做「最接近的 double」，不保证 round-trip 精确。
- JSON 字符串中写
"0.1"→double实际存的是0.10000000000000000555... - 再转回字符串输出时，若未控制格式，可能显示为
0.10000000000000001 - 高精度场景（金融、科学计算、ID 比对）必须避免这种隐式截断
用 nlohmann/json 时如何保留原始字符串值？
nlohmann/json 默认把数字全转成 double 或 int64_t，一旦解析完成，原始字符串就丢了。要保真，得在解析阶段「跳过自动转换」。
正确做法是：用 json::parse 的 allow_exceptions = false + 自定义 parser_callback，或更简单——直接读原始 token 流。
立即学习“C++免费学习笔记（深入）”；
- 启用
json::parse的json::parse(..., nullptr, false)并配合parser_callback，在value_type::number_float时返回json::value_t::discarded，强制该字段不被解析为数字 - 然后用
json.at("field").dump()得到原始字符串（含引号），再用substr(1, end-2)去掉引号 - 或者更干净：用
json::sax_parse+ 自定义 SAX handler，在number_float回调里直接拿到原始字符指针和长度（需传入std::string_view支持的版本，v3.11+）
需要计算时，怎么安全地转成高精度类型？
如果最终还是要算，但又不能接受 double 的误差，就得换底层表示。别硬刚 long double（它在 x86_64 上常是 80-bit 扩展精度，但 ABI 不稳定、跨平台行为不一）。
推荐路径：用字符串 → boost::multiprecision::cpp_dec_float_50 或 abseil's absl::numbers（轻量）做解析，或手写简易解析器处理科学计数法。
-
boost::multiprecision::cpp_dec_float_50("1.2345678901234567890123456789e-10")可精确存 50 位十进制数 - 若不想引入 Boost，可用
std::from_chars（C++17）先拆解：找'e'或'E'分出底数和指数，分别解析为整数，再做定点缩放（注意溢出） - 警惕
std::stold：它仍是long double，在 MSVC 和 GCC/macOS 上语义不同，不解决根本问题
序列化回 JSON 时为何又变样？
即使你内部用高精度类型存对了，用 nlohmann/json 的 json j = my_high_prec_value; 再 j.dump()，出来的还是 double 格式，精度已失。
根本原因：nlohmann/json 的 json 类型只支持 number_float_t = double（除非你重定义模板参数并重写序列化逻辑）。
- 方案一：不走自动序列化，手动构造
json对象，把高精度值先格式化为字符串（用std::ostringstream+std::setprecision控制位数），再设为json::string_t - 方案二：改用支持任意精度数值的 JSON 库，如
simdjson（只解析，不提供数值对象）或自研 parser + value wrapper - 方案三：业务层约定：所有高精度数值字段统一用字符串传输（JSON 中
"amount": "123.4567890123456789"），彻底绕过解析/序列化环节
最常被忽略的一点：不是“解析完再想办法修”，而是从 JSON Schema 设计阶段就要决定——这个字段是否允许丢失精度。一旦选了 number 类型，后续所有语言、所有解析器都会面临同样问题。
