接口返回的 JSON 复制到 Excel，是很多人每天都要做的事。看着简单，真动手时总会卡在几个地方：嵌套对象写出来多了一堆列、数组里的逗号把列撑开、中文逗号到底要不要转义、Excel 打开一片乱码。下面按踩坑顺序说明原因和正确做法。
坑一：嵌套对象直接拍平，列名撞车
[{"id":1,"user":{"name":"张三","city":"北京"}}]
直接把对象字符串塞进单元格，导出的表根本没法排序筛选。正确做法是把嵌套展开成点号路径：
id,user.name,user.city
1,张三,北京
展平的关键是「路径唯一」：user.name 和 order.user.name 不会撞车。如果只取最后一层 name，两个不同来源的同名字段就会互相覆盖——这是展平实现里最常见的错误。
坑二：数组用逗号连接，列直接被撑开
[{"id":1,"tags":["前端","后端"]}]
写成 1,前端,后端，读回来就变成 3 列，原来 2 列的表结构全错位。三种可选处理：
- 用不会出现在数据里的分隔符连接，例如
前端|后端（本文配套工具默认） - 整体序列化成 JSON：
"[""前端"",""后端""]"（引号需要再转义一层） - 拆成多行（一条记录变多行，适合一对多关系，但要额外加序号列）
前两种适合「只是展示」，第三种适合「需要按标签做透视统计」。选错的话，后面要么丢信息，要么透视时对不上。
坑三：中文逗号不是分隔符，英文逗号才是
这是常见误解：CSV 的分隔符默认是半角英文逗号 ,；全角中文逗号 ， 只是普通字符，直接写进去不会错位：
1,张三,北京，中国
上面这行仍然是 3 列，北京，中国 是第 3 列的完整内容。
真正需要转义的是这四种情况，按 RFC 4180 处理：
| 字段内容 | 是否需要包裹双引号 |
|---|---|
含英文逗号 a,b |
需要 |
含双引号 他说"好" |
需要，且内部引号双写 "他说""好""" |
| 含换行 | 需要 |
| 中文逗号、分号、空格 | 不需要 |
判断标准是「有没有出现分隔符本身」，不是「看起来像标点」。
坑四：Excel 打开中文全是乱码
CSV 存的是 UTF-8，Excel 双击时却按本地编码（GBK）读，中文就成了方块。两个办法：
- 导出时在文件最前面写入 BOM（字节顺序标记），Excel 会按 UTF-8 解析
- 或者用「数据 → 从文本/CSV」导入，手动选 UTF-8
BOM 是三个不可见字节，复制粘贴时看不出来。它只影响「双击打开」这一种用法：下载后要双击用 Excel 打开，文件就带 BOM；用「数据 → 从文本/CSV」导入，或直接复制内容粘贴，都不需要 BOM——复制带 BOM 粘到终端会多出隐藏字符。
坑五：字段不齐导致整表错位
[{"id":1,"name":"张三"},{"id":2,"name":"李四","city":"上海"}]
如果按每行的字段现拼，第二行会比第一行多一列。正确做法是先取所有行的字段并集做表头，缺的字段留空：
id,name,city
1,张三,
2,李四,上海
坑六：Excel 吃掉前导零和长数字
001 会变成 1，18 位订单号会变成 1.23457E+17。这是 Excel 的自动类型推断，和 CSV 本身没关系。导出侧能做的只有提示：这类列需要以文本形式导入，或在 Excel 里预先设置列为文本。不要指望在 CSV 里加引号就能保住——Excel 对带引号的数字照样会转成数值。
验证清单
- 嵌套对象是否展平成唯一路径
- 数组是否用了不会冲突的连接符
- 含英文逗号/引号/换行的字段是否加引号并双写引号
- 表头是否取字段并集，缺列是否留空
- 下载文件是否带 BOM，复制内容是否不带 BOM
工具页可直接验证：JSON 转 CSV，格式化排查看 JSON 格式化，命令行侧可参考 Bash 速查。