nlohmann/json跨平台部署实战：Windows/Linux/macOS避坑指南-平芜编程栈

1. 项目概述

如果你是一名C++开发者，并且你的项目需要在Windows、Linux和macOS这三个主流操作系统上运行，那么处理JSON数据时，nlohmann/json库几乎是一个绕不开的选择。这个库以其“现代C++”的设计哲学而闻名，承诺提供直观的语法和零依赖的集成体验。但“跨平台”这三个字，听起来美好，实操起来却可能遇到各种意想不到的坑。从Windows上Visual Studio的版本差异，到Linux上不同发行版的包管理器，再到macOS上Clang编译器的特殊配置，每个平台都有自己的一套“规矩”。

我经历过不止一次这样的场景：在Windows上调试得完美无缺的JSON解析代码，一放到Linux服务器上编译就报出一堆奇怪的模板错误；或者在macOS上跑得好好的程序，换到Windows上链接时却找不到符号。这些问题的根源，往往不在于代码逻辑本身，而在于我们如何在不同平台上“部署”这个库。部署不仅仅是把json.hpp文件复制到项目里那么简单，它涉及到构建系统的集成、编译器的兼容性、依赖管理以及最终的打包发布。今天，我就结合自己多年在三个平台间切换开发的经验，来详细拆解nlohmann/json的跨平台部署策略，把那些官方文档里一笔带过，但实际项目中至关重要的细节和避坑指南，一次性讲清楚。

2. 跨平台部署的核心挑战与设计思路

2.1 理解“跨平台”的真实含义

在开始动手之前，我们首先要明确一点：nlohmann/json标榜的“跨平台”到底指的是什么？从库本身的角度看，它指的是其源代码遵循C++11标准，不依赖任何平台特定的API（如Windows的Win32或Linux的POSIX扩展），因此理论上任何符合标准的C++编译器都能编译它。这确实是它最大的优势——一个纯头文件库，没有需要单独编译的.cpp文件或平台特定的二进制库（如.dll,.so,.dylib）。

然而，从我们开发者的“部署”视角看，“跨平台”意味着更多：

构建系统集成：你的项目可能使用CMake、Makefile、Visual Studio项目文件、Xcode项目，甚至是Bazel或Meson。库需要能无缝接入这些系统。
编译器兼容性：虽然支持C++11，但GCC、Clang、MSVC对标准的支持程度和扩展行为仍有细微差别，尤其是在模板实例化和异常处理等方面。
依赖管理：如何获取这个库？是手动下载头文件，还是通过vcpkg、conan、apt-get、homebrew等包管理器？不同团队成员、不同CI/CD环境需要一致。
运行时行为一致性：确保解析、序列化、数值处理等核心功能在所有平台上的行为一致，避免因浮点数精度、字节序（Endianness）或内存对齐差异导致的问题。

nlohmann/json通过其单一头文件的设计，极大地简化了前两个挑战。但正是这种“简单”，有时会让我们忽略了一些平台相关的细节配置。

2.2 部署方案选型：四种主流策略

根据项目规模、团队规范和目标平台，通常有四种部署策略：

策略一：直接包含单头文件这是最直接的方法，从GitHub Release页面或官网下载json.hpp，扔进项目的include目录，然后在代码中#include它。这种方法零依赖，最纯粹，适合小型项目或快速原型。

优点：极致简单，无需任何构建系统配置。
缺点：难以管理版本更新；在大型项目中，每个编译单元都包含这个庞大的头文件会显著增加编译时间；无法享受包管理器带来的依赖解析和冲突处理。

策略二：CMake集成（FetchContent或add_subdirectory）这是现代C++项目，尤其是使用CMake作为构建系统时的推荐做法。nlohmann/json提供了完善的CMake支持，你可以将它作为项目的一个子模块（Submodule）或通过FetchContent在配置时自动下载。

优点：与构建系统深度集成，可以自动处理依赖关系、编译器标志传递（如C++11标准）；便于版本锁定和团队协作。
缺点：要求项目使用CMake，对于遗留的Visual Studio.sln项目或纯Makefile项目需要额外适配。

策略三：系统级包管理器安装通过操作系统的包管理器安装开发包，例如：

