JSON 在线压缩（单行化）
把多行带缩进的 JSON 压成一行，去掉全部多余空白并校验语法，适合接口传输、日志打点和配置文件瘦身。
带缩进的 JSON 适合阅读，不适合传输。几十行结构里塞满的空格和换行对解析器毫无意义，却会实实在在增加请求体、日志文件和消息队列的字节数。这个工具把 JSON 合并成一行，只保留语法必需的内容，字符串字面量里的字符一个都不动，压缩前后的大小可以在底部状态栏直接对比。
处理方式是本地解析后重新序列化，整个过程在浏览器里完成，文本不会发往任何服务器，也不经过代理或日志记录。对包含手机号、订单号、内部接口地址的样例数据来说，这是可以放心粘贴的前提。页面断网也能用，因为功能实现全部编译在前端代码里，不依赖后端接口。
压缩做了什么，没做什么
压缩的实现是先用 JSON.parse 解析，再调用不带缩进参数的序列化，因此删除的是语法结构之外的所有空白：对象与数组前后的换行、逗号后的空格、冒号两侧的空白。字符串内部不在处理范围内，"a b" 里的两个空格会原样保留，换行也只有写成 \n 转义时才会存在。也要注意它并非单纯的文本替换：数字写法会被规范化（1.0 变 1、1e3 变 1000），\u4e2d 这类转义会还原成汉字，同一个对象里重复的同名 key 只保留最后一个。
体积能省多少
节省幅度取决于原来的缩进方式和嵌套深度。常见的 2 空格缩进，压缩后大约能减掉一到三成；深层嵌套加长字段名的情况比例更高；反过来，如果原文本来就是紧凑写法，压缩几乎不会带来变化。底部状态栏显示的是当前内容的真实字节数，按 UTF-8 计算，超过 1024 字节会换算成 KB，压缩前后各看一次就能算出准确收益。补充一点：汉字在 UTF-8 里占 3 字节，而 \uXXXX 转义占 6 字节，所以把中文还原成汉字通常还能再省一些。
什么时候不要压缩
压缩会牺牲可读性，凡是需要人来阅读的场合都不该用：提交到代码仓库的配置文件、需要人工核对的数据清单、要写进接口文档的示例。另外压缩依赖解析成功，只要存在一处语法错误就会整体失败，状态栏此时给出错误行号与片段而不是结果，需要先修正或交给智能纠错处理。如果只是想去掉多余空格但保留多行结构，用格式化重排一次比压缩更合适。
常见问题
- 压缩后的 JSON 和原文件语义一样吗？
- 一样。JSON 的换行与缩进不属于数据，解析器只看结构本身，所以压缩前后解析出的对象完全相同。可能变化的只有两点：数值写法被规范化，1.0 与 1 是同一个数；重复 key 按标准取后出现的值。两者都不影响语义。
- 字符串里的空格会被删掉吗？
- 不会。压缩针对的是字符串之外的结构空白，双引号内部的空格、制表符和换行转义都原样保留。含三个连续空格的字符串压缩后依然是三个空格，这一点与用正则批量删空格的粗暴做法有本质区别，后者会破坏字符串内容。
- 为什么压缩之后文件反而没变小？
- 如果原文本身就是紧凑写法，压缩几乎没有可删的空白，差距只在个别逗号后的空格上。另一种情况是原文以 GBK 等编码保存，工具按 UTF-8 计算字节数，一个汉字从 2 字节变成 3 字节，看起来反而更大，这是统计口径差异而非压缩造成的膨胀。
- 压缩能顺带去掉注释和多余的逗号吗？
- 不能。注释和尾随逗号都不属于 JSON 标准，解析会直接失败，压缩也就无从执行。这类文本要先经过智能纠错修复：它会去掉 // 与 /* */ 注释、删掉紧跟在 } 或 ] 前面的逗号，再交给压缩处理。