JSON 格式正确，数据就可靠吗？我用一份自编配置检查类型与空值

同事发来一行配置，括号和逗号都挤在一起。我通常先把它展开，看看字段层级，再决定能不能交给程序使用。看起来整齐，只能解决阅读问题；数据是否符合约定，还要另查。

下面是一份完全自编的配置示例，不来自业务系统：

json 复制代码

{"retryCount":"3","enabled":"false","nickname":"","timeout":null}

它是合法JSON。但如果接收方约定重试次数为数字、开关为布尔值，那么前两个值就值得停下来核对。

forxi.cn 的IT工具箱有JSON格式化入口，提供格式化、压缩和复制操作。它适合把一行JSON展开成容易逐项阅读的文本。

我在2026年10月19日把上面的自编示例粘到本地功能页面，点击"格式化"。结果按层级展开，但重试次数和开关仍然是字符串，空字符串与null也保持原样。

该工具是简易格式整理器，能帮助查看层级；它不了解接收方的数据约定，不能据此保证配置可用。

对上面的示例，展开后的阅读形式是：

json 复制代码

{
  "retryCount": "3",
  "enabled": "false",
  "nickname": "",
  "timeout": null
}

这些字段与数值只是教学示例。缩进变了，字符串并没有自动变成数字或布尔值，空字符串也没有自动变成null。

我会在展开后做一张小表：

JSON里的false与字符串"false"是不同值；null与空字符串也不是同一回事。至于是否应该改，必须看接口或配置说明。不能因为觉得某个字段"像数字"，就自动改类型。

例如某些编号本来就是字符串，前导零需要保留；某些字段允许null，空字符串却会被拒绝。格式整理器不了解这些业务约定。

先核对文本是否能按JSON语法解析，再核对字段是否齐全、类型是否一致、取值是否在允许范围，最后放到对应环境中验证实际效果。涉及账号、凭据或个人信息的原始配置，不应随手粘到公开文章或不熟悉的工具里。

这类工具的价值是减少阅读一长行文本的负担。它不负责判断重试次数合不合理、开关是否符合预期，也不能保证配置加载后得到正确结果。

对我来说，格式化后的文本是一张更清楚的检查表。看到缩进漂亮了，可以开始逐项核对；还不能据此按下交付键。