插件配置与元数据：JSON/INI 配置文件解析、插件版本与依赖声明

好，咱们接着聊。上一章我们把插件加载器搭起来了，动态库也能拽进进程了。但你想想看，一个插件系统要是光靠文件名和硬编码来管理，那跟写死代码有什么区别？

真正的插件系统，得让插件自己「说话」。它得告诉宿主：我叫什么、我是什么版本、我依赖谁、我有什么配置项。这就是插件配置与元数据要做的事。

为什么需要元数据？

我早年做过一个嵌入式项目，插件全靠文件名后缀来区分版本。结果有一次，一个同事把旧版本的 .so 文件覆盖了新版本的，系统直接崩了。排查了一下午，最后发现是版本不匹配。

从那以后，我养成了一个习惯：每个插件必须携带自己的元数据。元数据就是插件的「身份证」和「说明书」。

元数据至少包含这几样东西：

• 插件名称：唯一的标识符，别跟别的插件撞名
• 版本号：主版本.次版本.修订号，语义化版本
• 依赖声明：这个插件需要哪些其他插件，什么版本范围
• 配置项：插件对外暴露的可调参数，比如缓冲区大小、超时时间
• 作者/描述：方便维护，别等人走了代码就成黑盒

配置文件格式选型：JSON vs INI

说到配置文件，大家第一反应就是 JSON 或者 INI。我个人的建议是：JSON 用于复杂结构，INI 用于简单场景。

为什么？

• INI：简单、人类可读性好，适合只有键值对的场景。但嵌套结构？不好意思，不支持。
• JSON：支持数组、嵌套对象，解析库遍地都是。但写起来啰嗦，容易多一个逗号就解析失败。

我在项目中遇到过一种折中方案：用 JSON 做插件元数据，用 INI 做运行时配置。元数据是固定的，JSON 结构清晰；运行时配置经常被人手动改，INI 更友好。

JSON 配置文件解析实战

C 语言里解析 JSON，我推荐 cJSON 库。它轻量、无依赖，一个 .c 一个 .h 就能干活。

先看一个插件元数据的 JSON 示例：

{
  "name": "image_processor",
  "version": "2.1.0",
  "description": "图像处理插件，支持缩放和旋转",
  "author": "蓝海资料掘金营",
  "dependencies": [
    {
      "name": "memory_pool",
      "version": ">=1.0.0 <2.0.0"
    },
    {
      "name": "logger",
      "version": ">=3.0.0"
    }
  ],
  "config": {
    "max_buffer_size": 4096,
    "timeout_ms": 5000,
    "enable_cache": true
  }
}

解析这段 JSON 的 C 代码，我习惯这样写：

#include "cJSON.h"

typedef struct {
    char name[64];
    int major, minor, patch;
    char description[256];
    // 依赖列表用链表或动态数组
    Dependency *deps;
    int dep_count;
    // 配置项
    int max_buffer_size;
    int timeout_ms;
    int enable_cache;
} PluginMeta;

int parse_plugin_meta(const char *json_str, PluginMeta *meta) {
    cJSON *root = cJSON_Parse(json_str);
    if (!root) {
        fprintf(stderr, "JSON 解析失败\n");
        return -1;
    }

    // 读取名称
    cJSON *name = cJSON_GetObjectItem(root, "name");
    if (cJSON_IsString(name)) {
        strncpy(meta->name, name->valuestring, sizeof(meta->name));
    }

    // 解析版本号 "2.1.0" -> major=2, minor=1, patch=0
    cJSON *ver = cJSON_GetObjectItem(root, "version");
    if (cJSON_IsString(ver)) {
        sscanf(ver->valuestring, "%d.%d.%d",
               &meta->major, &meta->minor, &meta->patch);
    }

    // 解析配置项
    cJSON *config = cJSON_GetObjectItem(root, "config");
    if (config) {
        cJSON *buf = cJSON_GetObjectItem(config, "max_buffer_size");
        if (cJSON_IsNumber(buf)) meta->max_buffer_size = buf->valueint;

        cJSON *timeout = cJSON_GetObjectItem(config, "timeout_ms");
        if (cJSON_IsNumber(timeout)) meta->timeout_ms = timeout->valueint;
    }

    cJSON_Delete(root);
    return 0;
}

