你的构建因"JSON在位置4,821处出现意外令牌"而失败。太好了，谢谢。现在你必须滚动浏览一个四千字符的配置文件，在你的头脑中计数括号，试图找出哪一个不匹配。这是软件开发中最可避免的时间浪费之一，它不断发生，因为JSON对小错误零容忍。
数组中最后一个项目之后的尾部逗号。关键周围缺少引号。从其他地方复制的额外右括号。其中任何一个都完全破坏解析，错误消息很少指向实际问题 — 它指向解析器放弃的地方，这通常远离真实错误。
为什么位置数字没有帮助
大多数JSON解析器将错误报告为字符偏移，而不是你可以跳转到编辑器的行和列。将位置4,821转换为"行112，在第三个对象附近某个地方"需要手动计数或编写一次性脚本。两者都不是你下午的好用处。
一些编辑器内联突出显示JSON语法错误，这对你积极编写的文件有帮助。但对于你从API、同事或继承的遗留配置收到的JSON，你需要一个工具来接收原始文本并确切地告诉你什么是错误以及在哪里。
在Mac上验证JSON而无需离开
也验证的JSON格式化工具节省猜测。粘贴JSON，如果格式错误，你会得到一个清晰的错误，指向特定的行和字符，而不是原始字节偏移。如果有效，它呈现干净，正确缩进，所以你可以直观地扫描结构。Bellows在同一工具中处理两种情况 — 你不需要提前知道你的JSON是否被破坏。
在运送之前捕获错误
配置文件、API请求体和装置数据都靠有效JSON生存或死亡。在提交配置更改或发送测试请求之前运行快速验证通过会捕获那种否则会在管道中后来作为混乱运行时错误表面的印刷错误。
使用不信任的输入
当同事在Slack中粘贴JSON块，或者你从你不完全信任的第三方API中提取，在本地验证它意味着你永远不必将该数据发送到外部网站仅仅检查它是否解析。