如何第一时间看到新文章？

收藏本博客列表页，并在首页与工具聚合页留意指南入口。阅读文章无需注册或邮件订阅。

博客主要写什么？

围绕 JSON 校验、格式化、转换与调试流程，以及 JSON Work 工具更新，与在线工具的本地能力一一对应。

可以建议教程选题吗？

可以。请通过关于页的联系方式或 GitHub 反馈；我们会优先安排贴近真实开发场景的教程。

API JSON 校验清单：语法正确之后还要检查什么？

JSON.parse 成功只说明文本符合 JSON 语法，并不代表它满足接口契约。一个响应可以语法完全正确，却缺少必填字段、返回错误类型、使用过期枚举或把金额变成不安全的浮点数。下面是一套可用于前后端联调、自动化测试和上线检查的分层清单。

一、先检查 HTTP 层

在查看正文之前记录状态码、Content-Type、字符集和请求 ID。JSON 接口通常应返回 application/json 或明确的兼容媒体类型。状态码为 204 时不应强行解析空正文；错误响应也应有稳定的错误结构，而不是偶尔返回 HTML。

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
X-Request-Id: req_123

如果代理把登录页或 WAF 错误页包装成 200，单纯调用解析器会得到一个不直观的错误。先检查响应头和正文前几个字符可以更快定位问题。

二、验证语法和编码

把响应放入 JSON 验证器，确认括号、逗号、引号和转义字符正确。还要测试包含中文、Emoji、换行、反斜线和 Unicode 转义的样例。服务端与客户端应统一使用 UTF-8，避免把可见乱码误认为业务数据。

{
  "message": "保存成功 ✅",
  "path": "C:\\logs\\today"
}

三、确认根节点与字段存在性

接口文档应明确根节点是对象、数组还是标量。分页接口可以约定 {items, page, total}，不要在无数据时从对象变成空数组。对每个字段区分三种状态：缺失、显式 null、存在有效值。它们在更新接口中往往代表“保持不变”“清空”和“设置新值”，不能混用。

建议逐项回答：

• 必填字段缺失时返回什么错误？

• 可选字段是否允许 null？

• 空字符串与缺失是否等价？

• 未知字段是忽略、保存还是拒绝？

• 新旧客户端如何处理新增字段？

四、严格检查字段类型

JSON 只有字符串、数字、布尔值、null、对象和数组。日期、UUID、金额等都需要额外格式约束。常见错误包括把数字写成字符串、把单个对象写成数组，或把 false 当成缺失值。

{
  "userId": "9007199254740993",
  "enabled": false,
  "createdAt": "2026-07-17T08:30:00Z"
}

示例中 userId 使用字符串是为了避免 JavaScript 安全整数精度问题；日期带有明确时区。金额最好使用最小货币单位整数，或使用定义清楚的十进制字符串。

五、使用 JSON Schema 固化契约

JSON Schema 可以把必填字段、类型、长度、格式、枚举和嵌套规则变成可执行规范：

{
  "type": "object",
  "required": ["id", "status"],
  "properties": {
    "id": {"type": "string", "minLength": 1},
    "status": {"enum": ["pending", "active", "disabled"]},
    "tags": {"type": "array", "items": {"type": "string"}, "uniqueItems": true}
  },
  "additionalProperties": false
}

开发阶段可使用严格的 additionalProperties: false 捕获拼写错误；公共 API 是否允许新增字段则要根据兼容策略决定。Schema 应进入版本控制，并在服务端输入校验、契约测试和客户端生成流程中复用。

六、覆盖失败与边界场景

一套上线前测试至少应包含：

最小合法对象和完整合法对象。

每个必填字段分别缺失。

字段类型错误、空值和超长字符串。

空数组、超大数组和深层嵌套。

重复项、未知枚举和额外字段。

超大整数、小数精度、负数和零。

无效日期、夏令时边界和不带时区的日期。

401、403、404、409、422、429 和 500 错误结构。

错误响应应提供机器可识别的错误代码、面向人的说明和可用于排查的请求 ID，但不要泄露堆栈、SQL 或服务器路径。

七、前后端联调验收表

联调完成前，双方共同确认：接口示例能被真实代码解析；Schema 与文档一致；错误码稳定；分页边界正确；新增字段保持向后兼容；日志不会记录令牌或完整敏感正文。可把两个版本的样例放入 JSON Diff 检查契约变化，再用 JSON 美化器生成便于评审的格式。

总结

API JSON 验证应按 HTTP、语法、结构、类型、业务规则和兼容性逐层进行。解析成功只是第一关；只有把契约写成 Schema、覆盖失败样例并纳入持续集成，才能在上线前发现那些“看起来是 JSON、实际不能安全使用”的问题。