INI 配置文件解析实战

INI 解析更简单。我一般自己手写一个轻量解析器，或者用 inih 这个库。它只有几十行代码，够用。

INI 文件长这样：

[plugin]
name=image_processor
version=2.1.0

[dependencies]
memory_pool=>=1.0.0 <2.0.0
logger=>=3.0.0

[config]
max_buffer_size=4096
timeout_ms=5000
enable_cache=true

解析 INI 的核心逻辑就是逐行读取，遇到 [section] 就切换当前节，遇到 key=value 就存下来。嗯，这里要注意：INI 没有类型系统，所有值都是字符串，你需要自己转成 int 或 bool。

int parse_ini_line(const char *line, char *section,
                   char *key, char *value) {
    if (line[0] == '[') {
        // 提取 section 名
        sscanf(line, "[%[^]]]", section);
        return 1; // 表示这是节名
    }
    if (sscanf(line, "%[^=]=%s", key, value) == 2) {
        return 2; // 表示这是键值对
    }
    return 0; // 空行或注释
}

插件版本与依赖声明

版本管理是插件系统的命门。我见过最惨的一次事故：两个插件都依赖同一个底层库，但一个要求 1.x，另一个要求 2.x，加载时直接符号冲突，进程崩溃。

从那以后，我定了几条铁律：

• 语义化版本：主版本号不同，表示不兼容 API 变更。次版本号不同，表示新增功能但向后兼容。修订号不同，表示 bug 修复。
• 依赖范围：声明依赖时，不要写死版本号。用 >=1.0.0 <2.0.0 这样的范围，给升级留空间。
• 循环依赖检测：A 依赖 B，B 依赖 A？加载时直接报错，别等运行时崩。

依赖解析的代码，我一般这样写：

int check_dependency(const PluginMeta *plugin,
                     const PluginMeta *available[], int count) {
    for (int i = 0; i < plugin->dep_count; i++) {
        Dependency *dep = &plugin->deps[i];
        int found = 0;

        for (int j = 0; j < count; j++) {
            if (strcmp(dep->name, available[j]->name) == 0) {
                // 检查版本是否在范围内
                if (version_in_range(available[j], dep->version_range)) {
                    found = 1;
                    break;
                }
            }
        }

        if (!found) {
            fprintf(stderr, "插件 %s 缺少依赖: %s (版本 %s)\n",
                    plugin->name, dep->name, dep->version_range);
            return -1;
        }
    }
    return 0;
}

知识体系总览

下面这张图，把插件配置与元数据的核心逻辑串起来了：

避坑指南

做插件配置解析这几年，我踩过不少坑。挑几个典型的说说：

• 字符编码问题：JSON 文件里用了 UTF-8 BOM，解析器直接报错。我后来统一要求所有配置文件必须是纯 UTF-8 无 BOM。
• 版本号比较陷阱：字符串比较 "9.0.0" > "10.0.0" 会返回 true，因为 '9' > '1'。必须拆成整数逐段比较。
• 依赖循环：A 依赖 B，B 依赖 A，加载器死循环。我后来加了一个 visited 集合，检测到循环直接报错。
• 配置项默认值：解析 JSON 时，如果某个配置项缺失，不要直接报错。给一个合理的默认值，让插件能跑起来。

好了，插件配置与元数据这块，说白了就是让插件学会「自我介绍」。你给它一个 JSON 或 INI 文件，它告诉你它是什么、需要什么、能调什么。这套机制搭好了，插件系统才能真正做到「插拔自如」。

---