简介这是一份面向 Geany 编辑器用户的 JSON 处理插件源码包定位为 JSON Prettifier 的独立实现可手动集成进 Geany用于对未格式化或压缩过的 JSON 文件进行美化、缩小和语法校验。插件支持全文或选区格式化、按实体拆分处理校验范围可设为全部或部分内容并支持正斜杠转义与缩进风格自定义在 Linux 环境下通过编译安装即可使用。资源共 176 个文件压缩包大小仅 163KB主体为 C 源码与头文件配以 json 测试样例、gold 预期结果、txt 说明及 cmake 等构建配置便于学习插件开发与调试。目前已有 402 人学习下载。借助源码和测试数据读者可掌握 yajl 解析库的封装用法、Geany 插件接口的编写流程也能理解 JSON 词法/语法分析在编辑器中的落地方式并在此基础上调整缩进策略或扩展 JSON5 等变体支持适合有志于扩展 Geany 功能的开发者参考。1. 为什么要在 Geany 里处理 JSON一个配置文件的惨案现场你大概也经历过这种时刻手改一个 JSON 配置文件多加了一个逗号或者把某个字符串的引号写成了中文引号保存后程序启动直接报错日志里只有一行parse error连行号都不给。你打开编辑器看了半天眼睛都花了也找不到问题在哪。这就是我们要聊聊的 Geany-JSON-Prettifier一个跑在 Geany 编辑器里的 JSON 格式化、美化和验证插件。它能在你按下一个快捷键后把乱七八糟的 JSON 排版成标准缩进格式顺手告诉你语法对不对、错在第几行。适合每天和配置文件、API 响应、数据交换打交道的开发者也适合把 Geany 当主力编辑器、不想为一个小功能再装一个 IDE 的人。2. 先看懂 Geany 插件的底裤插件结构、生命周期和选型取舍写插件之前得先认识到 Geany 不是那种开箱即用、自带插件 SDK 的编辑器。它是一套 C 语言写的轻量编辑器插件通过动态库加载注册回调函数到编辑器的事件循环里。没有 GUI 拖拽配置没有脚手架命令一切从geanyplugin.h这个头文件开始。2.1 Geany 插件到底长什么样入口、上下文与回调Geany 插件本质上就是一个编译成.so的动态库导出三个固定符号geany_plugin_set_info、geany_plugin_init和geany_plugin_cleanup。编辑器启动时扫描插件目录用dlopen加载这些库然后调geany_plugin_init完成初始化。先看最小骨架文件json_prettifier.c#include geanyplugin.h #include json_prettifier.h // 插件元信息Geany 在帮助/插件管理器里展示 PluginInfo geany_plugin_info { .name JSON Prettifier, .description Format, minify and validate JSON documents, .version {1, 0, 0}, .author Your Name }; // 工具菜单项的回调 static void on_prettify(GtkWidget *widget, gpointer data) { // 核心逻辑在之后实现 geany_debug(Prettify triggered); } void geany_plugin_init(GeanyPlugin *plugin, gpointer pdata) { GtkWidget *menu_item gtk_menu_item_new_with_label(Prettify JSON); g_signal_connect(menu_item, activate, G_CALLBACK(on_prettify), NULL); gtk_container_add(GTK_CONTAINER(geany-tools_menu), menu_item); gtk_widget_show(menu_item); plugin-priv menu_item; } void geany_plugin_cleanup(GeanyPlugin *plugin, gpointer pdata) { // 菜单项在插件卸载时由 Geany 框架统一回收这里一般留空 }逻辑说明geany_plugin_info是静态元数据Geany 的插件管理器读它做列表展示geany_plugin_init里做两件事——创建一个菜单项塞进 Geany 的「工具」菜单以及把菜单项指针存到plugin-priv方便后续清理时释放。geany_plugin_cleanup用于卸载时回收资源这个插件里菜单项由 GTK 父容器管理可以不手动销毁。参数说明PluginInfo.version是三个整数组成的版本号geany-debug是 Geany 提供的调试输出接口信息会打到 Geany 的日志面板比printf靠谱得多因为这日志能看到插件加载时间、编译选项这些上下文。2.2 为什么用 C 写而不是用外部脚本你可能会想Geany 明明支持「外部工具」直接调用jq、python -m json.tool不就行了确实可以但差别很大。外部工具方案每次执行都要起一个子进程选中的文本传进去、输出再读回来一来一回至少几百毫秒而且没法做细粒度的交互——比如错误定位到行号、在状态栏常驻验证结果、对选区做局部格式化。插件方案把这些动作全部压进编辑器进程内数据不用过管道关键是能拿到 Geany 内部的文档对象模型直接操作缓冲区。性能上也有考量。格式化一个几百 KB 的 JSON外部脚本从启动解释器到出结果要一两秒而 C 里调用 json-glib 的解析器整个过程不到几十毫秒。需要反复试参数、调缩进风格的时候这个差距体感非常明显。另一个决策点是 JSON 解析库。Geany 依赖 GLib 和 GTK而 json-glib 是 GLib 生态里的官方 JSON 库无需额外引入重量级依赖系统里通常已经装好了。这样编译插件时只需要链接json-glib-1.0不需要手写递归下降解析器。少一个自己维护的解析器就少一片出 bug 的土壤。2.3 搭建最小可编译插件骨架先跑通一个菜单项有了代码骨架还得知道怎么编译。Geany 插件用的构建方式是pkg-config找依赖路径再通过 CMake 或纯 Makefile 生成动态库。这里用最直白的 Makefile 演示依赖关系CC ? gcc PKG_CONFIG ? pkg-config # 找 Geany 和 json-glib 的头文件与库路径 GEANY_CFLAGS : $(shell $(PKG_CONFIG) --cflags geany) GEANY_LIBS : $(shell $(PKG_CONFIG) --libs geany) JSON_CFLAGS : $(shell $(PKG_CONFIG) --cflags json-glib-1.0) JSON_LIBS : $(shell $(PKG_CONFIG) --libs json-glib-1.0) PLUGIN_CFLAGS -fPIC -Wall -Wextra $(GEANY_CFLAGS) $(JSON_CFLAGS) PLUGIN_LIBS $(GEANY_LIBS) $(JSON_LIBS) json_prettifier.so: json_prettifier.c json_prettifier.h $(CC) -shared $(PLUGIN_CFLAGS) $ -o $ $(PLUGIN_LIBS) install: cp json_prettifier.so ~/.config/geany/plugins/逻辑说明-shared告诉编译器产出动态库-fPIC生成位置无关代码这是动态库的硬性要求。pkg-config --cflags geany会展开成类似-I/usr/include/geany -I/usr/include/geany/scintilla的路径这是能找到geanyplugin.h的前提。~/.config/geany/plugins/是用户级插件目录Linux 下 Geany 启动时会自动扫描这个目录不需要 root 权限适合日常调试。参数说明-Wall -Wextra建议保留Geany 插件开发里最常见的翻车就是回调函数签名不一致这两个开关能提前暴露大部分类型警告。GEANY_LIBS链接的其实只有glib-2.0Geany 本身不导出太多符号真正的接口都在头文件里用宏展开。编译后重启 Geany打开插件管理器如果列表里出现了JSON Prettifier说明骨架已经跑通。这一步是整个插件开发里最磨人的卡住的人很多是pkg-config找不到geany.pc文件——常见原因是系统里只装了geany没装geany-dev或对应的开发包。3. 格式化与美化的核心实现缩进、排序与 Unicode 处理骨架跑通只是第一步真正的核心在工具栏按钮背后那几百行逻辑里。格式化不是简单地把{换行加两个空格而是要处理好字符串里的特殊字符、数组和对象的嵌套层级、以及 JSON 标准里那些让人崩溃的边界情况。3.1 用 json-glib 做解析别手写状态机我见过某开发者自己写了一个基于字符扫描的格式化器最初几百行跑起来挺正常后来遇到一个 JSON 字符串里带{a:b}这种嵌套引号就彻底乱套。这就是典型的「手写状态机陷阱」JSON 的字符串字面量里允许出现任意字符包括大括号、引号被转义的、换行符不用完整词法分析根本判断不了哪个}是真的结构结束符。所以第一准则解析工作全部交给 json-glib。它提供JsonParser能够把文本解析成JsonNode树之后格式化就是一次树的遍历。看核心函数static gchar* prettify_json(const gchar *text, gsize length, GError **error) { JsonParser *parser json_parser_new(); JsonNode *root; gchar *result; // 解析输入文本出错时 error 会被填充 if (!json_parser_load_from_data(parser, text, length, error)) { g_object_unref(parser); return NULL; } root json_parser_get_root(parser); if (root NULL) { g_set_error(error, G_IO_ERROR, G_IO_ERROR_INVALID_DATA, No JSON content found); g_object_unref(parser); return NULL; } // json-glib 自带序列化器indent 参数控制缩进 result json_to_string(root, TRUE); g_object_unref(parser); return result; }逻辑说明json_parser_load_from_data是核心入口它接受原始文本和长度内部完成真正的词法分析和语法分析。如果输入不合法函数返回FALSE并且填充GError这个GError里带了具体的错误位置——后面做验证功能就是从这里拿行号的。json_parser_get_root取出树的根节点之后json_to_string把节点树重新序列化成文本第二个参数TRUE表示输出美化过的带缩进格式。参数说明json_to_string的缩进是固定的两个空格不能直接设置成 4 个空格这是 json-glib 的 API 限制。要改缩进风格得先拿到序列化文本再全局替换\n里的空格前缀稍后在 3.3 里再说怎么做。error参数必须传NULL或者一个初始化的GError *否则解析失败时直接内存泄漏。3.2 prettify 主流程解析→重排版→回写缓冲区格式化前后要有一个清晰的缓冲区读写流程。Geany 里操作文本依赖 Scintilla 编辑组件通过sci_get_text取全文替换内容则用sci_set_text。这里需要额外注意一件事操作前必须保存当前的撤销栈状态否则用户按一次撤销会奇迹般地把整个格式化结果全部撤销掉而不是只撤销一步。看完整的回调实现static void on_prettify(GtkWidget *widget, gpointer data) { GeanyDocument *doc document_get_current(); gchar *src, *formatted; gsize len; GError *error NULL; if (doc NULL || doc-editor NULL) return; // 第一步取出编辑器全部内容 len sci_get_length(doc-editor-sci); src g_malloc(len 1); sci_get_contents(doc-editor-sci, len 1, src); // 第二步格式化 formatted prettify_json(src, len, error); g_free(src); if (error ! NULL) { // 弹对话框提示用户错误位置 show_parse_error(doc, error); g_error_free(error); return; } // 第三步替换内容前进入撤销分组 sci_start_undo_group(doc-editor-sci); sci_set_text(doc-editor-sci, formatted); sci_end_undo_group(doc-editor-sci); g_free(formatted); }逻辑说明sci_get_length和sci_get_contents是老搭档先问长度再按长度取数据避免自己猜缓冲区大小。sci_start_undo_group和sci_end_undo_group是 Scintilla 的分组撤销机制把一次全文替换包进去这样用户 CtrlZ 一次就能退回原始内容不会撤销到一半看到残缺文本。参数说明sci_get_contents的第二个参数必须是缓冲区大小包含结尾的空字符所以分配时要len 1这是 Scintilla API 的经典陷阱。formatted返回的是新分配的内存用完必须释放否则长时间使用编辑器内存会肉眼可见地增长。3.3 处理特殊需求键排序、数组缩进、Unicode 保留基础格式化跑通后你会遇到真实世界里的需求。比如说某个接口返回的 JSON 键顺序是乱的你想按字母序排列方便 diff再比如团队规范要求 4 空格缩进json-glib 默认 2 空格还有最关键的一点中文内容格式化后不能被转义成\uXXXX否则人眼完全没法看。这三个问题可以集中解决。键排序在解析之后、序列化之前做递归遍历JsonObject把键排序后重新组装缩进风格在序列化之后做字符串处理Unicode 转义的问题则需要换一个函数。看这个递归排序的实现思路static void sort_object_recursive(JsonObject *obj) { GList *keys, *iter; gchar **key_array, **sorted; guint i, n; n json_object_get_size(obj); if (n 2) return; // 取出所有键并排序 key_array g_new0(gchar *, n 1); keys json_object_get_members(obj); i 0; for (iter keys; iter ! NULL; iter iter-next) { key_array[i] g_strdup((const gchar *)iter-data); } sorted g_strdupv(key_array); // 把键数组按 strcmp 排序 // 这里用 GLib 的排序函数注意只排键不排值 // 重建新对象按排序后的键插入 JsonObject *new_obj json_object_new(); for (i 0; sorted[i] ! NULL; i) { JsonNode *node json_object_get_member(obj, sorted[i]); json_object_set_member(new_obj, sorted[i], json_node_copy(node)); // 递归处理嵌套对象 if (JSON_NODE_HOLDS_OBJECT(node)) { JsonObject *child json_node_get_object(node); sort_object_recursive(child); } } // 用新对象替换旧对象的内容 // 实际使用中需要在上层逻辑里替换节点 }逻辑说明这个函数的核心是「先取所有键、排序、再按新顺序重新插入」。js-glib 的JsonObject内部是哈希表遍历顺序和插入顺序无关所以要显式排序。json_node_copy用来复制节点避免指针共享递归调用时只处理类型为JsonObject的子节点数组里的对象也要处理这部分需要额外遍历JsonArray。参数说明g_strdupv生成 NULL 结尾的字符串数组方便统一用g_strcmp0排序。这里的排序是破坏性的会改变对象的成员顺序。如果你的目标是「不做任何改动只改格式」排序这个功能应该做成可选通过插件配置项开关而不是默认开启。Unicode 保留相对简单json-glib 序列化时只要不用json_to_string而是遍历节点自己拼字符串就能保留原始 UTF-8 内容代价是代码量增加所以要评估你的数据里中文和转义字符出现的频率再决定。4. 缩小与验证一行命令的复合工具链格式化是重排版缩小是去掉所有非必要空白和换行验证是判断 JSON 是否合法并指出错误位置。这三个动作可以独立用组合起来就是一个完整的 JSON 处理工作流先验证确认没问题再格式化日常阅读提交前缩小成单行放到配置里。4.1 minify 的两种实现路线和参数选择缩小有两种做法。第一种是解析后重新序列化为紧凑格式json_to_string(root, FALSE)就直接输出无缩进无换行的文本。优点是很稳因为经过了完整解析输出的必然是合法 JSON。缺点是不保留某些数字字面量的原始写法比如1.0可能变1科学计数法也可能被规范化。第二种是纯文本压缩扫描字符流只在字符串外面删除空白字符。这种做法的优点是逻辑简单、速度快缺点是要正确识别字符串遇到带转义引号的字符串容易误删内容。我一般会用第一种理由很实际能过解析器说明内容合法输出虽然可能在数字格式上有轻微变化但语义不变而且不会出现「压缩后反而语法错误」这种离谱情况。缩小后的产物除了放在配置文件里也常用来做日志单行输出。实现很简单改一个参数的事static gchar* minify_json(const gchar *text, gsize length, GError **error) { JsonParser *parser json_parser_new(); JsonNode *root; gchar *result; if (!json_parser_load_from_data(parser, text, length, error)) { g_object_unref(parser); return NULL; } root json_parser_get_root(parser); // FALSE输出紧凑文本没有缩进和额外换行 result json_to_string(root, FALSE); g_object_unref(parser); return result; }逻辑说明和prettify_json的差别只有一个布尔值FALSE表示紧凑序列化。你会注意到这两个函数几乎一模一样的结构实际项目中可以合并成一个函数带布尔参数这里拆开是为了让逻辑更清楚。最后别忘了紧凑输出也不一定就是一行因为字符串内容里可能自带换行符这是合法的不要试图把这些换行也删掉。参数说明如果系统里装了jq用jq -c .做 minify 更省事但插件里不依赖外部命令因为编辑器插件不应该要求用户额外安装工具链。另外有些格式特别紧凑的 JSON 压缩后反而变大因为字符串转义被展开这是正常现象不要误以为算法有 bug。4.2 validate 的反馈方式状态栏、对话框与日志验证是三个功能里最常用、也最需要设计反馈机制的一个。格式化失败时你不能只在日志里打一句parse error就完事用户需要知道错在哪一行、那一行大概什么问题。json-glib 的JsonParser解析失败时GError的message字段里带了行号和列号要做的只是把这些信息展示出来。错误展示方式我建议分三个层级轻量问题用状态栏明确报错用对话框重复出现的同类错误写进 Geany 消息窗口。状态栏适合「不知道有没有问题顺手验一下」的场景对话框适合用户主动点验证按钮时。static void validate_document(GeanyDocument *doc) { gchar *src; gsize len; GError *error NULL; JsonParser *parser json_parser_new(); len sci_get_length(doc-editor-sci); src g_malloc(len 1); sci_get_contents(doc-editor-sci, len 1, src); if (json_parser_load_from_data(parser, src, len, error)) { // 合法状态栏显示绿色提示 ui_set_statusbar(TRUE, NULL, JSON is valid (parsed in %.1f ms), timing_elapsed_ms()); g_free(src); g_object_unref(parser); return; } // 非法从 error 里提取行号并跳转到错误位置 show_error_at_line(doc, error-message); g_free(src); g_object_unref(parser); g_error_free(error); }逻辑说明ui_set_statusbar是 Geany 提供的状态栏接口第一个参数TRUE表示显示为短暂提示会自动在几秒后消失。错误信息提取用正则从字符串里抓行号或者更简单的方法——把整个error-message直接放对话框里。show_error_at_line是自定义函数内部通过sci_goto_line跳转到出错行让用户立刻看到问题上下文。参数说明timing_elapsed_ms是示例函数实际计时用g_get_monotonic_time前后做差即可。json_parser_load_from_data的len参数用-1表示自动检测字符串长度但如果文本里有二进制内容或\0则必须传真实长度这也是这里用sci_get_length而不是strlen的原因。4.3 把三个动作绑到常用键位上功能做完了交互还差一步。Geany 默认的键位绑定通过geany-keybindings组来注册可以把三个动作各分配一个快捷键。先定义按键 ID再在插件初始化时注册。常见的做法是把 CtrlAlt 组合留给插件使用避免覆盖编辑器原生快捷键。static GeanyKeyGroup *key_group; void geany_plugin_init(GeanyPlugin *plugin, gpointer pdata) { // 注册一个名为 json_prettifier 的按键组 key_group plugin_set_key_group(plugin, json_prettifier, KEY_GROUP_SIZE, NULL); // 给三个动作分配 IDdefault 里给出建议键位 keybindings_set_item(key_group, KEY_PRETTIFY, on_prettify, 0, NULL, prettify, Format JSON, GDK_CONTROL_MASK | GDK_MOD1_MASK, GDK_KEY_p); keybindings_set_item(key_group, KEY_MINIFY, on_minify, 0, NULL, minify, Minify JSON, GDK_CONTROL_MASK | GDK_MOD1_MASK, GDK_KEY_m); keybindings_set_item(key_group, KEY_VALIDATE, on_validate, 0, NULL, validate, Validate JSON, GDK_CONTROL_MASK | GDK_MOD1_MASK, GDK_KEY_v); }逻辑说明plugin_set_key_group在插件里建一组可配置按键Geany 的配置界面会为每个按键生成一行用户可以在「按键绑定」里看到并修改。keybindings_set_item的参数里第一个是键组指针第二个是自定义的枚举 ID第三个是回调函数最后两个参数是默认的组合键和键码。这组默认键CtrlAltP/M/V和 Geany 自带快捷键冲突的可能性比较小。参数说明GDK_CONTROL_MASK | GDK_MOD1_MASK表示同时按下 Ctrl 和 AltGDK_KEY_p是键码。KEY_GROUP_SIZE需要在头文件里定义通常是一个枚举常量数值要等于按键个数否则 Geany 遍历按键列表时会越界。5. 避坑记录Geany JSON 插件常见的 5 个翻车现场插件开发最花时间的往往不是功能本身而是那些看着莫名其妙、查半天才知道原因的坑。这里记录五条我在调试中真正遇到过、以及同行反馈过的高频问题。5.1 现象打开 JSON 文件时 Geany 直接崩溃现象描述插件在菜单里点「Prettify JSON」一切正常但某天起打开任何 JSON 文件 Geany 直接闪退命令行里能看到段错误。原因定位崩溃通常不是格式化函数本身而是插件在geany_plugin_init里访问了geany-tools_menu但这个全局指针在插件加载时还没初始化完成。Geany 的插件加载顺序不是确定的如果另一个插件先启动并且修改了菜单结构我们的菜单项插入操作就可能挂在空指针上。另一个常见原因是PluginInfo结构里的version数组没有初始化完全字段缺省导致越界读。解决方法把所有 GUI 操作从geany_plugin_init挪到geany_plugin_set_info完成后的第一次geany_plugin_init内部延迟执行或者使用geany-main_window初始化后置信号。更稳的办法是注册 Geany 的document-open信号在第一个文件打开时才创建菜单项避开插件加载的竞态区间。5.2 现象格式化后中文全部变成 \uXXXX 转义现象描述一段包含名称: 测试的 JSON格式化之后变成\u540d\u79f0: \u6d4b\u8bd5内容没变但人完全看不懂。原因定位json-glib 的json_to_string在序列化时默认对非 ASCII 字符做转义输出这是为了兼容某些老式传输场景做的保守选择。这不算法 bug但在这个编辑器插件场景下体验极差。关键是网络上一半教程会告诉你用json_to_string没人提它有这个输出偏好。解决方法需要绕开json_to_string自己遍历JsonNode树对字符串节点直接用json_node_get_string取原始 UTF-8 文本拼接。路径是写一个递归的序列化函数字段名加引号冒号字符串值直接输出不经过转义。代价是代码量多几十行但效果是中文原样保留。另外记得处理字符串值内部的引号和反斜杠——不能无脑原样拼要手动转义和\\。5.3 现象多行字符串格式化后语义不变但人看不懂现象描述一个 JSON 里某个字段值是带\n的完整日志文本格式化后所有换行都变成了\n的字面量折叠成一行阅读起来极其痛苦。原因定位JSON 标准里字符串就是不能有真实换行格式化工具遵守这个规则没问题。但是用户预期是「格式化后更易读」看到一堆\n挤在一行里反而更难读。这与配置文件里的长文本字段是高频冲突点。解决方法在格式化时检测字符串节点里的转义换行如果发现\n且当前输出上下文允许可以把这个字段单独放一个段落或者提示用户这类字段适合用jq之类的工具做提取。不要试图在格式化输出里把\n还原成真实换行那会产生非法 JSON。更实际的做法是在插件配置里加一个「折叠超长字符串」选项超过 120 字符的字符串值显示为(lengthN)的占位鼠标悬停才显示完整内容。5.4 现象损坏的 JSON 文件格式化后直接清空现象描述文件内容是{a: 1, a: 2}格式化之后编辑缓冲区被清空或者只留下一个空对象。原因定位json-glib 对重复键的处理比较激进后一个键会覆盖前一个并且序列化时只保留一个。更危险的是某些损坏场景下json_parser_get_root返回的节点指针不可以在解析器释放后继续使用如果格式化函数和主逻辑之间没有正确复制节点就会产生悬垂指针表现就是输出内容随机清空。解决方法格式化前先做一次静态检查发现重复键直接报错而不是「自动修复」。做法是在遍历JsonObject时用一个GHashTable记录已见过的键遇到重复就向GError写入信息。核心原则是格式化工具不应当默默修改数据内容一旦检测到语义冲突应当停下来让用户决定如何处理。5.5 现象大文件卡死UI 无响应现象描述格式化一个 20 MB 的 JSON 文件时Geany 界面冻住十几秒期间无法滚动、无法切换文件点击任何地方都没反应。原因定位格式化逻辑在 Geany 的主线程GTK 事件循环里执行JavaScript 和前端领域有 Web Worker 概念可以避开GTK 程序默认没有。解析 20 MB 文本和重新序列化都是 CPU 密集操作一次性做完必然卡界面。解决方法在格式化前检查文件大小超过 1 MB 的文件弹提示让用户确认。如果做了确认仍然卡可以把格式化操作放到 GLib 的线程池里完成后通过g_idle_add把结果传回主线程更新 UI。注意 Scintilla 的缓冲区操作必须在主线程完成不能在线程里直接改编辑器内容。6. 进阶技巧把插件做成「验证 跳转」的闭环工具基础功能都有了接下来值得花时间的是把验证结果和编辑器行为绑在一起。长期以来我养成的习惯是保存 JSON 文件前先让插件自动验证一遍有错直接跳到出错行而不是等日志输出报错再回头找。这个闭环用 Geany 的editor-notify信号实现文件保存前触发校验。实现思路不复杂核心只有一段信号处理逻辑注册document-before-save信号回调里取当前文档内容做解析如果出错就中断保存并把光标定位到错误行。这样相当于给 JSON 文件上了一道编译检查。虽然 Geany 不强制你这么做但这个习惯能省下大量和「配置文件写错导致服务起不来」的纠缠时间。另一个投入产出比很高的功能是选区格式化。选中一段 JSON 片段只对选区做格式化和验证而不是整份文档。实现上要处理一个边界问题选区的起点和终点可能落在字符串中间直接解析必然失败。我的做法是先检查选区边界如果边界在字符串内部就把选区扩大直到覆盖完整的 JSON 值。这个判断依赖于对选区前后引号的配对分析细节多但做完了很顺手日常调试配置文件里的嵌套结构时能频繁用到。回头总结来说这个插件最关键的设计决策一个是用 json-glib 而不是手写解析器另一个是格式化永远不修改语义只动排版。格式化工具做久了会发现很多需求不是「格式化」而是「重新整理」用户真正想要的是在一个键值对很乱的文件里快速定位某个字段。为这个需求我在插件里加了一个简单的大纲视图解析成功后把所有键路径列在侧边栏点击键路径跳转到对应行。这个小功能比好看的缩进更受欢迎。希望这个方向能帮到你。如果你准备动手写自己的版本记住一条我踩过的教训先写验证功能再做格式化验证是格式化正确性的前提顺序反了后面每一步排错都会变成玄学。本文还有配套的精品资源点击获取 
长河君 · 2026/10/10 20:44:09 · 阅读 1.2k Geany插件开发实战：打造JSON格式化与验证工具
简介这是一份面向 Geany 编辑器用户的 JSON 处理插件源码包定位为 JSON Prettifier 的独立实现可手动集成进 Geany用于对未格式化或压缩过的 JSON 文件进行美化、缩小和语法校验。插件支持全文或选区格式化、按实体拆分处理校验范围可设为全部或部分内容并支持正斜杠转义与缩进风格自定义在 Linux 环境下通过编译安装即可使用。资源共 176 个文件压缩包大小仅 163KB主体为 C 源码与头文件配以 json 测试样例、gold 预期结果、txt 说明及 cmake 等构建配置便于学习插件开发与调试。目前已有 402 人学习下载。借助源码和测试数据读者可掌握 yajl 解析库的封装用法、Geany 插件接口的编写流程也能理解 JSON 词法/语法分析在编辑器中的落地方式并在此基础上调整缩进策略或扩展 JSON5 等变体支持适合有志于扩展 Geany 功能的开发者参考。1. 为什么要在 Geany 里处理 JSON一个配置文件的惨案现场你大概也经历过这种时刻手改一个 JSON 配置文件多加了一个逗号或者把某个字符串的引号写成了中文引号保存后程序启动直接报错日志里只有一行parse error连行号都不给。你打开编辑器看了半天眼睛都花了也找不到问题在哪。这就是我们要聊聊的 Geany-JSON-Prettifier一个跑在 Geany 编辑器里的 JSON 格式化、美化和验证插件。它能在你按下一个快捷键后把乱七八糟的 JSON 排版成标准缩进格式顺手告诉你语法对不对、错在第几行。适合每天和配置文件、API 响应、数据交换打交道的开发者也适合把 Geany 当主力编辑器、不想为一个小功能再装一个 IDE 的人。2. 先看懂 Geany 插件的底裤插件结构、生命周期和选型取舍写插件之前得先认识到 Geany 不是那种开箱即用、自带插件 SDK 的编辑器。它是一套 C 语言写的轻量编辑器插件通过动态库加载注册回调函数到编辑器的事件循环里。没有 GUI 拖拽配置没有脚手架命令一切从geanyplugin.h这个头文件开始。2.1 Geany 插件到底长什么样入口、上下文与回调Geany 插件本质上就是一个编译成.so的动态库导出三个固定符号geany_plugin_set_info、geany_plugin_init和geany_plugin_cleanup。编辑器启动时扫描插件目录用dlopen加载这些库然后调geany_plugin_init完成初始化。先看最小骨架文件json_prettifier.c#include geanyplugin.h #include json_prettifier.h // 插件元信息Geany 在帮助/插件管理器里展示 PluginInfo geany_plugin_info { .name JSON Prettifier, .description Format, minify and validate JSON documents, .version {1, 0, 0}, .author Your Name }; // 工具菜单项的回调 static void on_prettify(GtkWidget *widget, gpointer data) { // 核心逻辑在之后实现 geany_debug(Prettify triggered); } void geany_plugin_init(GeanyPlugin *plugin, gpointer pdata) { GtkWidget *menu_item gtk_menu_item_new_with_label(Prettify JSON); g_signal_connect(menu_item, activate, G_CALLBACK(on_prettify), NULL); gtk_container_add(GTK_CONTAINER(geany-tools_menu), menu_item); gtk_widget_show(menu_item); plugin-priv menu_item; } void geany_plugin_cleanup(GeanyPlugin *plugin, gpointer pdata) { // 菜单项在插件卸载时由 Geany 框架统一回收这里一般留空 }逻辑说明geany_plugin_info是静态元数据Geany 的插件管理器读它做列表展示geany_plugin_init里做两件事——创建一个菜单项塞进 Geany 的「工具」菜单以及把菜单项指针存到plugin-priv方便后续清理时释放。geany_plugin_cleanup用于卸载时回收资源这个插件里菜单项由 GTK 父容器管理可以不手动销毁。参数说明PluginInfo.version是三个整数组成的版本号geany-debug是 Geany 提供的调试输出接口信息会打到 Geany 的日志面板比printf靠谱得多因为这日志能看到插件加载时间、编译选项这些上下文。2.2 为什么用 C 写而不是用外部脚本你可能会想Geany 明明支持「外部工具」直接调用jq、python -m json.tool不就行了确实可以但差别很大。外部工具方案每次执行都要起一个子进程选中的文本传进去、输出再读回来一来一回至少几百毫秒而且没法做细粒度的交互——比如错误定位到行号、在状态栏常驻验证结果、对选区做局部格式化。插件方案把这些动作全部压进编辑器进程内数据不用过管道关键是能拿到 Geany 内部的文档对象模型直接操作缓冲区。性能上也有考量。格式化一个几百 KB 的 JSON外部脚本从启动解释器到出结果要一两秒而 C 里调用 json-glib 的解析器整个过程不到几十毫秒。需要反复试参数、调缩进风格的时候这个差距体感非常明显。另一个决策点是 JSON 解析库。Geany 依赖 GLib 和 GTK而 json-glib 是 GLib 生态里的官方 JSON 库无需额外引入重量级依赖系统里通常已经装好了。这样编译插件时只需要链接json-glib-1.0不需要手写递归下降解析器。少一个自己维护的解析器就少一片出 bug 的土壤。2.3 搭建最小可编译插件骨架先跑通一个菜单项有了代码骨架还得知道怎么编译。Geany 插件用的构建方式是pkg-config找依赖路径再通过 CMake 或纯 Makefile 生成动态库。这里用最直白的 Makefile 演示依赖关系CC ? gcc PKG_CONFIG ? pkg-config # 找 Geany 和 json-glib 的头文件与库路径 GEANY_CFLAGS : $(shell $(PKG_CONFIG) --cflags geany) GEANY_LIBS : $(shell $(PKG_CONFIG) --libs geany) JSON_CFLAGS : $(shell $(PKG_CONFIG) --cflags json-glib-1.0) JSON_LIBS : $(shell $(PKG_CONFIG) --libs json-glib-1.0) PLUGIN_CFLAGS -fPIC -Wall -Wextra $(GEANY_CFLAGS) $(JSON_CFLAGS) PLUGIN_LIBS $(GEANY_LIBS) $(JSON_LIBS) json_prettifier.so: json_prettifier.c json_prettifier.h $(CC) -shared $(PLUGIN_CFLAGS) $ -o $ $(PLUGIN_LIBS) install: cp json_prettifier.so ~/.config/geany/plugins/逻辑说明-shared告诉编译器产出动态库-fPIC生成位置无关代码这是动态库的硬性要求。pkg-config --cflags geany会展开成类似-I/usr/include/geany -I/usr/include/geany/scintilla的路径这是能找到geanyplugin.h的前提。~/.config/geany/plugins/是用户级插件目录Linux 下 Geany 启动时会自动扫描这个目录不需要 root 权限适合日常调试。参数说明-Wall -Wextra建议保留Geany 插件开发里最常见的翻车就是回调函数签名不一致这两个开关能提前暴露大部分类型警告。GEANY_LIBS链接的其实只有glib-2.0Geany 本身不导出太多符号真正的接口都在头文件里用宏展开。编译后重启 Geany打开插件管理器如果列表里出现了JSON Prettifier说明骨架已经跑通。这一步是整个插件开发里最磨人的卡住的人很多是pkg-config找不到geany.pc文件——常见原因是系统里只装了geany没装geany-dev或对应的开发包。3. 格式化与美化的核心实现缩进、排序与 Unicode 处理骨架跑通只是第一步真正的核心在工具栏按钮背后那几百行逻辑里。格式化不是简单地把{换行加两个空格而是要处理好字符串里的特殊字符、数组和对象的嵌套层级、以及 JSON 标准里那些让人崩溃的边界情况。3.1 用 json-glib 做解析别手写状态机我见过某开发者自己写了一个基于字符扫描的格式化器最初几百行跑起来挺正常后来遇到一个 JSON 字符串里带{a:b}这种嵌套引号就彻底乱套。这就是典型的「手写状态机陷阱」JSON 的字符串字面量里允许出现任意字符包括大括号、引号被转义的、换行符不用完整词法分析根本判断不了哪个}是真的结构结束符。所以第一准则解析工作全部交给 json-glib。它提供JsonParser能够把文本解析成JsonNode树之后格式化就是一次树的遍历。看核心函数static gchar* prettify_json(const gchar *text, gsize length, GError **error) { JsonParser *parser json_parser_new(); JsonNode *root; gchar *result; // 解析输入文本出错时 error 会被填充 if (!json_parser_load_from_data(parser, text, length, error)) { g_object_unref(parser); return NULL; } root json_parser_get_root(parser); if (root NULL) { g_set_error(error, G_IO_ERROR, G_IO_ERROR_INVALID_DATA, No JSON content found); g_object_unref(parser); return NULL; } // json-glib 自带序列化器indent 参数控制缩进 result json_to_string(root, TRUE); g_object_unref(parser); return result; }逻辑说明json_parser_load_from_data是核心入口它接受原始文本和长度内部完成真正的词法分析和语法分析。如果输入不合法函数返回FALSE并且填充GError这个GError里带了具体的错误位置——后面做验证功能就是从这里拿行号的。json_parser_get_root取出树的根节点之后json_to_string把节点树重新序列化成文本第二个参数TRUE表示输出美化过的带缩进格式。参数说明json_to_string的缩进是固定的两个空格不能直接设置成 4 个空格这是 json-glib 的 API 限制。要改缩进风格得先拿到序列化文本再全局替换\n里的空格前缀稍后在 3.3 里再说怎么做。error参数必须传NULL或者一个初始化的GError *否则解析失败时直接内存泄漏。3.2 prettify 主流程解析→重排版→回写缓冲区格式化前后要有一个清晰的缓冲区读写流程。Geany 里操作文本依赖 Scintilla 编辑组件通过sci_get_text取全文替换内容则用sci_set_text。这里需要额外注意一件事操作前必须保存当前的撤销栈状态否则用户按一次撤销会奇迹般地把整个格式化结果全部撤销掉而不是只撤销一步。看完整的回调实现static void on_prettify(GtkWidget *widget, gpointer data) { GeanyDocument *doc document_get_current(); gchar *src, *formatted; gsize len; GError *error NULL; if (doc NULL || doc-editor NULL) return; // 第一步取出编辑器全部内容 len sci_get_length(doc-editor-sci); src g_malloc(len 1); sci_get_contents(doc-editor-sci, len 1, src); // 第二步格式化 formatted prettify_json(src, len, error); g_free(src); if (error ! NULL) { // 弹对话框提示用户错误位置 show_parse_error(doc, error); g_error_free(error); return; } // 第三步替换内容前进入撤销分组 sci_start_undo_group(doc-editor-sci); sci_set_text(doc-editor-sci, formatted); sci_end_undo_group(doc-editor-sci); g_free(formatted); }逻辑说明sci_get_length和sci_get_contents是老搭档先问长度再按长度取数据避免自己猜缓冲区大小。sci_start_undo_group和sci_end_undo_group是 Scintilla 的分组撤销机制把一次全文替换包进去这样用户 CtrlZ 一次就能退回原始内容不会撤销到一半看到残缺文本。参数说明sci_get_contents的第二个参数必须是缓冲区大小包含结尾的空字符所以分配时要len 1这是 Scintilla API 的经典陷阱。formatted返回的是新分配的内存用完必须释放否则长时间使用编辑器内存会肉眼可见地增长。3.3 处理特殊需求键排序、数组缩进、Unicode 保留基础格式化跑通后你会遇到真实世界里的需求。比如说某个接口返回的 JSON 键顺序是乱的你想按字母序排列方便 diff再比如团队规范要求 4 空格缩进json-glib 默认 2 空格还有最关键的一点中文内容格式化后不能被转义成\uXXXX否则人眼完全没法看。这三个问题可以集中解决。键排序在解析之后、序列化之前做递归遍历JsonObject把键排序后重新组装缩进风格在序列化之后做字符串处理Unicode 转义的问题则需要换一个函数。看这个递归排序的实现思路static void sort_object_recursive(JsonObject *obj) { GList *keys, *iter; gchar **key_array, **sorted; guint i, n; n json_object_get_size(obj); if (n 2) return; // 取出所有键并排序 key_array g_new0(gchar *, n 1); keys json_object_get_members(obj); i 0; for (iter keys; iter ! NULL; iter iter-next) { key_array[i] g_strdup((const gchar *)iter-data); } sorted g_strdupv(key_array); // 把键数组按 strcmp 排序 // 这里用 GLib 的排序函数注意只排键不排值 // 重建新对象按排序后的键插入 JsonObject *new_obj json_object_new(); for (i 0; sorted[i] ! NULL; i) { JsonNode *node json_object_get_member(obj, sorted[i]); json_object_set_member(new_obj, sorted[i], json_node_copy(node)); // 递归处理嵌套对象 if (JSON_NODE_HOLDS_OBJECT(node)) { JsonObject *child json_node_get_object(node); sort_object_recursive(child); } } // 用新对象替换旧对象的内容 // 实际使用中需要在上层逻辑里替换节点 }逻辑说明这个函数的核心是「先取所有键、排序、再按新顺序重新插入」。js-glib 的JsonObject内部是哈希表遍历顺序和插入顺序无关所以要显式排序。json_node_copy用来复制节点避免指针共享递归调用时只处理类型为JsonObject的子节点数组里的对象也要处理这部分需要额外遍历JsonArray。参数说明g_strdupv生成 NULL 结尾的字符串数组方便统一用g_strcmp0排序。这里的排序是破坏性的会改变对象的成员顺序。如果你的目标是「不做任何改动只改格式」排序这个功能应该做成可选通过插件配置项开关而不是默认开启。Unicode 保留相对简单json-glib 序列化时只要不用json_to_string而是遍历节点自己拼字符串就能保留原始 UTF-8 内容代价是代码量增加所以要评估你的数据里中文和转义字符出现的频率再决定。4. 缩小与验证一行命令的复合工具链格式化是重排版缩小是去掉所有非必要空白和换行验证是判断 JSON 是否合法并指出错误位置。这三个动作可以独立用组合起来就是一个完整的 JSON 处理工作流先验证确认没问题再格式化日常阅读提交前缩小成单行放到配置里。4.1 minify 的两种实现路线和参数选择缩小有两种做法。第一种是解析后重新序列化为紧凑格式json_to_string(root, FALSE)就直接输出无缩进无换行的文本。优点是很稳因为经过了完整解析输出的必然是合法 JSON。缺点是不保留某些数字字面量的原始写法比如1.0可能变1科学计数法也可能被规范化。第二种是纯文本压缩扫描字符流只在字符串外面删除空白字符。这种做法的优点是逻辑简单、速度快缺点是要正确识别字符串遇到带转义引号的字符串容易误删内容。我一般会用第一种理由很实际能过解析器说明内容合法输出虽然可能在数字格式上有轻微变化但语义不变而且不会出现「压缩后反而语法错误」这种离谱情况。缩小后的产物除了放在配置文件里也常用来做日志单行输出。实现很简单改一个参数的事static gchar* minify_json(const gchar *text, gsize length, GError **error) { JsonParser *parser json_parser_new(); JsonNode *root; gchar *result; if (!json_parser_load_from_data(parser, text, length, error)) { g_object_unref(parser); return NULL; } root json_parser_get_root(parser); // FALSE输出紧凑文本没有缩进和额外换行 result json_to_string(root, FALSE); g_object_unref(parser); return result; }逻辑说明和prettify_json的差别只有一个布尔值FALSE表示紧凑序列化。你会注意到这两个函数几乎一模一样的结构实际项目中可以合并成一个函数带布尔参数这里拆开是为了让逻辑更清楚。最后别忘了紧凑输出也不一定就是一行因为字符串内容里可能自带换行符这是合法的不要试图把这些换行也删掉。参数说明如果系统里装了jq用jq -c .做 minify 更省事但插件里不依赖外部命令因为编辑器插件不应该要求用户额外安装工具链。另外有些格式特别紧凑的 JSON 压缩后反而变大因为字符串转义被展开这是正常现象不要误以为算法有 bug。4.2 validate 的反馈方式状态栏、对话框与日志验证是三个功能里最常用、也最需要设计反馈机制的一个。格式化失败时你不能只在日志里打一句parse error就完事用户需要知道错在哪一行、那一行大概什么问题。json-glib 的JsonParser解析失败时GError的message字段里带了行号和列号要做的只是把这些信息展示出来。错误展示方式我建议分三个层级轻量问题用状态栏明确报错用对话框重复出现的同类错误写进 Geany 消息窗口。状态栏适合「不知道有没有问题顺手验一下」的场景对话框适合用户主动点验证按钮时。static void validate_document(GeanyDocument *doc) { gchar *src; gsize len; GError *error NULL; JsonParser *parser json_parser_new(); len sci_get_length(doc-editor-sci); src g_malloc(len 1); sci_get_contents(doc-editor-sci, len 1, src); if (json_parser_load_from_data(parser, src, len, error)) { // 合法状态栏显示绿色提示 ui_set_statusbar(TRUE, NULL, JSON is valid (parsed in %.1f ms), timing_elapsed_ms()); g_free(src); g_object_unref(parser); return; } // 非法从 error 里提取行号并跳转到错误位置 show_error_at_line(doc, error-message); g_free(src); g_object_unref(parser); g_error_free(error); }逻辑说明ui_set_statusbar是 Geany 提供的状态栏接口第一个参数TRUE表示显示为短暂提示会自动在几秒后消失。错误信息提取用正则从字符串里抓行号或者更简单的方法——把整个error-message直接放对话框里。show_error_at_line是自定义函数内部通过sci_goto_line跳转到出错行让用户立刻看到问题上下文。参数说明timing_elapsed_ms是示例函数实际计时用g_get_monotonic_time前后做差即可。json_parser_load_from_data的len参数用-1表示自动检测字符串长度但如果文本里有二进制内容或\0则必须传真实长度这也是这里用sci_get_length而不是strlen的原因。4.3 把三个动作绑到常用键位上功能做完了交互还差一步。Geany 默认的键位绑定通过geany-keybindings组来注册可以把三个动作各分配一个快捷键。先定义按键 ID再在插件初始化时注册。常见的做法是把 CtrlAlt 组合留给插件使用避免覆盖编辑器原生快捷键。static GeanyKeyGroup *key_group; void geany_plugin_init(GeanyPlugin *plugin, gpointer pdata) { // 注册一个名为 json_prettifier 的按键组 key_group plugin_set_key_group(plugin, json_prettifier, KEY_GROUP_SIZE, NULL); // 给三个动作分配 IDdefault 里给出建议键位 keybindings_set_item(key_group, KEY_PRETTIFY, on_prettify, 0, NULL, prettify, Format JSON, GDK_CONTROL_MASK | GDK_MOD1_MASK, GDK_KEY_p); keybindings_set_item(key_group, KEY_MINIFY, on_minify, 0, NULL, minify, Minify JSON, GDK_CONTROL_MASK | GDK_MOD1_MASK, GDK_KEY_m); keybindings_set_item(key_group, KEY_VALIDATE, on_validate, 0, NULL, validate, Validate JSON, GDK_CONTROL_MASK | GDK_MOD1_MASK, GDK_KEY_v); }逻辑说明plugin_set_key_group在插件里建一组可配置按键Geany 的配置界面会为每个按键生成一行用户可以在「按键绑定」里看到并修改。keybindings_set_item的参数里第一个是键组指针第二个是自定义的枚举 ID第三个是回调函数最后两个参数是默认的组合键和键码。这组默认键CtrlAltP/M/V和 Geany 自带快捷键冲突的可能性比较小。参数说明GDK_CONTROL_MASK | GDK_MOD1_MASK表示同时按下 Ctrl 和 AltGDK_KEY_p是键码。KEY_GROUP_SIZE需要在头文件里定义通常是一个枚举常量数值要等于按键个数否则 Geany 遍历按键列表时会越界。5. 避坑记录Geany JSON 插件常见的 5 个翻车现场插件开发最花时间的往往不是功能本身而是那些看着莫名其妙、查半天才知道原因的坑。这里记录五条我在调试中真正遇到过、以及同行反馈过的高频问题。5.1 现象打开 JSON 文件时 Geany 直接崩溃现象描述插件在菜单里点「Prettify JSON」一切正常但某天起打开任何 JSON 文件 Geany 直接闪退命令行里能看到段错误。原因定位崩溃通常不是格式化函数本身而是插件在geany_plugin_init里访问了geany-tools_menu但这个全局指针在插件加载时还没初始化完成。Geany 的插件加载顺序不是确定的如果另一个插件先启动并且修改了菜单结构我们的菜单项插入操作就可能挂在空指针上。另一个常见原因是PluginInfo结构里的version数组没有初始化完全字段缺省导致越界读。解决方法把所有 GUI 操作从geany_plugin_init挪到geany_plugin_set_info完成后的第一次geany_plugin_init内部延迟执行或者使用geany-main_window初始化后置信号。更稳的办法是注册 Geany 的document-open信号在第一个文件打开时才创建菜单项避开插件加载的竞态区间。5.2 现象格式化后中文全部变成 \uXXXX 转义现象描述一段包含名称: 测试的 JSON格式化之后变成\u540d\u79f0: \u6d4b\u8bd5内容没变但人完全看不懂。原因定位json-glib 的json_to_string在序列化时默认对非 ASCII 字符做转义输出这是为了兼容某些老式传输场景做的保守选择。这不算法 bug但在这个编辑器插件场景下体验极差。关键是网络上一半教程会告诉你用json_to_string没人提它有这个输出偏好。解决方法需要绕开json_to_string自己遍历JsonNode树对字符串节点直接用json_node_get_string取原始 UTF-8 文本拼接。路径是写一个递归的序列化函数字段名加引号冒号字符串值直接输出不经过转义。代价是代码量多几十行但效果是中文原样保留。另外记得处理字符串值内部的引号和反斜杠——不能无脑原样拼要手动转义和\\。5.3 现象多行字符串格式化后语义不变但人看不懂现象描述一个 JSON 里某个字段值是带\n的完整日志文本格式化后所有换行都变成了\n的字面量折叠成一行阅读起来极其痛苦。原因定位JSON 标准里字符串就是不能有真实换行格式化工具遵守这个规则没问题。但是用户预期是「格式化后更易读」看到一堆\n挤在一行里反而更难读。这与配置文件里的长文本字段是高频冲突点。解决方法在格式化时检测字符串节点里的转义换行如果发现\n且当前输出上下文允许可以把这个字段单独放一个段落或者提示用户这类字段适合用jq之类的工具做提取。不要试图在格式化输出里把\n还原成真实换行那会产生非法 JSON。更实际的做法是在插件配置里加一个「折叠超长字符串」选项超过 120 字符的字符串值显示为(lengthN)的占位鼠标悬停才显示完整内容。5.4 现象损坏的 JSON 文件格式化后直接清空现象描述文件内容是{a: 1, a: 2}格式化之后编辑缓冲区被清空或者只留下一个空对象。原因定位json-glib 对重复键的处理比较激进后一个键会覆盖前一个并且序列化时只保留一个。更危险的是某些损坏场景下json_parser_get_root返回的节点指针不可以在解析器释放后继续使用如果格式化函数和主逻辑之间没有正确复制节点就会产生悬垂指针表现就是输出内容随机清空。解决方法格式化前先做一次静态检查发现重复键直接报错而不是「自动修复」。做法是在遍历JsonObject时用一个GHashTable记录已见过的键遇到重复就向GError写入信息。核心原则是格式化工具不应当默默修改数据内容一旦检测到语义冲突应当停下来让用户决定如何处理。5.5 现象大文件卡死UI 无响应现象描述格式化一个 20 MB 的 JSON 文件时Geany 界面冻住十几秒期间无法滚动、无法切换文件点击任何地方都没反应。原因定位格式化逻辑在 Geany 的主线程GTK 事件循环里执行JavaScript 和前端领域有 Web Worker 概念可以避开GTK 程序默认没有。解析 20 MB 文本和重新序列化都是 CPU 密集操作一次性做完必然卡界面。解决方法在格式化前检查文件大小超过 1 MB 的文件弹提示让用户确认。如果做了确认仍然卡可以把格式化操作放到 GLib 的线程池里完成后通过g_idle_add把结果传回主线程更新 UI。注意 Scintilla 的缓冲区操作必须在主线程完成不能在线程里直接改编辑器内容。6. 进阶技巧把插件做成「验证 跳转」的闭环工具基础功能都有了接下来值得花时间的是把验证结果和编辑器行为绑在一起。长期以来我养成的习惯是保存 JSON 文件前先让插件自动验证一遍有错直接跳到出错行而不是等日志输出报错再回头找。这个闭环用 Geany 的editor-notify信号实现文件保存前触发校验。实现思路不复杂核心只有一段信号处理逻辑注册document-before-save信号回调里取当前文档内容做解析如果出错就中断保存并把光标定位到错误行。这样相当于给 JSON 文件上了一道编译检查。虽然 Geany 不强制你这么做但这个习惯能省下大量和「配置文件写错导致服务起不来」的纠缠时间。另一个投入产出比很高的功能是选区格式化。选中一段 JSON 片段只对选区做格式化和验证而不是整份文档。实现上要处理一个边界问题选区的起点和终点可能落在字符串中间直接解析必然失败。我的做法是先检查选区边界如果边界在字符串内部就把选区扩大直到覆盖完整的 JSON 值。这个判断依赖于对选区前后引号的配对分析细节多但做完了很顺手日常调试配置文件里的嵌套结构时能频繁用到。回头总结来说这个插件最关键的设计决策一个是用 json-glib 而不是手写解析器另一个是格式化永远不修改语义只动排版。格式化工具做久了会发现很多需求不是「格式化」而是「重新整理」用户真正想要的是在一个键值对很乱的文件里快速定位某个字段。为这个需求我在插件里加了一个简单的大纲视图解析成功后把所有键路径列在侧边栏点击键路径跳转到对应行。这个小功能比好看的缩进更受欢迎。希望这个方向能帮到你。如果你准备动手写自己的版本记住一条我踩过的教训先写验证功能再做格式化验证是格式化正确性的前提顺序反了后面每一步排错都会变成玄学。本文还有配套的精品资源点击获取