CSV / JSON / JSON Lines (JSONL) 三方对比

结构能力

扁平二维，仅支持表结构；不支持嵌套、数组

支持多层嵌套、对象、数组；单文件一般是一个大对象 / 大数组

单行内是完整 JSON，支持嵌套、数组；行之间互相独立，没有全局根结构

数据类型

全部是字符串，无原生类型，数字 / 布尔 /null 需要业务转换

原生支持 string/number/bool/null/array/object，自带类型

单行 JSON 拥有 JSON 全部类型能力，每行独立保留类型

文件形态

表头行 + 数据行，逗号分隔

一个完整 JSON 文档，常是[{...},{...}]大数组

一行 = 一条 JSON，换行\n分隔，不能整体当成单个 JSON 解析

可读性

表格直观，Excel/WPS 直接打开；字段一多容易错位

格式化后层级清晰；压缩单行 JSON 很难阅读

单独拿一行 JSON 可读性和 JSON 一致；整体是一堆 JSON 行，不适合 Excel 打开

文件大小（同等简单数据）

最小，分隔符开销极低

最大，大量"、:、{}冗余符号

介于 CSV 和标准 JSON 之间；比 JSON 数组少了外层[]和元素逗号，比 CSV 大

流式读取

✅ 非常友好，逐行读、逐行处理，内存占用低

❌ 原生 JSON 数组很难流式解析，一般要加载整个文档到内存（除非用专门流式解析器）

✅ 流式最佳：读一行、解析一行、处理一行，不用加载全文件，适合超大文件

解析难度 & 坑点

简单；痛点：逗号、换行、双引号转义，表头丢失、列顺序错乱

解析规范严格；括号、逗号写错直接整体解析失败；大数组内存爆炸

每行单独按 JSON 解析；只需要按换行分割，一行坏了不影响其他行（容错优于标准 JSON 数组）

自描述性

弱，依赖表头；表头丢了数据无意义

强，每个 key 自带字段含义

强，每一行 JSON 自带 key，不需要全局表头

常用工具生态

Excel、WPS、Hive、Spark、ClickHouse、数据库导出、BI 报表

所有编程语言、REST API、配置文件、Mongo 交互

Spark、Flink、DuckDB、Elasticsearch 导入、日志、埋点、数据湖、CDC 同步

典型优点

体积小、报表友好、运维运营看数据方便

表达复杂结构，API 标准，前后端交互通用

✔ 同时拥有 JSON 的嵌套能力 + CSV 的流式优势；容错好，适合海量日志 / 事件流

典型缺点

不能嵌套；转义麻烦；无类型；字段顺序绑定

大文件加载压力大；整体一个文档，局部出错全盘失败；冗余字符多

不能直接给 Excel 使用；不是标准 JSON，普通 JSON 解析器直接读整个文件会报错

典型场景

业务报表、批量二维表导出、运营对账、简单 ETL

HTTP 接口请求响应、配置文件、单条复杂对象传输

日志采集、用户埋点、CDC 变更数据、大数据离线导入、消息队列落盘、海量事件数据