Context.BindJSON 会自动解析 JSON，但要求结构体字段必须导出且标签匹配；若字段名不匹配或未导出，将静默赋零值而不报错。
Context.BindJSON 会自动解析但必须匹配结构体字段
BindJSON 是 Echo 中最常用的 JSON 解析方法，但它不是“万能解包器”——它依赖 Go 结构体的字段标签和导出性。如果你传入 {"name":"alice","age":25}，却定义了 type User { Name string } 而没写 Age int `json:"age"`，Age 字段就收不到值，也不会报错。
常见错误现象：BindJSON 返回 nil 错误，但字段值却是零值（比如 0、空字符串），误以为成功了；其实只是 JSON 字段名和结构体字段不匹配或未导出。
- 结构体字段必须首字母大写（导出）才能被
json包访问 - 推荐显式加
json标签，比如Age int `json:"age"`，避免大小写隐式映射出错 - 如果 JSON 字段可选，字段类型用指针（如
*string）或加omitempty标签 - 嵌套对象、数组都支持，但对应结构体字段也需按规则定义
BindJSON 和 ShouldBindJSON 的区别在哪
两者都调用底层解析逻辑，关键差异在错误处理策略：BindJSON 遇到解析失败（如类型不匹配、必填字段缺失）会返回非 nil 错误；而 ShouldBindJSON 在遇到 HTTP 400 类错误（如 Content-Type 不是 application/json、body 为空、JSON 格式非法）时会自动写入 400 响应并中断后续 handler 执行。
- 用
BindJSON：你希望统一处理所有错误（比如记录日志 + 自定义响应），且能控制是否继续执行 - 用
ShouldBindJSON：想快速拦截明显客户端错误，省去手动c.JSON(400, ...) - 注意：
ShouldBindJSON不会因结构体字段缺失而中断——只要 JSON 语法合法、能转成目标结构体（即使部分字段为零值），它就静默通过
解析失败时怎么拿到原始 JSON 内容
BindJSON 解析失败后，c.Request().Body 已被读取并关闭，无法再次读取。如果需要原始内容（比如做 fallback 解析、审计日志、转发给下游服务），必须提前缓存。
- 在调用
BindJSON前，用io.ReadAll(c.Request().Body)读一次，并用bytes.NewBuffer重建 body - 更稳妥的做法是写一个中间件，在请求进入 handler 前统一缓存 body（注意内存和大 payload 风险）
- 别依赖
c.Request().Body多次读取——HTTP body 是单次流，Echo 不会自动重放 - 示例片段：
body, _ := io.ReadAll(c.Request().Body) c.Request().Body = io.NopCloser(bytes.NewBuffer(body)) // 后续再 BindJSON 就不会报 "invalid request body"
时间字段、布尔字段、空数组容易出什么问题
JSON 解析对类型敏感，尤其当前端传值不规范时："null"、空字符串 ""、字符串数字 "123" 都可能让 BindJSON 静默失败或赋零值。
-
time.Time字段：JSON 中必须是 RFC3339 格式字符串（如"2024-05-20T10:30:00Z"），否则解析失败；建议用自定义类型 +UnmarshalJSON方法处理多种格式 -
bool字段：JSON 中只能是true或false，不能是"true"字符串，否则报错json: cannot unmarshal string into Go value of type bool - 空数组
[]绑定到[]string没问题，但绑定到*[]string可能得额外判断——指针本身不为 nil，但内部切片仍可能为空 - 所有这些边界情况，仅靠
BindJSON返回nil错误无法覆盖，必须结合业务校验（如检查len(Items) == 0是否允许）
真正麻烦的从来不是“怎么绑”，而是“绑完怎么信”。字段零值、类型隐式转换、空值语义模糊——这些都需要在结构体定义、中间件校验、甚至 API 文档层面提前对齐，而不是等到线上日志里看到一堆 0 和空字符串才去猜。
