JSON 是目前最常用的数据交换格式之一， 但在实际工程中，问题往往不在「会不会用」，而在「用得对不对」。
一、JSON 的本质
JSON 本质上是一种 文本格式，不是对象、不是 Map， 更不是语言原生结构。
在网络传输、日志记录、持久化存储时， 所有 JSON 最终都会退化成一段字符串。
二、常见结构示例
{
"user_id": 12345,
"username": "scorpio",
"roles": ["admin", "editor"],
"profile": {
"email": "test@example.com",
"active": true
}
}
在设计 JSON 结构时，应尽量保证：
- 字段语义清晰
- 避免多层无意义嵌套
- 字段类型稳定
三、工程中最容易踩的坑
1. 类型不一致
同一个字段，在不同版本中返回 string / number /
object，是线上 Bug 的高发区。
2. JSON 套 JSON
{
"body": "{\"status\":0,\"msg\":\"ok\"}"
}
这种结构会导致多次反序列化，增加复杂度，也极易出错。
3. 字段含义随意变化
JSON 没有 Schema 约束时， 约定本身就是协议，随意改字段等同于破坏接口。
四、实践建议
- 接口层明确 JSON Schema
- 字段命名保持长期稳定
- 日志中区分「原始字符串」和「解析后对象」
- 能不用嵌套就不用
大多数 JSON 问题，并不是技术难题， 而是设计阶段没有想清楚边界。