go中nil切片序列化为null，空切片[]t{}序列化为[]，gin的c.json复用该行为；db查询后未初始化的切片字段（如roles []role）默认为nil，导致前端解析失败，需在handler层显式初始化为make([]role, 0)或[]role{}以确保输出[]。
空数组在 Gin 中默认渲染为空 JSON 数组 []，这是符合 RFC 和前端预期的；但若结构体字段为 nil 切片（[]T(nil)），则会序列化为 null，而非 []——这常导致前端解析失败或类型校验报错。
空切片 vs nil 切片：JSON 序列化行为完全不同
Go 的 encoding/json 对两者处理严格区分：
-
[]string{}（空切片）→ JSON[] -
[]string(nil)（nil 切片）→ JSONnull
而 Gin 的 c.JSON 直接复用该逻辑，不额外转换。常见坑是 DB 查询后未初始化切片字段，例如：
type User struct {
ID int64 `json:"id"`
Name string `json:"name"`
Roles []Role `json:"roles"` // 若未显式赋值，Roles 是 nil，不是空切片
}
此时即使 DB 返回无角色，Roles 字段仍为 nil，最终响应中该字段为 "roles": null。
确保空数组始终输出 [] 的三种写法
关键是在赋值前强制初始化，避免字段保持 nil 状态：
- 声明时直接初始化：
Roles []Role `json:"roles"` = []Role{}（不推荐，结构体字面量无法设默认值） - 构造实例时显式初始化：
u := User{Roles: make([]Role, 0)}或u.Roles = []Role{} - 使用指针 +
omitempty控制（仅适用于可选字段）：Roles *[]Role `json:"roles,omitempty"`，然后赋值u.Roles = &[]Role{}
推荐第二种：在 handler 或 service 层统一做初始化，清晰可控，且不影响结构体定义复用。
嵌套结构体中的空数组容易被忽略的层级问题
当结构体嵌套多层（如 User.Profile.Permissions），任一层切片为 nil 都会导致对应 JSON 字段为 null。尤其注意 ORM（如 GORM）查询时：
- GORM 不会自动初始化嵌套切片字段，哪怕设置了
gorm:"default:[]" -
db.First(&u)后，u.Profile.Permissions仍是nil，除非你手动u.Profile.Permissions = []Permission{}
建议在模型层加一个初始化方法，或在返回前用工具函数递归检查并补空切片，而不是依赖 ORM 行为。
最易被忽略的是：前端通常假设数组字段一定存在且可遍历，null 值会直接触发 Cannot read property 'map' of null 类错误——所以空数组必须是 []，不是 null，也不是缺失字段。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
