在接口联调、日志排查、配置文件整理或者前端 Mock 数据处理时，JSON 格式化几乎是每天都会用到的操作。
但很多时候我们把一段 JSON 粘贴到格式化工具里，会直接看到类似下面的报错：
Unexpected token
Unexpected end of JSON input
Expected ',' or '}'
Invalid character
JSON parse error
这类问题看起来像是“格式化失败”，但本质上通常是 原始 JSON 不是合法 JSON。
JSON 格式化工具并不是在“修复”数据，它首先要做的是解析 JSON。只有解析成功，才能继续美化、压缩、折叠层级或者查看结构。如果 JSON 自身有语法问题，格式化工具只能告诉你哪里可能出错。
本文整理一套比较实用的排查方法，适合下面几类场景：
- 接口返回内容无法格式化
- 后端日志里的 JSON 复制出来后报错
- 配置文件看起来像 JSON，但解析失败
- 请求参数里嵌套 JSON 字符串
- JSON 里有大量反斜杠和转义引号
- 从数据库字段、消息队列或日志平台复制出来的数据无法解析
如果你只是想快速检查，也可以直接使用在线工具：
下面进入具体排查。
很多内容“长得像 JSON”，但并不是标准 JSON。
标准 JSON 通常只有几种顶层结构：
{
"name": "Open Tools",
"type": "json"
}或者：
[
{
"name": "JSON Formatter"
},
{
"name": "Timestamp Converter"
}
]也就是说，大部分接口响应的 JSON 顶层通常是对象 {} 或数组 []。
如果你复制出来的是下面这种内容：
2026-07-22 10:12:30 INFO response: {"code":200,"data":{"name":"test"}}
它整体就不是 JSON，因为前面混入了日志时间、日志级别和普通文本。
正确做法是只复制 JSON 部分：
{"code":200,"data":{"name":"test"}}这是接口日志里最常见的问题之一：复制时把日志前缀一起带进去了。
标准 JSON 要求对象字段名必须使用英文双引号。
错误示例：
{
name: "Open Tools",
type: "json"
}正确示例：
{
"name": "Open Tools",
"type": "json"
}很多 JavaScript 对象字面量可以省略字段名引号，但 JSON 不可以。
比如在 JS 代码里下面这样可以运行：
const user = {
id: 1,
name: "Tom"
}但它不是标准 JSON。如果要作为 JSON 传输或存储，应该写成：
{
"id": 1,
"name": "Tom"
}另外，单引号也不是标准 JSON 字符串引号。
错误示例：
{
'name': 'Open Tools'
}正确示例：
{
"name": "Open Tools"
}字符串没有闭合，是 JSON 解析失败里非常高频的问题。
错误示例：
{
"message": "hello world,
"code": 200
}这里 "hello world 少了结束双引号。
正确示例：
{
"message": "hello world",
"code": 200
}这种问题在手动拼接 JSON 时很常见，比如：
String json = "{\"name\":\"" + name + "\",\"remark\":\"" + remark + "\"}";如果 remark 中包含双引号、换行或反斜杠，就可能导致最终 JSON 被破坏。
更稳妥的做法是使用 JSON 序列化库，不要手动拼字符串。
JSON 中，对象属性之间需要逗号，数组元素之间也需要逗号。
错误示例：
{
"id": 1
"name": "Tom"
}正确示例：
{
"id": 1,
"name": "Tom"
}数组也是一样。
错误示例：
[
"json"
"base64"
"timestamp"
]正确示例：
[
"json",
"base64",
"timestamp"
]如果报错提示类似：
Expected ',' or '}'
就优先检查当前位置前后是否缺少逗号。
在一些编程语言或配置格式中，最后一项多一个逗号是允许的，但标准 JSON 不允许。
错误示例：
{
"id": 1,
"name": "Tom",
}正确示例：
{
"id": 1,
"name": "Tom"
}数组同理。
错误示例：
[
"json",
"base64",
]正确示例：
[
"json",
"base64"
]这个问题在从 JS 对象复制到 JSON 文件时尤其常见。
JSON 对象使用 {}，数组使用 []。
如果接口响应很长，复制时少复制了结尾一段，就容易出现：
Unexpected end of JSON input
错误示例：
{
"code": 200,
"data": {
"name": "Open Tools"
}这个 JSON 少了一个 }。
正确示例：
{
"code": 200,
"data": {
"name": "Open Tools"
}
}排查这类问题时，可以关注：
{和}是否数量一致[和]是否数量一致- 嵌套层级是否完整
- 是否只复制了接口响应的一部分
- 日志平台是否截断了长文本
很多日志系统会限制单条日志长度，导致 JSON 后半段被截断。这种情况下，不管用什么格式化工具都会失败。
JSON 字符串中有些字符需要转义。
常见转义包括：
\" 表示双引号
\\ 表示反斜杠
\n 表示换行
\t 表示制表符
例如：
{
"message": "他说：\"Hello\""
}如果直接写成下面这样，就会破坏字符串结构：
{
"message": "他说："Hello""
}还有一种情况是路径中的反斜杠。
错误示例：
{
"path": "C:\Users\admin\test"
}这里的 \U、\a 可能会被当成非法转义。
正确示例：
{
"path": "C:\\Users\\admin\\test"
}如果 JSON 中包含 Windows 路径、正则表达式、SQL、HTML、代码片段，尤其需要注意反斜杠。
很多时候，我们在日志里看到的不是原始 JSON，而是被再次序列化后的字符串。
例如：
"{\"code\":200,\"data\":{\"name\":\"Open Tools\"}}"它看起来有大量反斜杠。
这种内容并不是普通 JSON 对象，而是一个 JSON 字符串，字符串内部又包了一段 JSON。
处理方式通常是：
- 先判断最外层是否是字符串
- 对字符串做一次反转义
- 得到内部 JSON
- 再进行 JSON 格式化
反转义后可能得到：
{
"code": 200,
"data": {
"name": "Open Tools"
}
}如果你经常从 Java 日志、消息队列、数据库 JSON 字段里复制内容，这类问题会非常常见。
有些配置格式看起来像 JSON，但不是标准 JSON。
例如 JSON5 可能允许：
{
// comment
name: "Open Tools",
enabled: true,
}YAML 可能长这样：
name: Open Tools
enabled: true它们都不是标准 JSON。
如果你用标准 JSON 格式化工具解析它们，就会报错。
解决方式是：
- JSON 就使用 JSON 格式化工具
- YAML 就使用 YAML/JSON 转换工具
- 带注释和尾逗号的配置，要先确认它是不是 JSON5
接口调试时还有一种很隐蔽的问题：你以为返回的是 JSON，实际返回的是 HTML。
例如后端异常、网关拦截、登录失效、Nginx 错误页，可能返回：
<!DOCTYPE html>
<html>
<head>
<title>500 Internal Server Error</title>
</head>
<body>...</body>
</html>这时候 JSON 格式化一定会失败，因为内容根本不是 JSON。
排查方式：
- 先看 HTTP 状态码
- 再看响应头
Content-Type - 再确认响应体是不是
{}或[] - 如果是 HTML，优先排查后端接口、网关、登录态或跨域问题
常见状态码包括：
401 未登录或 Token 失效
403 无权限
404 接口不存在
500 服务端异常
502 网关异常
所以接口联调时，JSON 格式化只是其中一步，状态码也要一起看。
遇到 JSON 格式化报错，可以按下面顺序处理：
只复制 JSON 内容，不要带日志前缀、时间、线程名、日志级别。
错误：
2026-07-22 INFO response={"code":200,"data":{}}
正确：
{"code":200,"data":{}}看内容是否以 { 或 [ 开头，并以对应的 } 或 ] 结尾。
重点看：
- 字段名是否使用双引号
- 字符串是否闭合
- 是否误用了单引号
- 字符串内部双引号是否转义
重点看：
- 属性之间是否缺少逗号
- 数组元素之间是否缺少逗号
- 最后一项后面是否多了逗号
重点看：
- 路径中的反斜杠
- 字符串中的双引号
- 换行符
- 正则表达式
- 被二次序列化的 JSON 字符串
如果报 Unexpected end of JSON input，很可能是内容没复制完整，或者日志系统截断了响应体。
可以把内容粘贴到 JSON 格式化工具中，先看错误提示，再按提示附近的位置排查。
工具入口：
站内指南：
假设从日志里复制了下面这段内容：
2026-07-22 10:20:11 INFO response: {"code":200,"data":{"userId":1001,"name":"Tom","roles":["admin","editor",],"profile":{"city":"Shanghai","path":"C:\Users\tom"}}}
这段内容有多个问题。
应该先去掉：
2026-07-22 10:20:11 INFO response:
只保留：
{"code":200,"data":{"userId":1001,"name":"Tom","roles":["admin","editor",],"profile":{"city":"Shanghai","path":"C:\Users\tom"}}}错误：
"roles": ["admin", "editor",]正确：
"roles": ["admin", "editor"]错误：
"path": "C:\Users\tom"正确：
"path": "C:\\Users\\tom"最终修正后：
{
"code": 200,
"data": {
"userId": 1001,
"name": "Tom",
"roles": [
"admin",
"editor"
],
"profile": {
"city": "Shanghai",
"path": "C:\\Users\\tom"
}
}
}这就是典型的接口日志 JSON 排查过程：先清理日志噪声，再处理 JSON 语法，再格式化查看结构。
一般不建议自动修复。
格式化工具可以帮助定位错误，但如果自动改内容，可能会把原始数据语义改掉。对于接口调试、日志排查、配置文件处理来说，最好明确知道错误原因，再手动修正。
浏览器控制台里看到的对象可能是 JavaScript 对象，不一定是标准 JSON。
JavaScript 对象允许更多写法，比如字段名不加双引号、末尾逗号、函数、undefined 等，但 JSON 不支持这些。
标准 JSON 不支持注释。
如果你看到带注释的配置文件，它可能是 JSON5、YAML、TypeScript 配置或某个工具自己的配置格式。
通常不需要。
标准 JSON 可以直接包含中文：
{
"message": "你好"
}当然，也可以写成 Unicode 转义：
{
"message": "\u4f60\u597d"
}两者表达的内容一样。
常见原因包括：
- 响应体前后混入了其他字符
- 服务端返回了 HTML 错误页
- 网关或代理改写了响应
- 接口返回空字符串
Content-Type和实际响应体不一致- JSON 字符串被重复序列化
建议同时检查 HTTP 状态码、响应头和响应体。
JSON 格式化报错时，可以优先从这几个方向排查：
- 是否复制了完整 JSON
- 是否混入日志前缀
- 字段名和字符串是否使用英文双引号
- 对象属性和数组元素之间是否缺少逗号
- 最后一项是否多了逗号
- 括号是否成对闭合
- 反斜杠、换行、双引号是否正确转义
- 是否是二次转义后的 JSON 字符串
- 返回内容是否其实是 HTML 错误页
如果只是日常接口联调，可以先用工具快速定位错误：
如果你想看更简短的排查清单，也可以查看：
建议处理生产日志或真实接口数据时，先做脱敏，不要直接粘贴 Token、手机号、身份证号、密钥、订单信息等敏感内容。