Ubuntu/Debian:sudo apt-get install nlohmann-json3-dev
Fedora:sudo dnf install nlohmann_json-devel
macOS (Homebrew):brew install nlohmann-json
Windows (vcpkg):vcpkg install nlohmann-json
优点：与系统环境整合最好，管理方便，适合需要系统范围内统一库版本的环境。
缺点：不同平台包名可能不同（如nlohmann-json3-devvsnlohmann_json-devel）；版本可能滞后于上游；在CI环境中可能需要预先安装。

策略四：跨平台包管理器（Conan）使用像Conan这样的跨平台C/C++包管理器。你可以在conanfile.txt中声明依赖nlohmann/json，Conan会在构建时为你下载并生成对应编译器、架构的包。

优点：真正实现跨平台的依赖管理，版本控制精确，能处理复杂的依赖图，非常适合大型、多平台项目。
缺点：引入了额外的工具链和学习成本；需要团队统一使用Conan。

对于大多数项目，我推荐策略二（CMake集成），它在灵活性、可维护性和跨平台友好性之间取得了最佳平衡。下文将主要围绕这种策略展开，并兼顾其他策略的注意事项。

3. 三大平台详细部署实操指南

3.1 Windows平台：驯服Visual Studio

Windows上的C++开发环境以Visual Studio（MSVC）为主流。部署nlohmann/json时，需要特别注意编译器版本和项目配置。

3.1.1 环境准备与编译器兼容性

首先，确认你的Visual Studio版本。nlohmann/json要求MSVC 2015 Update 3或更高版本。我强烈建议使用VS 2019或VS 2022，它们对C++17/20标准支持更好，构建工具链也更稳定。你可以在VS Installer中确保安装了“使用C++的桌面开发”工作负载，并包含最新的MSVC工具集和Windows SDK。

一个常见的坑是工具集版本。即使你安装了VS 2022，旧项目可能仍在使用“v142”工具集（VS 2019），而新项目默认使用“v143”。nlohmann/json本身兼容这些工具集，但你的项目设置需要一致。在Visual Studio中，可以在项目属性 -> 常规 -> 平台工具集中查看和修改。

3.1.2 使用vcpkg进行部署（推荐给Windows原生项目）

如果你的项目是传统的Visual Studio解决方案（.sln），没有使用CMake，那么vcpkg是最佳选择。

安装vcpkg（如果尚未安装）：

git clone https://github.com/microsoft/vcpkg.git .\vcpkg\bootstrap-vcpkg.bat

安装nlohmann/json库：

.\vcpkg install nlohmann-json:x64-windows # 64位 # 或 .\vcpkg install nlohmann-json:x86-windows # 32位

集成到Visual Studio：运行.\vcpkg integrate install，这会将vcpkg的库路径自动添加到VS的全局搜索目录中。
在你的Visual Studio项目中，现在可以直接#include <nlohmann/json.hpp>，无需额外配置包含目录。链接也是自动的（对于头文件库，链接步骤实际上不需要做任何事）。

注意：vcpkg默认安装的是动态链接库的配置吗？对于nlohmann/json这种纯头文件库，vcpkg只是将头文件安装到特定目录，不存在链接问题。但如果你安装的是其他需要编译的库，需要注意x64-windows（动态链接）和x64-windows-static（静态链接）的区别。

3.1.3 使用CMake + Visual Studio

这是更现代、更跨平台的方式。

在你的CMakeLists.txt中，使用FetchContent引入库：

