DBeaver 原生 JSON 导出器不支持嵌套结构，因其仅将结果集扁平化为 JSON 对象数组，不解析 JSON 类型字段、不处理 JOIN 聚合，需在 SQL 层用数据库特有函数（如 PostgreSQL 的 json_build_object）预先构造嵌套。
不能直接导出嵌套 JSON 结构——DBeaver 原生导出器只支持扁平化行转 JSON 对象数组，不解析或生成嵌套对象/数组。
为什么 DBeaver 的 JSON 导出器不处理嵌套字段
DBeaver 的 DataExporterJSON 是按“结果集 → JSON 数组”设计的：每行数据映射为一个 JSON 对象，字段名即键名，值即单元格内容。它不识别数据库中的 JSON 类型字段内容结构，也不支持 JOIN 后自动聚合成树形结构。
- 即使源表某列是 PostgreSQL 的
jsonb或 MySQL 5.7+ 的JSON类型，导出时仍被当作字符串处理（双引号包裹的原始文本） - 没有“按外键自动嵌套”“按字段前缀分组为子对象”等配置项
- 官方 exporter 源码中无递归遍历、无 schema 推断逻辑，纯基于 ResultSetMetaData 逐列取值
想导出嵌套 JSON，得先在 SQL 层构造好
真正可行的做法，是把嵌套逻辑下推到数据库查询里，让 DBeaver 导出的只是“已经嵌套好的结果”。不同数据库语法差异大，关键点如下：
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- PostgreSQL：用
json_build_object()、json_agg()、to_jsonb()组合，例如：SELECT u.id, u.name, json_agg( json_build_object('id', o.id, 'amount', o.total) ) AS orders FROM users u JOIN orders o ON u.id = o.user_id GROUP BY u.id, u.name; - MySQL 8.0+：用
JSON_OBJECT()、JSON_ARRAYAGG()，注意别漏掉CAST防止 null 被跳过 - SQL Server：用
FOR JSON AUTO或FOR JSON PATH，但导出时需勾选“导出查询结果”而非“导出表”，否则忽略 FOR JSON 子句 - 通用避坑：确保查询结果列名不含空格或特殊字符，否则 JSON 键名会带引号且难读；避免别名重复，否则导出 JSON 会出现同名覆盖
导出时 JSON 格式选项的关键设置
即使 SQL 已构造好嵌套结构，导出环节仍有三个参数直接影响最终 JSON 可读性与兼容性：
- 勾选
Format output (pretty-print)：开启后生成带缩进的多行 JSON，方便人工阅读；关闭则为单行，适合传输或 API 消费 - 设置
nullString为null（而非空字符串）：否则数据库里的 NULL 会被转成"null"字符串，破坏 JSON 类型语义 - 编码必须选
UTF-8：尤其含中文字段时，否则嵌套 JSON 内部的字符串可能乱码，且部分解析器会直接拒收
替代方案：用 CSV + 外部脚本重组嵌套结构
如果数据库不支持 JSON 函数（如 SQLite、旧版 MySQL），或查询太复杂无法在 SQL 层完成嵌套，可走“导出 CSV → Python/Node.js 脚本加工”路径：
- 用 DBeaver 导出带前缀的扁平字段，例如：
user_id、user_name、order_id、order_amount - Python 示例用
pandas.read_csv()读入，再用groupby("user_id").apply(lambda x: x[["order_id","order_amount"]].to_dict("records"))生成嵌套字典 - 注意 CSV 导出时分隔符设为
\t，避免字段内逗号干扰解析；引号字符设为"，确保字符串安全包裹
嵌套不是导出功能的问题，而是数据建模和查询表达的责任边界——DBeaver 只负责忠实传递结果集，谁构造了嵌套，谁就得在 SQL 或后续环节把它立住。
