JSON 知识详解

本页面从基础概念到实战规范，全面介绍 JSON 的定义、语法、类型、解析流程、接口设计、数据治理、性能优化与安全要点。无论你是前端、后端、测试还是数据处理人员，都可以在这里系统理解 JSON 的核心知识与常见问题。

什么是 JSON

JSON（JavaScript Object Notation）是一种轻量级的数据交换格式。它以“文本”形式描述结构化数据，具备可读性好、跨语言兼容强、解析成本低等特点。JSON 在 Web 接口通信、配置文件、日志埋点、消息队列、数据导入导出等场景被广泛使用。

JSON 的核心目标是“让数据结构以统一、可读、可解析的方式表达出来”。它本质上是一套语法规范，并不依赖某一种编程语言。几乎所有主流语言都内置了 JSON 解析和序列化能力。

JSON 示例与字段讲解

{
  "id": 1001,
  "name": "Alice",
  "active": true,
  "skills": ["JSON", "API"],
  "profile": {
    "city": "Shanghai",
    "age": 28
  },
  "remark": null
}

`id` 是数值类型，常用于主键、编号、顺序值。
`name` 是字符串类型，必须使用双引号包裹。
`active` 是布尔类型，只能是 `true` 或 `false`。
`skills` 是数组类型，适合表达列表、标签、明细项。
`profile` 是对象类型，可继续嵌套子字段描述结构化信息。
`remark` 是空值 `null`，用于表达“字段存在但当前无值”。

JSON 语法规则（必须掌握）

基础规则

对象使用花括号：`{}`，由键值对组成。
数组使用方括号：`[]`，由多个值组成。
键名必须是双引号字符串，例如 `"name"`。
字符串值必须使用双引号，不能使用单引号。
键值对之间使用逗号分隔，不能在末尾多写逗号。

常见限制

JSON 不支持注释，`//` 或 `/* */` 都会导致解析失败。
JSON 不支持 `undefined`、`NaN`、`Infinity` 等值。
JSON 不支持函数、日期对象、正则对象等运行时类型。
布尔值只能是 `true` / `false`，且必须小写。
空值只能是 `null`，不能写成 `NULL` 或空字符串代替。

JSON 六大数据类型

Object（对象）

由键值对组成，用于表达结构化实体，例如用户信息、订单信息。

Array（数组）

有序集合，用于表达列表数据，例如商品列表、日志列表。

String（字符串）

文本类型，必须双引号包裹，适合姓名、状态描述、编码字段。

Number（数值）

整数或浮点数。涉及大整数时需注意精度与语言解析差异。

Boolean（布尔）

`true` 或 `false`，适合开关状态、是否启用等逻辑字段。

Null（空值）

用于表达“明确为空”，区别于缺失字段和空字符串。

JSON 解析与序列化

解析（Parse）是把 JSON 字符串转换成程序可操作的数据结构；序列化（Stringify）是把程序对象转换成 JSON 字符串。解析与序列化几乎存在于所有接口请求、响应、缓存和日志链路中。

解析阶段重点

先校验语法，再进入业务处理。
对关键字段做类型判断，避免隐式转换。
做好异常捕获，防止单条坏数据影响整体流程。

序列化阶段重点

保持字段顺序和命名一致，便于调试和比对。
明确空值策略，减少消费者二次判断负担。
在对外接口中保持稳定格式，降低版本兼容风险。

接口设计中的 JSON 规范

字段命名统一：建议在同一系统内统一使用一种命名风格（如 snake_case 或 camelCase），避免混用导致前后端映射复杂。

类型保持稳定：同一字段在不同接口或不同时间返回时，类型应保持一致，避免一会儿是字符串一会儿是数字。

空值约定清晰：提前约定“缺失字段”“null”“空字符串”“空数组”的语义，减少业务歧义。

层级不要过深：过深的嵌套增加解析复杂度和错误率，必要时考虑结构扁平化。

统一响应结构：可约定基础结构，例如 `code`、`message`、`data`，便于前端和网关统一处理。

版本演进可控：新增字段优先采用向后兼容方式，删除字段前应预留迁移周期。

JSON 常见错误与排查方法

语法错误

典型表现为缺少逗号、引号、括号不匹配、包含注释等。建议先做在线校验，再做格式化定位。

编码错误

常见为中文乱码、Unicode 转义异常。可借助转义/反转义工具和乱码修复工具排查。

类型错误

例如数字被当成字符串、布尔被当成文本。建议在解析后做字段类型断言和校验。

结构错误

例如字段缺失、层级变化、数组对象混用。应结合接口文档和样例做结构一致性检查。

JSON 性能优化建议

减少无用字段，降低传输体积与解析开销。
避免超深嵌套结构，提升可读性与处理效率。
大数据建议分页、分片、分批处理，不要一次性全量加载。
日志场景可采用 JSON Lines（逐行 JSON）便于流式处理。
缓存场景注意序列化成本与压缩策略，权衡 CPU 与网络开销。
前端处理大 JSON 时优先异步和分阶段渲染，避免主线程阻塞。

JSON 安全与治理建议

在处理 JSON 时，安全并不只来自“语法正确”，还包括“输入可信、输出可控、边界清晰”。

建议对外部 JSON 输入进行严格校验：字段白名单、长度限制、类型断言、内容过滤。不要直接信任用户提交的数据结构。

在日志系统中避免记录敏感字段原文，例如手机号、身份证、令牌、密码相关数据，必要时做脱敏处理。

接口返回应遵循最小必要原则，只返回当前业务需要字段，减少敏感信息泄露与冗余传输。

建立 JSON Schema 或字段文档规范，对核心接口做自动化校验和变更审查，提升团队协作质量。

JSON 学习路径（从入门到实战）

阶段一：语法与类型

掌握对象、数组、字符串、数值、布尔、null 的写法和限制，熟悉常见语法错误。

阶段二：工具与流程

学习格式化、校验、压缩、提取、转换、去重、拆分合并等工具流程。

阶段三：规范与治理

建立字段规范、版本策略、异常处理和安全机制，形成可复用的团队标准。

JSON 代码示例（正确与错误对比）

下面通过“可直接阅读”的示例，展示 JSON 常见写法和错误写法。建议在实际开发中先做格式化和语法校验，再进入业务逻辑处理。

正确的 JSON 示例

{
  "user_id": 1001,
  "name": "Alice",
  "is_vip": true,
  "tags": ["dev", "json"],
  "profile": {
    "city": "Shanghai",
    "age": 28
  },
  "last_login_at": null
}

错误的 JSON 示例

{
  user_id: 1001, // 键名未加双引号，且 JSON 不支持注释
  'name': 'Alice', // 不能使用单引号
  "is_vip": True, // 布尔值必须是 true / false 小写
  "tags": ["dev", "json",], // 末尾多余逗号
}

排查建议：先检查引号、逗号、括号，再检查是否包含注释、非法值和大小写错误。