cmake_minimum_required(VERSION 3.11) project(MyProject) include(FetchContent) FetchContent_Declare(json URL https://github.com/nlohmann/json/releases/download/v3.11.3/json.tar.xz # 使用URL确保版本固定，避免因Git子模块更新导致的不确定性 ) FetchContent_MakeAvailable(json) add_executable(my_app main.cpp) target_link_libraries(my_app PRIVATE nlohmann_json::nlohmann_json)

使用Visual Studio打开CMakeLists.txt所在文件夹，或者使用CMake GUI生成.sln文件。
Visual Studio的CMake集成会自动处理一切。target_link_libraries那一行是关键，它不仅表达了依赖关系，还会自动将必要的包含目录（-I）和编译定义传递给my_app目标。

3.1.4 常见问题与排查

错误 C2338: static_assert failed ... maybe you forgot to include ?这通常是因为在包含json.hpp之前，没有包含必要的C++标准库头文件（如<string>,<vector>,<map>）。确保你的源文件首先包含了这些头文件，或者至少确保json.hpp是第一个被包含的头文件之一（因为它内部会检查并包含它们）。
编译时间过长：在Windows上，由于MSVC的模板实例化机制，包含json.hpp可能会显著增加编译时间。可以考虑使用预编译头文件（PCH）。在CMake中，可以启用CMAKE_PCH，或者在Visual Studio项目属性中设置“使用预编译头”。
Unicode路径问题：如果你的JSON文件路径或JSON字符串本身包含非ASCII字符（如中文），确保你的源代码文件保存为UTF-8 with BOM（对于MSVC兼容性更好），并且在打开文件流时使用宽字符版本或进行正确的编码转换。std::ifstream在Windows上默认使用本地代码页，可能导致乱码。可以考虑使用std::filesystem::path结合std::ifstream，或者使用库提供的json::parse函数直接接受std::wstring路径（如果库版本支持）。

3.2 Linux平台：应对多样的发行版与编译器

Linux环境的特点是发行版众多，编译器以GCC和Clang为主。部署的核心在于包管理和编译器标志。

3.2.1 通过系统包管理器安装

这是最快捷的方式，能确保库与系统其他组件兼容。

Ubuntu/Debian:
```
sudo apt update sudo apt install nlohmann-json3-dev
```
安装后，头文件通常位于/usr/include/nlohmann/json.hpp或/usr/include/json.hpp。编译时只需添加-std=c++11或更高标准。
```
g++ -std=c++11 my_app.cpp -o my_app
```
Fedora/RHEL/CentOS:
```
sudo dnf install nlohmann_json-devel
```
Arch Linux:
```
sudo pacman -S nlohmann-json
```

3.2.2 使用CMake进行项目管理

与Windows类似，在Linux上使用CMake是跨发行版的推荐做法。CMakeLists.txt的写法几乎相同。一个关键区别是，在Linux上，你更可能从终端使用cmake和make命令。

mkdir build && cd build cmake .. -DCMAKE_BUILD_TYPE=Release # 或 Debug make -j$(nproc) # 并行编译 ./my_app

如果你的项目需要部署到没有安装系统包的生产服务器，使用FetchContent或将json.hpp直接放入项目源码树是更可靠的选择，避免了服务器上依赖包版本不一致的问题。

3.2.3 编译器特定标志与优化

GCC/Clang警告：高警告级别（如-Wall -Wextra -pedantic）可能会对nlohmann/json内部的某些代码产生警告。库的作者通常已经尽力消除了警告，但不同编译器版本可能会有新警告。如果遇到，可以考虑在包含json.hpp之前，使用#pragma GCC diagnostic push/ignored/pop来临时禁用特定警告，或者调整项目的警告级别。
链接优化（LTO）：对于纯头文件库，链接时优化（LTO）的收益不大，因为所有代码都在编译单元内。但启用LTO对于整个项目的优化仍有好处。
调试信息：在Debug构建（-DCMAKE_BUILD_TYPE=Debug）中，JSON对象的调试输出可能非常冗长。GDB和LLDB都能很好地打印nlohmann::json对象的内容，这得益于库内部提供的打印器（printer）。

3.2.4 静态链接与动态链接的考量

nlohmann/json是头文件库，不存在传统的“链接”问题。它的所有代码都在头文件里，编译时直接嵌入到你的目标文件中。这意味着：

最终二进制文件体积：会增大，因为每个使用了JSON库的编译单元都包含了一份模板实例化的代码。如果多个.cpp文件都用了json，可能会存在代码重复（但链接器可能会去重）。
编译时间：如前所述，可能会增加。在Linux上，你唯一需要关心的“链接”是C++标准库（libstdc++或libc++）和可能的异常处理库。这通过-static-libstdc++或-static标志来控制，与nlohmann/json本身无关。

3.3 macOS平台：聚焦Clang与Homebrew

macOS的开发环境以Xcode和Clang编译器为核心，包管理器Homebrew是事实上的标准。

3.3.1 使用Homebrew安装

这是最主流、最便捷的方式。

brew install nlohmann-json

安装后，头文件通常位于/usr/local/include/nlohmann/json.hpp（对于Intel Mac）或/opt/homebrew/include/nlohmann/json.hpp（对于Apple Silicon Mac）。Homebrew会自动处理这些路径，使其对编译器可见。

3.3.2 Xcode项目集成

如果你使用Xcode IDE而非CMake：

将json.hpp拖入Xcode项目的文件导航器中。在弹出窗口中，务必取消勾选“Copy items if needed”，然后选择“Create folder references”。这样做的目的是创建一个指向头文件实际位置的引用，而不是复制一份。然后，在项目的“Build Settings”中，将包含json.hpp的目录路径添加到“Header Search Paths”中。
更推荐的方式是使用Xcode的“Swift Packages”依赖管理（虽然这是C++库）。Xcode 11+支持通过Package.swift引入依赖，但nlohmann/json主要提供CMake支持。一个变通方法是：在项目根目录创建一个Package.swift文件（仅用于依赖解析），或者直接使用CMake生成Xcode项目（cmake -G Xcode ..）。

3.3.3 CMake在macOS上的特殊配置

在macOS上使用CMake，与Linux类似，但需要注意：

编译器选择：默认使用Apple Clang。确保你的CMake命令能正确找到它。有时需要显式设置：
```
cmake .. -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++
```
部署目标（Deployment Target）：如果你的应用需要支持旧版本的macOS，需要在CMake中设置-DCMAKE_OSX_DEPLOYMENT_TARGET=10.15（例如）。这会影响编译器标志。nlohmann/json本身不依赖高版本系统API，所以兼容性很好。
Homebrew路径：如果你通过Homebrew安装了其他库，可能需要手动将/usr/local/opt或/opt/homebrew/opt下的路径添加到CMake的查找路径中。但对于nlohmann/json，通过FetchContent可以完全避免这个问题。

3.3.4 处理macOS上的C++标准库

macOS自带的C++标准库是libc++。nlohmann/json与libc++完全兼容。在CMake中，通常不需要特殊配置。但如果你遇到链接问题，可以尝试显式指定：

target_link_libraries(my_app PRIVATE nlohmann_json::nlohmann_json c++)

实际上，通过target_link_libraries链接nlohmann_json::nlohmann_json时，CMake的依赖传递特性通常会帮你处理好标准库的链接。

4. 构建系统集成深度解析

4.1 CMake：现代C++项目的基石

CMake是管理nlohmann/json跨平台依赖的首选工具。除了基本的FetchContent，还有一些高级用法和注意事项。

4.1.1 版本锁定与安全下载

直接使用FetchContent_Declare的Git仓库URL（如GIT_REPOSITORY）虽然方便，但在CI环境中可能因网络问题失败，且默认拉取master分支，不利于版本锁定。更稳健的做法是使用发布包URL并指定版本：

include(FetchContent) FetchContent_Declare( nlohmann_json URL https://github.com/nlohmann/json/releases/download/v3.11.3/json.tar.xz URL_HASH SHA256=xxxxxx # 强烈建议添加SHA256校验和以确保下载完整性 ) FetchContent_MakeAvailable(nlohmann_json)

你可以在GitHub Release页面找到特定版本的压缩包URL和哈希值。添加URL_HASH能防止下载内容被篡改。

4.1.2 控制库的构建选项

nlohmann/json的CMake项目提供了一些选项，可以通过set命令在FetchContent_MakeAvailable之前进行配置：

set(JSON_BuildTests OFF CACHE INTERNAL "") # 不构建测试，加快配置速度 set(JSON_Install OFF CACHE INTERNAL "") # 如果你不打算安装这个库到系统 set(JSON_MultipleHeaders OFF CACHE INTERNAL "") # 使用单头文件模式（默认） # 如果你想使用模块化头文件以加快编译速度，可以开启： # set(JSON_MultipleHeaders ON CACHE INTERNAL "") FetchContent_MakeAvailable(nlohmann_json)

JSON_MultipleHeaders选项特别有用。当设置为ON时，库会被安装为多个头文件（如json.hpp,json_fwd.hpp等），而不是单一的json.hpp。这样你可以只包含向前声明头文件json_fwd.hpp，在源文件中再包含完整的json.hpp，有助于减少编译依赖，加快增量编译速度。

4.1.3 处理导入目标（Imported Target）

nlohmann_json::nlohmann_json是一个CMake的“接口库”目标。它不编译任何代码，但携带了必要的属性：

INTERFACE_INCLUDE_DIRECTORIES: 头文件路径。
INTERFACE_COMPILE_FEATURES: 可能包含cxx_std_11，要求依赖它的目标至少使用C++11。
INTERFACE_COMPILE_DEFINITIONS: 可能包含一些宏定义，如JSON_DIAGNOSTICS（如果启用）。

当你用target_link_libraries链接它时，这些属性会自动传递给你的目标。这是CMake现代最佳实践，避免了手动管理包含目录和编译定义的繁琐与错误。

4.2 其他构建系统集成要点

Makefile：如果使用纯Makefile，你需要手动指定头文件路径-I/path/to/json/include，并确保编译标志包含-std=c++11。管理依赖更新比较麻烦。
Bazel：nlohmann/json提供了BUILD.bazel文件。你可以在你的WORKSPACE文件中通过http_archive引入，然后在BUILD文件中依赖@nlohmann_json//:json。
Meson：可以通过dependency('nlohmann-json')来查找，或者使用subproject。
Visual Studio (非CMake)：除了vcpkg，还可以手动将json.hpp所在目录添加到项目属性 -> C/C++ -> 常规 -> 附加包含目录中。

5. 高级配置与平台特定优化

5.1 编译器兼容性宏与诊断

nlohmann/json内部使用了一系列宏来适配不同编译器和处理特殊情况。了解这些宏有助于解决棘手的编译问题。

JSON_SKIP_UNSUPPORTED_COMPILER_CHECK：如果你使用的编译器版本较旧且不在官方支持列表，但经过测试可以工作，可以定义此宏来跳过编译器检查。慎用，因为可能遇到未定义行为。
JSON_DIAGNOSTICS：这是一个非常有用的调试宏。定义它（例如在CMake中target_compile_definitions(my_app PRIVATE JSON_DIAGNOSTICS)）后，当JSON解析或访问出错时，错误信息会包含更详细的上下文，比如JSON指针路径，这对于调试复杂数据结构的问题至关重要。注意，这会增加一些运行时开销。
JSON_USE_IMPLICIT_CONVERSIONS：默认定义为1，允许从JSON值到C++类型的隐式转换。如果你希望代码更安全、更明确，可以将其定义为0来禁用隐式转换，强制使用.get<T>()或.get_to()。
Android NDK：在Android.mk或CMake for Android中，需要确保使用足够新的STL（如c++_shared）和Clang编译器。在CMake中，正确设置ANDROID_STL和ANDROID_TOOLCHAIN即可，nlohmann/json的目标会自动适配。

5.2 性能与二进制大小考量

编译防火墙（Compilation Firewall）：如前所述，使用JSON_MultipleHeaders=ON并配合#include <nlohmann/json_fwd.hpp>可以在声明中使用json类型，而只在实现文件中包含完整的定义，这能显著减少头文件依赖，加快编译速度，尤其是在大型项目中。
异常禁用：如果你的项目禁用异常（-fno-exceptions），需要定义宏JSON_NOEXCEPTION。库会将异常替换为abort()调用。你需要确保你的代码不依赖JSON库抛出异常，而是通过返回值或错误码处理错误（库的某些接口在禁用异常时行为会改变，需要查阅文档）。
自定义分配器：库默认使用std::allocator。对于有特殊内存管理需求的项目（如游戏、嵌入式），可以通过特化nlohmann::json的模板参数来使用自定义分配器，但这属于高级用法。

5.3 持续集成（CI）中的跨平台构建

确保CI流水线能在所有目标平台上成功构建是关键。以下是一个GitHub Actions工作流示例，展示了如何在Windows、Ubuntu、macOS上测试你的项目：

name: Cross-Platform Build on: [push, pull_request] jobs: build: runs-on: ${{ matrix.os }} strategy: matrix: os: [windows-latest, ubuntu-latest, macos-latest] build_type: [Release, Debug] steps: - uses: actions/checkout@v4 - name: Configure CMake run: | cmake -B ${{github.workspace}}/build -DCMAKE_BUILD_TYPE=${{ matrix.build_type }} shell: bash - name: Build run: | cmake --build ${{github.workspace}}/build --config ${{ matrix.build_type }} shell: bash - name: Test (Linux/macOS) if: runner.os != 'Windows' run: | cd ${{github.workspace}}/build && ctest -C ${{ matrix.build_type }} --output-on-failure shell: bash - name: Test (Windows) if: runner.os == 'Windows' run: | cd ${{github.workspace}}/build && ctest -C ${{ matrix.build_type }} --output-on-failure shell: cmd

这个工作流会为每个操作系统和构建类型组合创建一个任务，使用CMake配置和构建项目，并运行测试。关键在于，你的CMakeLists.txt必须能通过FetchContent正确获取nlohmann/json，这样CI环境就不需要预先安装任何系统包。

6. 常见问题与排查技巧实录

在实际部署中，你几乎一定会遇到下面这些问题。这里是我踩过坑后总结的排查清单。

问题一：编译错误“找不到nlohmann/json.hpp”

Windows (VS): 检查vcpkg集成是否成功（vcpkg integrate install），或者CMake生成的VS项目是否包含了正确的包含目录。在VS中，可以在项目属性 -> C/C++ -> 常规 -> 附加包含目录中查看。
Linux/macOS: 检查头文件是否确实安装在标准路径（/usr/include,/usr/local/include）或CMake是否正确设置了包含路径。使用make VERBOSE=1查看实际的编译命令，确认-I参数是否正确。
通用排查：在CMake项目中，确保使用了target_link_libraries(my_target PRIVATE nlohmann_json::nlohmann_json)，而不是手动写include_directories。前者是正确且现代的做法。

问题二：链接错误，提示未定义的JSON相关符号

纯头文件库为什么会有链接错误？这几乎可以肯定是因为你的代码在多个编译单元中包含了json.hpp，并且以不同的编译器设置或宏定义进行编译。例如，一个源文件用-std=c++11编译，另一个用-std=c++17编译，或者一个定义了JSON_DIAGNOSTICS而另一个没有。这会导致nlohmann::json的模板在不同单元中被实例化成不同的类型，链接器就懵了。
解决方案：统一项目的编译标准（在CMake中用set(CMAKE_CXX_STANDARD 11)）和所有与JSON库相关的宏定义。确保所有用到JSON的源文件，其包含路径和编译定义是一致的。

问题三：在macOS上，使用Homebrew安装后，Clang报错“unknown type name 'uint8_t'”等

原因：缺少C标准库头文件。uint8_t定义在<cstdint>或<stdint.h>中。
解决：在包含json.hpp之前，确保包含了必要的C++标准库头文件。最简单的办法是，在你的预编译头文件或第一个包含的头文件中，按顺序包含：
```
#include <cstdint> #include <string> #include <vector> #include <map> #include <nlohmann/json.hpp>
```
库的文档也明确建议这么做。

问题四：跨平台读写JSON文件时，内容或路径编码不一致

文件内容编码：nlohmann/json只支持UTF-8编码。确保你保存和读取的JSON文件是UTF-8 without BOM（在Windows上，某些编辑器默认保存为带BOM的UTF-8或GBK，这会导致解析失败）。可以在代码中使用std::ifstream的二进制模式打开，或者使用库的json::parse函数直接读取文件流，它能处理BOM。
文件路径：如果路径包含非ASCII字符，在Windows上使用std::filesystem::path和宽字符API（_wfopen）是更安全的选择，或者将路径转换为UTF-8后再使用。在C++17及以上，std::filesystem是跨平台处理路径的最佳工具。

问题五：在嵌入式或资源受限平台，如何减小体积？

禁用异常和RTTI：定义JSON_NOEXCEPTION和编译时加上-fno-rtti。
自定义底层类型：nlohmann/json允许你通过特化nlohmann::basic_json模板的第四个参数（BinaryType等）来使用更节省内存的容器，例如用std::array代替std::vector（如果大小固定），或用更紧凑的字符串类。但这需要深入理解库的内部结构，改动较大。
评估替代方案：如果体积和性能是首要考虑，可以评估更轻量级的JSON库，如json-c（C语言）或RapidJSON（C++，但API不如nlohmann/json直观）。

问题六：如何验证部署是否真正“跨平台”成功？

编写平台无关的单元测试：使用类似Google Test或Catch2的框架，编写测试用例，覆盖JSON的序列化、反序列化、复杂结构访问等核心功能。
在CI中运行所有平台的测试：如上节所述，设置CI流水线，确保每次提交都在Windows、Linux、macOS上构建和测试通过。
检查二进制接口（ABI）兼容性：如果你在动态库（DLL/SO）中暴露使用了nlohmann::json的接口，要极其小心。不同编译器、甚至同一编译器的不同版本，对于这个高度模板化的类的内存布局可能不同，导致严重的ABI兼容性问题。最佳实践是，不要在动态库的公开API中直接使用nlohmann::json对象，而是传递字符串（JSON文本）或使用C风格接口。