简介面向在 Visual Studio 中开发 C 程序、需要读写 JSON 数据的开发者这份已编译 jsoncpp 库省去从源码编译和依赖整理的步骤可用于接口数据解析、配置读取与序列化输出等场景。压缩包共 10 个文件大小约 1023KB主要由 8 个头文件和 2 个库文件组成头文件声明常用类与函数库文件供工程链接目录中带有 include、lib 以及 debug、release 分类。已有 339 人学习或下载。拿到后可按包含目录和附加依赖项完成接入围绕 JSON 解析、生成、查询及错误处理进行练习也可用于课程设计、工具开发中的小型数据交换任务减少环境搭建耗时适合希望快速在 VS 项目中集成该库的中级 C 学习者。1. 一个预编译包救了一个下午jsoncpp 到底该装哪一份接手老工程时最让人头疼的往往不是业务代码看不懂而是#include json/json.h那一行出现了波浪线意思很明确头文件还在库却没有。jsoncpp 源码文件不多真正麻烦的是把它编译出来CMake 版本对不上、机器上缺 Python、MSVC 工具链的字符集和运行库选项一改模板报错就能刷满一屏。我见过某开发者在一台不能联网的构建机上折腾了两个小时最后编译出的.lib跟主工程用的/MD不匹配链接报错前功尽弃。预编译好的 jsoncpp 正是为这种场景准备的头文件、静态库、动态库都已备齐你只需要挑出与自己的编译器匹配的那一份改两个路径写三行测试代码五分钟内就能确认它是否通过。下面这套顺序是我在 Windows MSVC 和 Linux GCC 两套环境里各走了一遍之后总结出来的。2. 环境先对齐jsoncpp 预编译包与编译器的配对表预编译库和源码包最大的区别在于源码包能修复问题预编译包只能选择匹配的那一份。选错了无法靠改代码解决只有在链接期才会暴露出来报错信息还常常指向无关的地方。所以在把文件放进工程之前先花两分钟对照清楚。2.1 编译器版本决定你该拿哪一份产物C 没有跨编译器的稳定 ABI这条限制在 jsoncpp 上体现得尤其明显。它对外暴露的接口里有std::string、std::vector还有Json::Value内部那套std::map与std::shared_ptr的组合。这些类型的内存布局由标准库实现决定而标准库由编译器版本决定。同一个jsoncpp.libVS2019 编出来的不能给 VS2015 链接x64 的不能给 x86 链接Release 的不能给 Debug 链接。常见做法是先看工程里用的是哪个平台工具集再去目录中找同名的文件夹。Windows 侧认准_MSC_VER宏和平台工具集名字vc140 对应 VS2015vc141 对应 VS2017vc142 对应 VS2019vc143 对应 VS2022。四个版本的运行库文件名不同、异常处理实现也不同互相之间不通用。MinGW 和 MSYS2 环境还要多看两个维度线程模型是 posix 还是 win32异常模型是 seh 还是 sjlj。x86_64 的 MSYS2 默认使用 posix seh拿到一份 sjlj 的.a链接一样会失败。Linux 侧的约束条件叫 GLIBCXX。GCC 5.1 之后标准库启用双 ABIstd::string在_GLIBCXX_USE_CXX11_ABI1和0下是两种完全不同的类型。用 GCC 4.8 编出来的.so拿去给 GCC 9 的工程链接符号表里根本找不到对应名字。目标平台编译器标识应选目录关键校验点Windows x64MSVC v143lib/x64/vc143/Release/MD与/MT需对应Windows x64MSVC v142lib/x64/vc142/Debug文件名带d后缀Windows x86MSVC v142lib/Win32/vc142/Release位数不能混WindowsMinGW-w64lib/mingw64/posix-seh线程、异常模型一致Linux x86_64GCC 5.1 及以上lib/linux-x64/查看GLIBCXX版本LinuxGCC 4.8lib/linux-x64-cxx03/旧 ABI 需单独标注提示如果在目录中找不到完全同名的文件夹就按工具集的主版本号来找。vc142 与 vc143 之间有兼容的前后版本反过来减一通常不行。2.2 拆包盘点include、lib、bin 三处不能少预编译包解压后第一件事是清点文件确认文件是否齐全。一份能用的 jsoncpp 预编译产物目录应该包含以下三层结构少任何一层都会在后面某个环节出问题。头文件层位于include/json/至少要包含json.h、config.h、forwards.h、value.h、reader.h、writer.h、allocator.h、assertions.h、version.h。config.h是编译期生成的里面写着JSON_USE_EXCEPTION、JSON_HAS_INT64这类开关它必须和库的编译选项一致。version.h提供JSONCPP_VERSION_STRING宏后面验证时要用到它用来确认头文件和库是否出自同一个版本。库文件层是主体。静态库在 Windows 上是jsoncpp.lib在 Linux 上是libjsoncpp.a动态库的 Windows 版本是jsoncpp.dll加导入库jsoncpp.libLinux 版本是libjsoncpp.so以及带版本号的实体比如libjsoncpp.so.1.9。如果包内同时提供了静态库和动态库两个.lib千万不要使用同一个名字否则很容易链接到错误的那一个正常的做法是放入不同子目录或者用_static后缀区分。辅助文件层容易被忽略但对 CMake 工程很关键lib/cmake/jsoncpp/下的jsoncppConfig.cmake、jsoncppConfigVersion.cmake以及lib/pkgconfig/jsoncpp.pc。有了这些文件find_package(jsoncpp)就能直接工作不需要手工填写路径。如果包里没有就改用后面 3.3 节的 IMPORTED 目标写法。# 清点预编译包内容确认三层结构齐全 find jsoncpp-prebuilt -maxdepth 3 -type d | sort # 输出应能看到 include/json、lib、bin 三处 ls include/json/ | head -20 # 头文件里应该能 grep 到版本宏 grep -r JSONCPP_VERSION_STRING include/json/version.h前面三条命令分别做三件事第一条看目录骨架确认预编译包的根目录是不是多套了一层文件夹第二条检查头文件数量正常在 9 到 12 个之间明显偏少说明包被裁剪过第三条从version.h中取出真实版本号记下来后面跟库文件的版本对不上就立刻能判断出来。我习惯把这个版本号写在工程README的第三行下一个人接手时不用再猜。3. 三种接入方式把 jsoncpp 嵌进工程的具体动作文件放好只是准备真正让工程识别它有手工配置、系统级安装、构建脚本接入三条路。选哪条取决于你的工程规模单工程临时用手工配置最快多工程共享系统级安装省事长期维护的正规项目一定走 CMake。3.1 MSVC 手工配置三个目录一次改到位Visual Studio 里最直接的接入方式是项目属性页。需要改动的地方只有三处C/C 的附加包含目录、链接器的附加库目录、链接器的附加依赖项。三处必须一起改只改前两处最后会报一串LNK2019。在属性管理器里对着具体配置改比直接改工程属性更稳尤其当你有 Debug、Release、x64、Win32 四个组合的时候。改完的属性可以保存成.props文件其他工程直接导入不用重复点。!-- 工程文件里对应的属性组Release|x64 组合 -- ItemDefinitionGroup Condition$(Configuration)|$(Platform)Release|x64 ClCompile !-- 指向 include 的上一级代码里才能写 #include json/json.h -- AdditionalIncludeDirectories$(SolutionDir)third_party\jsoncpp\include;%(AdditionalIncludeDirectories)/AdditionalIncludeDirectories /ClCompile Link !-- 精确到具体配置子目录避免链接到 Debug 版 -- AdditionalLibraryDirectories$(SolutionDir)third_party\jsoncpp\lib\x64\vc143\Release;%(AdditionalLibraryDirectories)/AdditionalLibraryDirectories AdditionalDependenciesjsoncpp.lib;%(AdditionalDependencies)/AdditionalDependencies /Link /ItemDefinitionGroup这段 XML 是.vcxproj里的真实结构手工编辑工程文件和用属性页操作等价。AdditionalIncludeDirectories指向include这一级而不是include/json因为代码里写的是json/json.h编译器会把include当作根来拼后面的相对路径如果多填了一层json就会变成json/json/json.h自然找不到。AdditionalLibraryDirectories必须精确到vc143\Release这种带配置的末级目录很多人只指到lib结果 Debug 版本d后缀的库被优先搜到链接期一片红。AdditionalDependencies里写库名不带路径靠上一行的目录去定位搜索顺序是从上到下、先到先得。运行期还差一步动态库的jsoncpp.dll要放到 exe 旁边或者把所在目录加进PATH。这一步不做编译链接全绿双击运行弹一个找不到模块的提示框。调试时可以把 DLL 目录写进调试属性的环境变量里省得每次拷贝。注意属性页里改的是当前选中的配置。改完 Debug|x64记得切到 Release|x64 再改一遍或者在属性管理器里用「所有配置」批量改。这是新手最容易漏的一步。3.2 Linux 与 MinGW库文件放哪、缓存怎么刷Linux 下把预编译包装成系统级依赖本质是三件事头文件进include库文件进lib然后刷新链接器缓存。放的位置有讲究/usr/local是给本地安装的第三方软件预留的跟包管理器装的/usr分开日后卸载或升级不会打架。# 1. 头文件放到 /usr/local/include/json sudo cp -a jsoncpp-prebuilt/include/json /usr/local/include/ # 2. 库文件连同软链接一起复制-a 保留软链关系 sudo cp -a jsoncpp-prebuilt/lib/linux-x64/libjsoncpp.so* /usr/local/lib/ # 3. 刷新动态链接器缓存让新库立刻可被找到 sudo ldconfig # 4. 确认系统能识别到它 ldconfig -p | grep jsoncpp第一条命令复制头文件-a保留目录结构和权限复制完/usr/local/include/json/json.h就位代码里#include json/json.h直接生效。第二条命令中的libjsoncpp.so*这个通配符很重要动态库通常有三个文件实体libjsoncpp.so.1.9.5、主版本软链libjsoncpp.so.1.9、开发用软链libjsoncpp.so。只复制实体链接期会报cannot find -ljsoncpp因为-l找的是那个不带版本号的软链。第三条ldconfig重建/etc/ld.so.cache不走这一步编译通过了运行时照样报找不到库。第四条是验证输出里能看到libjsoncpp.so.1之类的条目才算成功。编译命令按顺序给全顺便把运行期搜索路径也一起固定下来g main.cpp -o demo \ -I/usr/local/include \ -L/usr/local/lib \ -ljsoncpp \ -Wl,-rpath,/usr/local/lib四个参数各管一段-I给头文件搜索路径-L给链接期库搜索路径-ljsoncpp展开成libjsoncpp.so-Wl,-rpath,/usr/local/lib把路径写进可执行文件的DT_RUNPATH段运行时不依赖LD_LIBRARY_PATH也能找到。最后这个参数在容器镜像里特别有用镜像里通常不会配环境变量全靠 rpath 保底。MinGW 环境下还要多一步把bin目录里的libjsoncpp.dll复制到 exe 同级。MSYS2 的终端里ldd demo.exe可以列出依赖关系输出中出现not found就是缺 DLL。3.3 CMake 工程接入find_package 与 IMPORTED 目标两套写法工程一旦超过三个子模块手工配置路径就无法维持了。CMake 有两条路可选包里带jsoncppConfig.cmake的走find_package不带的走IMPORTED目标。两种写法都不需要改系统环境适合把预编译包直接放进third_party目录。cmake_minimum_required(VERSION 3.15) project(demo LANGUAGES CXX) # 方案一包内自带 cmake 配置指定前缀路径后直接 find list(APPEND CMAKE_PREFIX_PATH ${CMAKE_SOURCE_DIR}/third_party/jsoncpp) find_package(jsoncpp REQUIRED) add_executable(demo main.cpp) # 不同版本导出的目标名不一样1.9.x 常见的是 jsoncpp_lib 或 JsonCpp::JsonCpp target_link_libraries(demo PRIVATE jsoncpp_lib)CMAKE_PREFIX_PATH是给find_package的搜索根指向预编译包的顶层CMake 会自己去lib/cmake/jsoncpp/底下找配置文件。REQUIRED保证找不到就立刻报错退出而不是静默降级成一个空目标。真正容易出错的是最后一行jsoncpp 各版本导出的目标名不统一静态库叫jsoncpp_lib_static或jsoncpp_static动态库叫jsoncpp_lib新版又统一成带命名空间的JsonCpp::JsonCpp。名字写错了 CMake 配置阶段就会报「target not found」不会拖到链接期反而好排查。包里没有 cmake 配置文件时就用IMPORTED目标手工声明效果一样还更透明add_library(jsoncpp STATIC IMPORTED GLOBAL) set_target_properties(jsoncpp PROPERTIES # IMPORTED_LOCATION 必须是库文件的完整路径不能是目录 IMPORTED_LOCATION ${CMAKE_SOURCE_DIR}/third_party/jsoncpp/lib/x64/vc143/Release/jsoncpp.lib INTERFACE_INCLUDE_DIRECTORIES ${CMAKE_SOURCE_DIR}/third_party/jsoncpp/include ) add_executable(demo main.cpp) target_link_libraries(demo PRIVATE jsoncpp)STATIC IMPORTED声明这是一个外部已有的静态库CMake 不会去编译它只在链接时把路径加进去。IMPORTED_LOCATION必须给到.lib、.a、.so文件本身给目录会直接报错。INTERFACE_INCLUDE_DIRECTORIES是「使用这个库的人自动获得这个头文件路径」的意思target_link_libraries一写demo就自动拿到了 include 目录不用再单独target_include_directories。GLOBAL让这个目标在子目录里也可见工程分成多个add_subdirectory时必须加。4. 配置取舍静态还是动态、/MT 还是 /MD路径配好只是能让编译通过能不能稳定运行是另一回事。链接选项和库形态的选择决定了这套东西在你的发布包里会不会中途报错。4.1 运行库匹配/MT、/MD 与 Debug 后缀MSVC 的/MT和/MD决定 C 运行库是静态链入还是动态依赖。它们之间的区别不只是发布包里多不多一个vcruntime140.dll而是内存分配器是不是同一套。jsoncpp 的接口大量使用std::string字符串在库内部构造、在你的模块里析构如果两边用的是两套堆析构那一刻就是未定义行为。判断手里的.lib是哪种需要用dumpbin查看它写进文件里的默认库指令# 查看静态库声明的 CRTMSVCRT 是 /MDMSVCRTD 是 /MDd dumpbin /directives third_party\jsoncpp\lib\x64\vc143\Release\jsoncpp.lib | findstr DEFAULTLIB输出里出现MSVCRT说明是/MD出现MSVCRTD说明是/MDd出现LIBCMT说明是/MTLIBCMTD则是/MTd。拿到结果后把主工程的 C/C 代码生成选项设成同一个值。工程里一旦混用链接期多半会看到LNK4098: defaultlib 冲突这条警告不能忽略把它当错误处理比较稳妥。Debug 与 Release 的区分在 Windows 上更隐蔽。库文件名带不带d后缀不同发行包的约定不一样有的带有的靠目录区分。可靠办法还是dumpbin或者看config.h里有没有_DEBUG相关的条件分支。我在一个项目里遇到过这样的情况Debug 配置链接到了 Release 库编译链接全过一跑就崩溃查了两天才定位到std::string的调试迭代器在两套实现间不兼容。4.2 静态库与动态库发布形态和部署成本的权衡维度静态库.lib/.a动态库.dll/.so部署exe 自带无需附带其他文件必须同目录放库或配搜索路径体积每个 exe 各带一份代码多程序共享同一份升级必须重新链接换库文件即可接口不变时冲突与其他静态库符号可能重复受搜索顺序影响可能加载错版本调试符号直接进 exe断点直观需要单独保留 pdb 或 debuginfo小工具、绿色单文件、要丢给测试同事直接双击的选静态库少一类「在我机器上能跑」的问题。一个产品里七八个子模块都要解析 JSON选动态库公共代码只留一份还能统一升级。需要注意的是 Windows 上动态库的导入库和静态库扩展名同样是.lib两者名字撞了之后AdditionalDependencies里写一个名字无法区分到底链接了哪个。解决办法是目录隔离静态版本放lib/static动态版本放lib/shared路径写全不靠名字猜。Linux 上还有第三种选择编译时把.a加进去但链接顺序有讲究。-ljsoncpp必须写在引用它的目标文件之后g main.o -ljsoncpp能过g -ljsoncpp main.o就会报一堆未定义符号因为静态链接的解析是单向扫描的。4.3 头文件包含与命名空间版本差异带来的写法区别#include的路径在不同发行方式下不一样。自己装到/usr/local的写json/json.h某些发行版打包到jsoncpp/json/json.h用 pkg-config 拿到的路径又可能是第三种。写代码之前先确认一下pkg-config --cflags jsoncpp # 输出形如 -I/usr/include/jsoncpp那么代码里就要写 json/json.h如果输出里有-I/usr/include/jsoncpp说明编译器会去那个目录找json/json.h代码不用改。如果什么都没输出说明jsoncpp.pc没装到 pkg-config 的搜索路径里手工加-I即可。API 层面的版本差异更值得提前知道。Json::FastWriter、Json::StyledWriter在 1.9.x 里已经标记为废弃新写法是Json::StreamWriterBuilder配writeString。反过来如果工程里全是老代码用FastWriter也照样能编只是会出一堆deprecated警告。1.9.4 之后Json::Value的隐式类型转换开关JSON_USE_IMPLICIT_CONVERSIONS默认值变过value.asString()在某些场景下会抛异常规范的写法是先用isString()判断或者用asString()带默认值。这些差异都在config.h和version.h里拿到预编译包第一件事就是把这两个文件打开看一遍。5. 避坑与排查五条我踩过的链接和运行时错误预编译库的问题有个共同特点报错位置和真实原因经常相隔很远。下面五条按「现象 → 原因 → 解决」写遇到同类症状可以直接对号入座。5.1 LNK2019 未解析的外部符号报错的符号名带一堆修饰现象编译通过链接阶段报error LNK2019: 无法解析的外部符号 public: __cdecl Json::Value::Value(int)所有 jsoncpp 相关的符号都找不到。原因库压根没被链接进去或者链接错了一份。常见情况有三种AdditionalDependencies漏写库名AdditionalLibraryDirectories指到了空目录链接器没找到就跳过代码里定义了JSON_DLL宏编译器按__declspec(dllimport)生成符号实际链的是静态库两边对不上。解决先用dumpbin /symbols jsoncpp.lib | findstr Value确认库里确实有导出符号排除库文件本身残缺。再检查工程里有没有手写JSON_DLL宏静态库场景必须去掉。最后确认链接器实际搜到的文件路径把「链接器 → 常规 → 显示进度」打开日志里会打出每个.lib的完整路径一眼能看出接错了。5.2 double free or corruption崩在 Json::Value 析构里现象Debug 下跑得好好的切到 Release 或者反过来运行时随机崩溃调用栈指向Json::Value::~Value或者std::string的析构函数偶尔还伴随堆损坏提示。原因主工程和 jsoncpp 库用了不同的 CRT。一方/MT一方/MD或者一方 Debug 一方 Releasestd::string在一块堆上分配、在另一块堆上释放。解决按 4.1 节用dumpbin /directives查库的 CRT把工程改成同一套。工程属性里搜RuntimeLibrary确保所有配置项一致包括依赖的第三方库。这条我吃过一次亏之后现在新工程模板里把 CRT 选项写字面量写死不留给继承。5.3 程序启动提示找不到 jsoncpp.dll或者 0xc000007b现象编译链接全部通过双击 exe 弹窗提示缺少jsoncpp.dll或者提示应用程序无法正常启动错误码0xc000007b。原因前者是动态库没放到运行目录PATH里也没有。后者是位数不匹配64 位程序加载了 32 位 DLL或者反过来。0xc000007b这个错误码看起来吓人实际就是「架构不对」。解决先看 exe 是 x64 还是 Win32用dumpbin /headers demo.exe | findstr machine确认。再把对应位数的jsoncpp.dll复制到 exe 同级目录。排查加载了哪个 DLL 时用where jsoncpp.dll或者 Process Explorer 查看进程的模块列表比在系统目录里盲找快得多。系统目录里如果有别的软件塞进去的老版本 DLLPATH顺序会让它优先命中这也是玄学问题的常见来源。5.4 Linux 下报 GLIBCXX_3.4.26 not found现象编译一切正常运行时报version GLIBCXX_3.4.26 not found或者undefined reference to std::__cxx11::basic_string。原因预编译.so用的 GCC 版本比运行环境的 GCC 新它依赖的libstdc符号在目标机器上不存在。或者更隐蔽的一种库用新 ABI 编译_GLIBCXX_USE_CXX11_ABI1工程按旧 ABI 编两边std::string不是同一个类型。解决用strings /usr/local/lib/libjsoncpp.so.1.9 | grep GLIBCXX看库依赖的最高版本再对比目标机器上strings /usr/lib/x86_64-linux-gnu/libstdc.so.6 | grep GLIBCXX能提供的最高版本。前者高于后者只能换一份低版本 GCC 编的库或者升级目标机器的运行库。ABI 不匹配的情况检查编译命令里有没有-D_GLIBCXX_USE_CXX11_ABI0工程和库必须用同一个值。5.5 头文件和库不是同一版本解析结果诡异现象程序能跑解析简单 JSON 正常一遇到带数组或者嵌套对象的内容就出错字段值对不上或者抛Json::LogicError。原因include/json/下的头文件和lib/下的库来自不同版本。Json::Value的内部成员在两个版本之间增删过头文件按新布局计算偏移库按旧布局存取读出来的自然全是垃圾。解决比对两边版本。头文件看version.h里的JSONCPP_VERSION_STRING库文件在 Windows 上用dumpbin /strings jsoncpp.lib | findstr 1.9Linux 上直接看libjsoncpp.so文件名里的版本号。两边对不上就整套换掉不要只换一半。这条我现在的习惯是解压之后立刻核对核对不过直接删包重下不抱侥幸。6. 跑通验证一段 30 行的程序确认它真的能用到这一步编译链接应该都没问题了。但「能编过」和「能正确工作」是两回事特别是链接到了一份 ABI 不合的库症状可能延迟到某个特定操作才出现。我的做法是固定跑一段最小验证程序从解析、取值、序列化三个方向各过一遍。// verify.cpp —— 覆盖读、取、写三个方向 #include json/json.h #include iostream #include sstream int main() { // 1. 解析带嵌套对象和数组覆盖 Reader 的类型分支 const std::string raw R({name:demo,port:8080,tags:[a,b]}); Json::CharReaderBuilder readerBuilder; Json::Value root; std::string errs; std::istringstream iss(raw); if (!Json::parseFromStream(readerBuilder, iss, root, errs)) { std::cerr parse failed: errs std::endl; return 1; } // 2. 取值打印版本宏确认头文件与库版本一致 std::cout jsoncpp JSONCPP_VERSION_STRING std::endl; std::cout root[name].asString() root[port].asInt() root[tags].size() std::endl; // 3. 序列化再写回去验证 Writer 侧也正常 Json::StreamWriterBuilder writerBuilder; writerBuilder[indentation] ; std::cout Json::writeString(writerBuilder, root) std::endl; return 0; }这段代码刻意用了CharReaderBuilder和StreamWriterBuilder而不是老式的Json::Reader和FastWriter因为前者在 1.9.x 全系列都在后者已经进了废弃名单。parseFromStream的第四个参数errs一定要传解析失败时它能给出具体位置比只看返回值有用得多。JSONCPP_VERSION_STRING打印出来是头文件里的版本跟目录里库文件的版本对照一下就能确认整套文件出自同一份产物。最后一行序列化不带缩进输出便于比对。Windows 下用 MSVC 命令行编译Linux 下用 g两条命令各自对应前面配好的路径# Linux路径按 3.2 节的实际安装位置调整 g -stdc11 verify.cpp -o verify -I/usr/local/include -L/usr/local/lib -ljsoncpp -Wl,-rpath,/usr/local/lib ./verify# Windows在 Developer Command Prompt 里执行 cl /EHsc /MD /I third_party\jsoncpp\include verify.cpp /link /LIBPATH:third_party\jsoncpp\lib\x64\vc143\Release jsoncpp.lib verify.exe两边的预期输出一致逐行对照下面这张表核对输出行预期内容不通过说明第 1 行jsoncpp 1.9.x版本号为空或缺失头文件不全第 2 行demo 8080 2数字或数组长度不对ABI 不匹配第 3 行{name:demo,port:8080,tags:[a,b]}字段丢失或乱码序列化侧有问题三行全对说明头文件、库文件、运行库三者匹配读写两条路径都通。这时候再把这段代码删掉换成业务代码心里就有底了。如果第 2 行的数字变成一坨负数别怀疑代码写错直接回去查 4.1 节的 CRT 匹配如果第 3 行字段顺序跟原始 JSON 不一致那是正常的jsoncpp 内部用std::map存对象成员按 key 排序输出不是 bug。提示把这段验证代码留在工程里做成一个verify目标CI 上每次换库都跑一遍。比人工点开程序确认快也避免换库之后发现问题太晚。这套预编译包我放在下载区了解压后按第 2 章清点目录第 3 章挑一种接入方式第 6 章跑一遍验证整个过程二十来分钟。从那以后我每次接手新环境、换新编译器都会先跑一遍这段三十行的验证程序再动手写业务代码——预编译库的坑绝大多数不是「装没装上」而是「装的是不是对的那一份」而这件事只有跑起来才知道。希望帮到你。本文还有配套的精品资源点击获取
简介面向在 Visual Studio 中开发 C 程序、需要读写 JSON 数据的开发者这份已编译 jsoncpp 库省去从源码编译和依赖整理的步骤可用于接口数据解析、配置读取与序列化输出等场景。压缩包共 10 个文件大小约 1023KB主要由 8 个头文件和 2 个库文件组成头文件声明常用类与函数库文件供工程链接目录中带有 include、lib 以及 debug、release 分类。已有 339 人学习或下载。拿到后可按包含目录和附加依赖项完成接入围绕 JSON 解析、生成、查询及错误处理进行练习也可用于课程设计、工具开发中的小型数据交换任务减少环境搭建耗时适合希望快速在 VS 项目中集成该库的中级 C 学习者。1. 一个预编译包救了一个下午jsoncpp 到底该装哪一份接手老工程时最让人头疼的往往不是业务代码看不懂而是#include json/json.h那一行出现了波浪线意思很明确头文件还在库却没有。jsoncpp 源码文件不多真正麻烦的是把它编译出来CMake 版本对不上、机器上缺 Python、MSVC 工具链的字符集和运行库选项一改模板报错就能刷满一屏。我见过某开发者在一台不能联网的构建机上折腾了两个小时最后编译出的.lib跟主工程用的/MD不匹配链接报错前功尽弃。预编译好的 jsoncpp 正是为这种场景准备的头文件、静态库、动态库都已备齐你只需要挑出与自己的编译器匹配的那一份改两个路径写三行测试代码五分钟内就能确认它是否通过。下面这套顺序是我在 Windows MSVC 和 Linux GCC 两套环境里各走了一遍之后总结出来的。2. 环境先对齐jsoncpp 预编译包与编译器的配对表预编译库和源码包最大的区别在于源码包能修复问题预编译包只能选择匹配的那一份。选错了无法靠改代码解决只有在链接期才会暴露出来报错信息还常常指向无关的地方。所以在把文件放进工程之前先花两分钟对照清楚。2.1 编译器版本决定你该拿哪一份产物C 没有跨编译器的稳定 ABI这条限制在 jsoncpp 上体现得尤其明显。它对外暴露的接口里有std::string、std::vector还有Json::Value内部那套std::map与std::shared_ptr的组合。这些类型的内存布局由标准库实现决定而标准库由编译器版本决定。同一个jsoncpp.libVS2019 编出来的不能给 VS2015 链接x64 的不能给 x86 链接Release 的不能给 Debug 链接。常见做法是先看工程里用的是哪个平台工具集再去目录中找同名的文件夹。Windows 侧认准_MSC_VER宏和平台工具集名字vc140 对应 VS2015vc141 对应 VS2017vc142 对应 VS2019vc143 对应 VS2022。四个版本的运行库文件名不同、异常处理实现也不同互相之间不通用。MinGW 和 MSYS2 环境还要多看两个维度线程模型是 posix 还是 win32异常模型是 seh 还是 sjlj。x86_64 的 MSYS2 默认使用 posix seh拿到一份 sjlj 的.a链接一样会失败。Linux 侧的约束条件叫 GLIBCXX。GCC 5.1 之后标准库启用双 ABIstd::string在_GLIBCXX_USE_CXX11_ABI1和0下是两种完全不同的类型。用 GCC 4.8 编出来的.so拿去给 GCC 9 的工程链接符号表里根本找不到对应名字。目标平台编译器标识应选目录关键校验点Windows x64MSVC v143lib/x64/vc143/Release/MD与/MT需对应Windows x64MSVC v142lib/x64/vc142/Debug文件名带d后缀Windows x86MSVC v142lib/Win32/vc142/Release位数不能混WindowsMinGW-w64lib/mingw64/posix-seh线程、异常模型一致Linux x86_64GCC 5.1 及以上lib/linux-x64/查看GLIBCXX版本LinuxGCC 4.8lib/linux-x64-cxx03/旧 ABI 需单独标注提示如果在目录中找不到完全同名的文件夹就按工具集的主版本号来找。vc142 与 vc143 之间有兼容的前后版本反过来减一通常不行。2.2 拆包盘点include、lib、bin 三处不能少预编译包解压后第一件事是清点文件确认文件是否齐全。一份能用的 jsoncpp 预编译产物目录应该包含以下三层结构少任何一层都会在后面某个环节出问题。头文件层位于include/json/至少要包含json.h、config.h、forwards.h、value.h、reader.h、writer.h、allocator.h、assertions.h、version.h。config.h是编译期生成的里面写着JSON_USE_EXCEPTION、JSON_HAS_INT64这类开关它必须和库的编译选项一致。version.h提供JSONCPP_VERSION_STRING宏后面验证时要用到它用来确认头文件和库是否出自同一个版本。库文件层是主体。静态库在 Windows 上是jsoncpp.lib在 Linux 上是libjsoncpp.a动态库的 Windows 版本是jsoncpp.dll加导入库jsoncpp.libLinux 版本是libjsoncpp.so以及带版本号的实体比如libjsoncpp.so.1.9。如果包内同时提供了静态库和动态库两个.lib千万不要使用同一个名字否则很容易链接到错误的那一个正常的做法是放入不同子目录或者用_static后缀区分。辅助文件层容易被忽略但对 CMake 工程很关键lib/cmake/jsoncpp/下的jsoncppConfig.cmake、jsoncppConfigVersion.cmake以及lib/pkgconfig/jsoncpp.pc。有了这些文件find_package(jsoncpp)就能直接工作不需要手工填写路径。如果包里没有就改用后面 3.3 节的 IMPORTED 目标写法。# 清点预编译包内容确认三层结构齐全 find jsoncpp-prebuilt -maxdepth 3 -type d | sort # 输出应能看到 include/json、lib、bin 三处 ls include/json/ | head -20 # 头文件里应该能 grep 到版本宏 grep -r JSONCPP_VERSION_STRING include/json/version.h前面三条命令分别做三件事第一条看目录骨架确认预编译包的根目录是不是多套了一层文件夹第二条检查头文件数量正常在 9 到 12 个之间明显偏少说明包被裁剪过第三条从version.h中取出真实版本号记下来后面跟库文件的版本对不上就立刻能判断出来。我习惯把这个版本号写在工程README的第三行下一个人接手时不用再猜。3. 三种接入方式把 jsoncpp 嵌进工程的具体动作文件放好只是准备真正让工程识别它有手工配置、系统级安装、构建脚本接入三条路。选哪条取决于你的工程规模单工程临时用手工配置最快多工程共享系统级安装省事长期维护的正规项目一定走 CMake。3.1 MSVC 手工配置三个目录一次改到位Visual Studio 里最直接的接入方式是项目属性页。需要改动的地方只有三处C/C 的附加包含目录、链接器的附加库目录、链接器的附加依赖项。三处必须一起改只改前两处最后会报一串LNK2019。在属性管理器里对着具体配置改比直接改工程属性更稳尤其当你有 Debug、Release、x64、Win32 四个组合的时候。改完的属性可以保存成.props文件其他工程直接导入不用重复点。!-- 工程文件里对应的属性组Release|x64 组合 -- ItemDefinitionGroup Condition$(Configuration)|$(Platform)Release|x64 ClCompile !-- 指向 include 的上一级代码里才能写 #include json/json.h -- AdditionalIncludeDirectories$(SolutionDir)third_party\jsoncpp\include;%(AdditionalIncludeDirectories)/AdditionalIncludeDirectories /ClCompile Link !-- 精确到具体配置子目录避免链接到 Debug 版 -- AdditionalLibraryDirectories$(SolutionDir)third_party\jsoncpp\lib\x64\vc143\Release;%(AdditionalLibraryDirectories)/AdditionalLibraryDirectories AdditionalDependenciesjsoncpp.lib;%(AdditionalDependencies)/AdditionalDependencies /Link /ItemDefinitionGroup这段 XML 是.vcxproj里的真实结构手工编辑工程文件和用属性页操作等价。AdditionalIncludeDirectories指向include这一级而不是include/json因为代码里写的是json/json.h编译器会把include当作根来拼后面的相对路径如果多填了一层json就会变成json/json/json.h自然找不到。AdditionalLibraryDirectories必须精确到vc143\Release这种带配置的末级目录很多人只指到lib结果 Debug 版本d后缀的库被优先搜到链接期一片红。AdditionalDependencies里写库名不带路径靠上一行的目录去定位搜索顺序是从上到下、先到先得。运行期还差一步动态库的jsoncpp.dll要放到 exe 旁边或者把所在目录加进PATH。这一步不做编译链接全绿双击运行弹一个找不到模块的提示框。调试时可以把 DLL 目录写进调试属性的环境变量里省得每次拷贝。注意属性页里改的是当前选中的配置。改完 Debug|x64记得切到 Release|x64 再改一遍或者在属性管理器里用「所有配置」批量改。这是新手最容易漏的一步。3.2 Linux 与 MinGW库文件放哪、缓存怎么刷Linux 下把预编译包装成系统级依赖本质是三件事头文件进include库文件进lib然后刷新链接器缓存。放的位置有讲究/usr/local是给本地安装的第三方软件预留的跟包管理器装的/usr分开日后卸载或升级不会打架。# 1. 头文件放到 /usr/local/include/json sudo cp -a jsoncpp-prebuilt/include/json /usr/local/include/ # 2. 库文件连同软链接一起复制-a 保留软链关系 sudo cp -a jsoncpp-prebuilt/lib/linux-x64/libjsoncpp.so* /usr/local/lib/ # 3. 刷新动态链接器缓存让新库立刻可被找到 sudo ldconfig # 4. 确认系统能识别到它 ldconfig -p | grep jsoncpp第一条命令复制头文件-a保留目录结构和权限复制完/usr/local/include/json/json.h就位代码里#include json/json.h直接生效。第二条命令中的libjsoncpp.so*这个通配符很重要动态库通常有三个文件实体libjsoncpp.so.1.9.5、主版本软链libjsoncpp.so.1.9、开发用软链libjsoncpp.so。只复制实体链接期会报cannot find -ljsoncpp因为-l找的是那个不带版本号的软链。第三条ldconfig重建/etc/ld.so.cache不走这一步编译通过了运行时照样报找不到库。第四条是验证输出里能看到libjsoncpp.so.1之类的条目才算成功。编译命令按顺序给全顺便把运行期搜索路径也一起固定下来g main.cpp -o demo \ -I/usr/local/include \ -L/usr/local/lib \ -ljsoncpp \ -Wl,-rpath,/usr/local/lib四个参数各管一段-I给头文件搜索路径-L给链接期库搜索路径-ljsoncpp展开成libjsoncpp.so-Wl,-rpath,/usr/local/lib把路径写进可执行文件的DT_RUNPATH段运行时不依赖LD_LIBRARY_PATH也能找到。最后这个参数在容器镜像里特别有用镜像里通常不会配环境变量全靠 rpath 保底。MinGW 环境下还要多一步把bin目录里的libjsoncpp.dll复制到 exe 同级。MSYS2 的终端里ldd demo.exe可以列出依赖关系输出中出现not found就是缺 DLL。3.3 CMake 工程接入find_package 与 IMPORTED 目标两套写法工程一旦超过三个子模块手工配置路径就无法维持了。CMake 有两条路可选包里带jsoncppConfig.cmake的走find_package不带的走IMPORTED目标。两种写法都不需要改系统环境适合把预编译包直接放进third_party目录。cmake_minimum_required(VERSION 3.15) project(demo LANGUAGES CXX) # 方案一包内自带 cmake 配置指定前缀路径后直接 find list(APPEND CMAKE_PREFIX_PATH ${CMAKE_SOURCE_DIR}/third_party/jsoncpp) find_package(jsoncpp REQUIRED) add_executable(demo main.cpp) # 不同版本导出的目标名不一样1.9.x 常见的是 jsoncpp_lib 或 JsonCpp::JsonCpp target_link_libraries(demo PRIVATE jsoncpp_lib)CMAKE_PREFIX_PATH是给find_package的搜索根指向预编译包的顶层CMake 会自己去lib/cmake/jsoncpp/底下找配置文件。REQUIRED保证找不到就立刻报错退出而不是静默降级成一个空目标。真正容易出错的是最后一行jsoncpp 各版本导出的目标名不统一静态库叫jsoncpp_lib_static或jsoncpp_static动态库叫jsoncpp_lib新版又统一成带命名空间的JsonCpp::JsonCpp。名字写错了 CMake 配置阶段就会报「target not found」不会拖到链接期反而好排查。包里没有 cmake 配置文件时就用IMPORTED目标手工声明效果一样还更透明add_library(jsoncpp STATIC IMPORTED GLOBAL) set_target_properties(jsoncpp PROPERTIES # IMPORTED_LOCATION 必须是库文件的完整路径不能是目录 IMPORTED_LOCATION ${CMAKE_SOURCE_DIR}/third_party/jsoncpp/lib/x64/vc143/Release/jsoncpp.lib INTERFACE_INCLUDE_DIRECTORIES ${CMAKE_SOURCE_DIR}/third_party/jsoncpp/include ) add_executable(demo main.cpp) target_link_libraries(demo PRIVATE jsoncpp)STATIC IMPORTED声明这是一个外部已有的静态库CMake 不会去编译它只在链接时把路径加进去。IMPORTED_LOCATION必须给到.lib、.a、.so文件本身给目录会直接报错。INTERFACE_INCLUDE_DIRECTORIES是「使用这个库的人自动获得这个头文件路径」的意思target_link_libraries一写demo就自动拿到了 include 目录不用再单独target_include_directories。GLOBAL让这个目标在子目录里也可见工程分成多个add_subdirectory时必须加。4. 配置取舍静态还是动态、/MT 还是 /MD路径配好只是能让编译通过能不能稳定运行是另一回事。链接选项和库形态的选择决定了这套东西在你的发布包里会不会中途报错。4.1 运行库匹配/MT、/MD 与 Debug 后缀MSVC 的/MT和/MD决定 C 运行库是静态链入还是动态依赖。它们之间的区别不只是发布包里多不多一个vcruntime140.dll而是内存分配器是不是同一套。jsoncpp 的接口大量使用std::string字符串在库内部构造、在你的模块里析构如果两边用的是两套堆析构那一刻就是未定义行为。判断手里的.lib是哪种需要用dumpbin查看它写进文件里的默认库指令# 查看静态库声明的 CRTMSVCRT 是 /MDMSVCRTD 是 /MDd dumpbin /directives third_party\jsoncpp\lib\x64\vc143\Release\jsoncpp.lib | findstr DEFAULTLIB输出里出现MSVCRT说明是/MD出现MSVCRTD说明是/MDd出现LIBCMT说明是/MTLIBCMTD则是/MTd。拿到结果后把主工程的 C/C 代码生成选项设成同一个值。工程里一旦混用链接期多半会看到LNK4098: defaultlib 冲突这条警告不能忽略把它当错误处理比较稳妥。Debug 与 Release 的区分在 Windows 上更隐蔽。库文件名带不带d后缀不同发行包的约定不一样有的带有的靠目录区分。可靠办法还是dumpbin或者看config.h里有没有_DEBUG相关的条件分支。我在一个项目里遇到过这样的情况Debug 配置链接到了 Release 库编译链接全过一跑就崩溃查了两天才定位到std::string的调试迭代器在两套实现间不兼容。4.2 静态库与动态库发布形态和部署成本的权衡维度静态库.lib/.a动态库.dll/.so部署exe 自带无需附带其他文件必须同目录放库或配搜索路径体积每个 exe 各带一份代码多程序共享同一份升级必须重新链接换库文件即可接口不变时冲突与其他静态库符号可能重复受搜索顺序影响可能加载错版本调试符号直接进 exe断点直观需要单独保留 pdb 或 debuginfo小工具、绿色单文件、要丢给测试同事直接双击的选静态库少一类「在我机器上能跑」的问题。一个产品里七八个子模块都要解析 JSON选动态库公共代码只留一份还能统一升级。需要注意的是 Windows 上动态库的导入库和静态库扩展名同样是.lib两者名字撞了之后AdditionalDependencies里写一个名字无法区分到底链接了哪个。解决办法是目录隔离静态版本放lib/static动态版本放lib/shared路径写全不靠名字猜。Linux 上还有第三种选择编译时把.a加进去但链接顺序有讲究。-ljsoncpp必须写在引用它的目标文件之后g main.o -ljsoncpp能过g -ljsoncpp main.o就会报一堆未定义符号因为静态链接的解析是单向扫描的。4.3 头文件包含与命名空间版本差异带来的写法区别#include的路径在不同发行方式下不一样。自己装到/usr/local的写json/json.h某些发行版打包到jsoncpp/json/json.h用 pkg-config 拿到的路径又可能是第三种。写代码之前先确认一下pkg-config --cflags jsoncpp # 输出形如 -I/usr/include/jsoncpp那么代码里就要写 json/json.h如果输出里有-I/usr/include/jsoncpp说明编译器会去那个目录找json/json.h代码不用改。如果什么都没输出说明jsoncpp.pc没装到 pkg-config 的搜索路径里手工加-I即可。API 层面的版本差异更值得提前知道。Json::FastWriter、Json::StyledWriter在 1.9.x 里已经标记为废弃新写法是Json::StreamWriterBuilder配writeString。反过来如果工程里全是老代码用FastWriter也照样能编只是会出一堆deprecated警告。1.9.4 之后Json::Value的隐式类型转换开关JSON_USE_IMPLICIT_CONVERSIONS默认值变过value.asString()在某些场景下会抛异常规范的写法是先用isString()判断或者用asString()带默认值。这些差异都在config.h和version.h里拿到预编译包第一件事就是把这两个文件打开看一遍。5. 避坑与排查五条我踩过的链接和运行时错误预编译库的问题有个共同特点报错位置和真实原因经常相隔很远。下面五条按「现象 → 原因 → 解决」写遇到同类症状可以直接对号入座。5.1 LNK2019 未解析的外部符号报错的符号名带一堆修饰现象编译通过链接阶段报error LNK2019: 无法解析的外部符号 public: __cdecl Json::Value::Value(int)所有 jsoncpp 相关的符号都找不到。原因库压根没被链接进去或者链接错了一份。常见情况有三种AdditionalDependencies漏写库名AdditionalLibraryDirectories指到了空目录链接器没找到就跳过代码里定义了JSON_DLL宏编译器按__declspec(dllimport)生成符号实际链的是静态库两边对不上。解决先用dumpbin /symbols jsoncpp.lib | findstr Value确认库里确实有导出符号排除库文件本身残缺。再检查工程里有没有手写JSON_DLL宏静态库场景必须去掉。最后确认链接器实际搜到的文件路径把「链接器 → 常规 → 显示进度」打开日志里会打出每个.lib的完整路径一眼能看出接错了。5.2 double free or corruption崩在 Json::Value 析构里现象Debug 下跑得好好的切到 Release 或者反过来运行时随机崩溃调用栈指向Json::Value::~Value或者std::string的析构函数偶尔还伴随堆损坏提示。原因主工程和 jsoncpp 库用了不同的 CRT。一方/MT一方/MD或者一方 Debug 一方 Releasestd::string在一块堆上分配、在另一块堆上释放。解决按 4.1 节用dumpbin /directives查库的 CRT把工程改成同一套。工程属性里搜RuntimeLibrary确保所有配置项一致包括依赖的第三方库。这条我吃过一次亏之后现在新工程模板里把 CRT 选项写字面量写死不留给继承。5.3 程序启动提示找不到 jsoncpp.dll或者 0xc000007b现象编译链接全部通过双击 exe 弹窗提示缺少jsoncpp.dll或者提示应用程序无法正常启动错误码0xc000007b。原因前者是动态库没放到运行目录PATH里也没有。后者是位数不匹配64 位程序加载了 32 位 DLL或者反过来。0xc000007b这个错误码看起来吓人实际就是「架构不对」。解决先看 exe 是 x64 还是 Win32用dumpbin /headers demo.exe | findstr machine确认。再把对应位数的jsoncpp.dll复制到 exe 同级目录。排查加载了哪个 DLL 时用where jsoncpp.dll或者 Process Explorer 查看进程的模块列表比在系统目录里盲找快得多。系统目录里如果有别的软件塞进去的老版本 DLLPATH顺序会让它优先命中这也是玄学问题的常见来源。5.4 Linux 下报 GLIBCXX_3.4.26 not found现象编译一切正常运行时报version GLIBCXX_3.4.26 not found或者undefined reference to std::__cxx11::basic_string。原因预编译.so用的 GCC 版本比运行环境的 GCC 新它依赖的libstdc符号在目标机器上不存在。或者更隐蔽的一种库用新 ABI 编译_GLIBCXX_USE_CXX11_ABI1工程按旧 ABI 编两边std::string不是同一个类型。解决用strings /usr/local/lib/libjsoncpp.so.1.9 | grep GLIBCXX看库依赖的最高版本再对比目标机器上strings /usr/lib/x86_64-linux-gnu/libstdc.so.6 | grep GLIBCXX能提供的最高版本。前者高于后者只能换一份低版本 GCC 编的库或者升级目标机器的运行库。ABI 不匹配的情况检查编译命令里有没有-D_GLIBCXX_USE_CXX11_ABI0工程和库必须用同一个值。5.5 头文件和库不是同一版本解析结果诡异现象程序能跑解析简单 JSON 正常一遇到带数组或者嵌套对象的内容就出错字段值对不上或者抛Json::LogicError。原因include/json/下的头文件和lib/下的库来自不同版本。Json::Value的内部成员在两个版本之间增删过头文件按新布局计算偏移库按旧布局存取读出来的自然全是垃圾。解决比对两边版本。头文件看version.h里的JSONCPP_VERSION_STRING库文件在 Windows 上用dumpbin /strings jsoncpp.lib | findstr 1.9Linux 上直接看libjsoncpp.so文件名里的版本号。两边对不上就整套换掉不要只换一半。这条我现在的习惯是解压之后立刻核对核对不过直接删包重下不抱侥幸。6. 跑通验证一段 30 行的程序确认它真的能用到这一步编译链接应该都没问题了。但「能编过」和「能正确工作」是两回事特别是链接到了一份 ABI 不合的库症状可能延迟到某个特定操作才出现。我的做法是固定跑一段最小验证程序从解析、取值、序列化三个方向各过一遍。// verify.cpp —— 覆盖读、取、写三个方向 #include json/json.h #include iostream #include sstream int main() { // 1. 解析带嵌套对象和数组覆盖 Reader 的类型分支 const std::string raw R({name:demo,port:8080,tags:[a,b]}); Json::CharReaderBuilder readerBuilder; Json::Value root; std::string errs; std::istringstream iss(raw); if (!Json::parseFromStream(readerBuilder, iss, root, errs)) { std::cerr parse failed: errs std::endl; return 1; } // 2. 取值打印版本宏确认头文件与库版本一致 std::cout jsoncpp JSONCPP_VERSION_STRING std::endl; std::cout root[name].asString() root[port].asInt() root[tags].size() std::endl; // 3. 序列化再写回去验证 Writer 侧也正常 Json::StreamWriterBuilder writerBuilder; writerBuilder[indentation] ; std::cout Json::writeString(writerBuilder, root) std::endl; return 0; }这段代码刻意用了CharReaderBuilder和StreamWriterBuilder而不是老式的Json::Reader和FastWriter因为前者在 1.9.x 全系列都在后者已经进了废弃名单。parseFromStream的第四个参数errs一定要传解析失败时它能给出具体位置比只看返回值有用得多。JSONCPP_VERSION_STRING打印出来是头文件里的版本跟目录里库文件的版本对照一下就能确认整套文件出自同一份产物。最后一行序列化不带缩进输出便于比对。Windows 下用 MSVC 命令行编译Linux 下用 g两条命令各自对应前面配好的路径# Linux路径按 3.2 节的实际安装位置调整 g -stdc11 verify.cpp -o verify -I/usr/local/include -L/usr/local/lib -ljsoncpp -Wl,-rpath,/usr/local/lib ./verify# Windows在 Developer Command Prompt 里执行 cl /EHsc /MD /I third_party\jsoncpp\include verify.cpp /link /LIBPATH:third_party\jsoncpp\lib\x64\vc143\Release jsoncpp.lib verify.exe两边的预期输出一致逐行对照下面这张表核对输出行预期内容不通过说明第 1 行jsoncpp 1.9.x版本号为空或缺失头文件不全第 2 行demo 8080 2数字或数组长度不对ABI 不匹配第 3 行{name:demo,port:8080,tags:[a,b]}字段丢失或乱码序列化侧有问题三行全对说明头文件、库文件、运行库三者匹配读写两条路径都通。这时候再把这段代码删掉换成业务代码心里就有底了。如果第 2 行的数字变成一坨负数别怀疑代码写错直接回去查 4.1 节的 CRT 匹配如果第 3 行字段顺序跟原始 JSON 不一致那是正常的jsoncpp 内部用std::map存对象成员按 key 排序输出不是 bug。提示把这段验证代码留在工程里做成一个verify目标CI 上每次换库都跑一遍。比人工点开程序确认快也避免换库之后发现问题太晚。这套预编译包我放在下载区了解压后按第 2 章清点目录第 3 章挑一种接入方式第 6 章跑一遍验证整个过程二十来分钟。从那以后我每次接手新环境、换新编译器都会先跑一遍这段三十行的验证程序再动手写业务代码——预编译库的坑绝大多数不是「装没装上」而是「装的是不是对的那一份」而这件事只有跑起来才知道。希望帮到你。本文还有配套的精品资源点击获取
