shouldbindjson校验失败主因是content-type未设为application/json，导致gin回退至form绑定、字段为空且校验跳过；须同时配置json:"name"和binding:"required"标签，并用shouldbindjson显式调用。
ShouldBindJSON 为什么校验失败？
多数人第一次用 c.ShouldBindJSON 报错，不是因为结构体写错了，而是请求头没设对。Gin 会根据 Content-Type 自动选绑定器：如果发的是 JSON 数据但没带 Content-Type: application/json，它就会 fallback 到 formBinding，导致字段全为空、校验直接跳过。
常见错误现象：
- Postman 或 curl 发送 JSON，但漏了
-H "Content-Type: application/json" - 前端用
fetch没显式设置headers，浏览器自动加了text/plain - 结构体字段用了
json:"name"，但标签里没写binding:"required"—— 这时 Gin 不校验，只做反序列化
实操建议：
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 先确认请求头是否为
application/json，用c.Request.Header.Get("Content-Type")打印验证 - 结构体必须同时包含
json标签（用于反序列化）和binding标签（用于校验），缺一不可 - 不要依赖
c.Bind，它不区分 Content-Type，容易误判；明确用c.ShouldBindJSON/c.ShouldBindQuery等具体方法
路径参数和查询参数怎么一起校验？
URL 路径参数（如 /users/:id）和查询参数（如 ?page=1&size=20）不能靠一个结构体 + ShouldBindJSON 全部覆盖。Gin 的绑定器是按来源隔离的：路径参数走 ShouldBindUri，查询参数走 ShouldBindQuery，它们互不干扰。
使用场景：
- GET
/api/v1/users/:id?include=profile：需要校验id是正整数、include是白名单值 - DELETE
/files/:path?force=true：path必须非空，force只能是布尔值
实操建议：
- 为路径参数单独定义结构体，带
uri标签，调用c.ShouldBindUri(&uri) - 为查询参数另定义结构体，带
form或query标签，调用c.ShouldBindQuery(&query) - 两个校验都通过后，再合并处理业务逻辑；任一失败就立即返回 400
- 别把
uri和form标签混在一个结构体里——Gin 不会跨来源合并校验
自定义校验函数注册后不生效？
注册了 validator.RegisterValidation 却发现 binding:"myrule" 报错说找不到规则，大概率是因为你操作了错误的 validator 实例。Gin 启动时创建了一个全局单例 validator，并把它塞进 binding.Validator；你必须往这个实例上注册，而不是自己 new 一个。
容易踩的坑：
- 在单元测试里单独 new 了
*validator.Validate，然后注册规则，但 handler 里走的是 Gin 默认实例 - 调用
RegisterValidation的时机太晚——必须在gin.Default()或gin.New()之后、路由注册之前 - 注册时传的 tag 名（如
"phone"）和结构体里写的不一致（比如写成了"mobile"）
实操建议：
- 统一在
main()开头注册自定义规则，例如：if v, ok := binding.Validator.Engine().(*validator.Validate); ok { v.RegisterValidation("phone", validatePhone) } - 校验函数签名必须是
func(fl validator.FieldLevel) bool，且内部要用fl.Field().Interface()取值 - 调试时可临时加日志，打印
v.StructDescriptions(req)查看当前所有已注册规则
DTO 分层时 binding 标签该写在哪一层？
binding 标签只应出现在 DTO（Data Transfer Object）层，也就是专门接收请求参数的结构体上，绝不能写在 GORM 模型或领域实体上。否则会出现两个严重问题：一是暴露数据库字段细节（比如 created_at 被客户端篡改），二是破坏职责分离（校验逻辑和持久化逻辑耦合）。
典型错误结构：
- 直接把
UserGORM 模型当入参：c.ShouldBindJSON(&user)→ 客户端可传is_admin:true提权 - 在 GORM 模型里加
binding:"required"→ 后续 ORM Save 时可能触发校验，导致写库失败
实操建议：
- 为每个接口定义独立 DTO，如
SignUpDTO、UpdateUserDTO，只含该接口真正需要的字段 - DTO 字段名可与模型不同，用
json标签映射，用binding标签约束，完全解耦 - 校验通过后，手动赋值或用
mapstructure转到模型，中间可做字段过滤、默认值填充等安全处理
