c.ReadJSON专用于解析Content-Type为application/json的请求体，需传入结构体指针且字段首字母大写并建议加json tag；PostValue/FormValue仅处理表单编码，对JSON无效。
用 c.ReadJSON 解析 JSON 请求体，不是 PostValue 或 FormValue
前端发的是 Content-Type: application/json，后端就必须走 c.ReadJSON；用 c.PostValue 或 c.FormValue 一定拿不到数据——它们只处理表单编码（application/x-www-form-urlencoded）和 multipart 数据。
常见错误现象：c.FormValue("user") 返回空字符串，但前端明明发了 {"user":"admin"}；这是因为 FormValue 根本不解析 JSON body，它只查 query 和 form 字段。
-
c.ReadJSON要求传入一个**地址（指针）**，比如&payload，否则会 panic - payload 结构体字段名必须首字母大写（可导出），且建议加
jsontag 显式映射，例如Name string `json:"name"` - 如果 JSON 字段是数组（如
"ids": [1,2,3]），对应 Go 字段应声明为IDs []int，不是string - 请求体为空或格式非法时，
ReadJSON返回非 nil error，务必检查，不要忽略
ReadJSON 和 ReadJSONProtobuf 的区别在哪
c.ReadJSON 专用于标准 JSON；而 c.ReadJSONProtobuf 是 Iris 对 protobuf 的扩展支持，用于把 JSON 格式的请求体反序列化成 protobuf 消息对象（即实现了 proto.Message 接口的类型）。
如果你用的是 .proto 定义 + google.golang.org/protobuf 生成的结构体，且希望前端能用 JSON 提交、后端仍按 protobuf 类型处理，才需要 ReadJSONProtobuf。普通业务接口用 ReadJSON 就够了。
立即学习“前端免费学习笔记（深入）”；
-
ReadJSONProtobuf要求目标变量是proto.Message实现类型，比如&hello.HelloRequest{} - 它底层调用的是 protobuf v2 的
json.Unmarshal，兼容 JSON 映射规则（如 snake_case 自动转 camelCase） - 普通 struct 不支持
ReadJSONProtobuf，会 panic
为什么 PostValues 在 JSON 请求里完全无效
c.PostValues 的作用域仅限于 application/x-www-form-urlencoded 和 multipart/form-data 请求。当 Content-Type 是 application/json 时，Iris 根本不会解析 body 为键值对，所以 PostValues 返回空切片，PostValue 返回空字符串——这不是 bug，是协议层面的设计约束。
- 不要试图在 JSON 请求里用
PostValues("items")拿数组，它永远是[]string{} - 也不要用
c.Request().Body手动读取再解析：Iris 的ReadJSON已做缓冲复用和错误封装，重复读会导致io.EOF或 body 丢失 - 调试时可用
c.Request().Header.ContentType()打印确认实际类型，避免凭经验误判
嵌套 JSON 和空字段的处理要点
JSON 解析默认跳过空字段（如 {"name": ""} 中的 name 字段），除非结构体字段加了 json:",omitempty" 以外的 tag，或者你明确需要零值保留。
- 想让空字符串、0、false 等也被接收，去掉
omitempty，或用指针类型（如*string），这样null会转成nil - 嵌套结构体（如
User.Profile.Address）要确保每一层都定义了对应 Go 结构体，且字段可导出 - 如果 JSON 字段名含特殊字符（如
user-id），必须用json:"user-id"tag 映射，否则无法绑定 -
ReadJSON不支持自动类型转换（比如字符串"123"转int），前端必须发正确类型，否则报错
