接口返回一堆 JSON，业务方要的是 Excel。中间这一步就是扁平化 —— 把嵌套的对象压成二维表。JSON 格式化 的 JSON 转 CSV 遵循三条固定规则，看懂它们就知道转出来为什么长那样。

三条扁平化规则

一、嵌套键用 a.b.c 路径做列名。 {"user":{"name":"张"},"id":1} 会产出 user.name 与 id 两列，而不是把整个 user 对象塞进一个单元格。列名里带点，接手的人一看就知道原来是嵌套的。

二、所有对象的键取并集。 十条记录里有一条多了 remark 字段，最终表格就会有 remark 这一列，不会因为「第一条没有」就丢掉这一列。这是最容易出问题的地方：一条脏数据就会给整表加一列。

三、缺失值留空。 某条记录没有该字段，对应单元格留空，不会填 null、0 或空字符串占位。统计时注意区分「空值」与「真的没数据」。

非对象数组输出单列。 如果数据是 [1,2,3] 或 ["a","b"] 这种一维数组，结果就是一列 —— 先确认你的根节点是数组还是对象包着数组。

两种一定会错列的数据

数组里套数组。 一条记录的 tags 是数组，多值无法压进一个单元格。转出来会把数组整个序列化成文本塞进一格。要规范的做法是先转成 CSV，再用 Excel 的分列或回 JSON 侧改成拼接字符串。

同一层键名大小写不一致。 Name 与 name 会被当成两列。并集规则不做大小写归一，所以源头要统一。

转完之后还要做两件事

第一是修编码。 CSV 双击打开中文乱码，是因为文件没有 BOM。CSV 转换 可以导出带 BOM 的 UTF-8（文件开头写入 EF BB BF），Excel 双击就不乱；接收方是程序时反而要选无 BOM。原理见 CSV 打开中文乱码怎么修？分清 UTF-8 和 GBK 就一次搞定。

第二是查长编号。 转进 Excel 后 18 位身份证号、订单号尾数会变成 0 —— 那是 Excel 只保 15 位有效数字，不是转错了。双击打开 CSV 一定会踩这个坑，可靠做法是走 Excel 的「数据 → 从文本/CSV」导入，并把该列的类型指定为文本。站内规则与此相关的设计见 图片转 Excel 后数字不能求和？按文本写入是故意的。

列多而只要几列时，CSV 转换页能勾选保留哪些列并调整先后顺序，比在 Excel 里删列安全 —— 它遵循 RFC4180，引号内的逗号与换行不会被误判成边界。

两个明确的边界

不做 JSON Schema 校验。 JSON 格式化页只检查语法是否合法，字段类型、必填项对不对不在能力范围内。

反方向不在这一页。 CSV 转 JSON、提取表头在 CSV 转换，它支持首行做键名输出对象数组，或不映射键名输出二维数组；空表头会补成 column3 这类列名，重复表头自动加 _2、_3 后缀。XML 又是另一页，见 XML 转 JSON 后属性变成 @、文字变成 #text：规则是固定的。

全程在浏览器本地完成，数据不上传服务器，所以接口样例和用户数据都可以直接粘。