结构体字段校验不能只靠struct标签，因为标签仅支持静态规则（如required、min=1），无法处理依赖运行时数据的动态逻辑（如“用户名不能和邮箱前缀相同”“状态为draft时description可为空”），必须将校验逻辑移至代码中，用方法或函数封装，并避免硬编码字段名导致维护困难。
结构体字段校验为什么不能只靠 struct 标签？
因为 json 或 validate 标签只能做静态规则（比如 required、min=1），一旦校验逻辑依赖运行时数据（如“用户名不能和邮箱前缀相同”“状态为 draft 时 description 可为空”），标签就失效了。这时候必须把校验逻辑从声明式移到代码里，用方法或函数封装。
常见错误是把所有校验塞进一个 Validate() 方法里硬编码字段名和条件，导致后续加字段、改规则时难维护、易漏判。
- 推荐做法：每个业务规则单独写成闭包或函数，再通过 map 或 slice 组合调用
- 避免直接操作
reflect.Value做通用校验——类型擦除后容易 panic，且无法精确控制错误信息格式 - 若用第三方库（如
go-playground/validator），务必覆盖其默认 tag 解析逻辑，否则嵌套结构体或指针字段会跳过校验
如何让结构体自己决定哪些字段参与过滤？
字段级动态过滤的关键不是“删掉字段”，而是控制序列化行为。Golang 的 json 包支持 omitempty，但它只看零值，不看业务逻辑。真正可控的方式是用自定义 MarshalJSON() 方法，或用中间结构体（DTO）做显式投影。
容易踩的坑：在 HTTP handler 里直接返回原始结构体并指望 omitempty 过滤敏感字段，结果 password 字段明明是空字符串却没被过滤——因为 string 的零值是 ""，而 omitempty 对空字符串生效，但对 "0"、"false" 这类“业务上无效但非零值”完全无效。
立即学习“go语言免费学习笔记（深入）”；
- 敏感字段（如
Password）应设为指针类型：*string，再配合omitempty和初始化为nil - 动态字段（如根据用户角色显示不同字段）建议用 map[string]interface{} 构建响应体，而不是修改原结构体
- 不要在
MarshalJSON()里调用json.Marshal递归处理自身——容易栈溢出，应转为 map 后删键再 marshal
mapstructure 解码时怎么保留校验上下文？
当从 map[string]interface{}（比如 API 请求 body）解码到结构体时，mapstructure 默认丢弃原始 key 的位置信息，导致报错时只知道“Field X 无效”，不知道是 query、header 还是 body 里的哪个字段出问题。这对调试和前端提示很不友好。
解决方案不是放弃 mapstructure，而是用它的 DecodeHook 和自定义 Metadata 捕获路径信息。
- 启用
WeaklyTypedInput: true时，"1"会被转成 int，但若业务要求严格类型（如 ID 必须是数字而非字符串），需关闭它并手动处理 - 用
metadata := &mapstructure.Metadata{}接收解码元数据，再遍历metadata.Keys构建带层级的错误路径（如user.profile.phone） - 避免在 hook 里做耗时操作（如查 DB），hook 是同步执行且不可取消的
为什么校验和过滤逻辑不该放在 HTTP handler 里？
因为 handler 层职责是编排，不是决策。把 if req.Role == "admin" { delete(resp, "salary") } 写在 handler 里，会导致同一结构体在不同接口中重复判断，且无法单元测试。
真正可复用的做法是定义接口：
type Filterable interface {
Filter(ctx context.Context, role string) map[string]interface{}
}
然后让结构体实现它，把字段可见性规则内聚在类型内部。
- 不要用全局 map 存储角色-字段映射——并发读写需加锁，且违反开闭原则
- 如果字段过滤依赖外部服务（如权限中心），应在
Filter方法里接受context.Context并做超时控制 - 注意：
map[string]interface{}返回值里不要塞 struct 指针，否则 JSON 序列化时可能 panic
最常被忽略的是错误链路：校验失败时，是否把原始输入字段名透传给前端？过滤逻辑是否考虑了缓存一致性？这些细节不提前设计，上线后就会变成线上问题排查的盲点。
