validator包无法支持动态规则，因其依赖编译期固定的struct标签（如validate:"required,email"），无法在运行时按需增删、组合或加载规则；当字段由JSON Schema等配置动态生成时，结构体失去灵活性，且规则变更需重启服务。
为什么不能直接用 validator 包做动态规则？
因为 validator（如 go-playground/validator）依赖结构体标签（validate:"required,email"），编译期绑定，无法在运行时按需加载、增删或组合规则。一旦表单字段由配置生成（比如 JSON Schema 或低代码平台下发），结构体就失去灵活性——你没法为每个请求动态定义 struct。
常见错误现象：panic: reflect: call of reflect.Value.Interface on zero Value，往往源于试图对 map[string]interface{} 中的 nil 字段调用 Validate.Struct()；或者规则变更后必须重启服务。
- 动态校验的核心是「规则描述」与「执行逻辑」解耦：规则用 map 或结构体描述（如
{"field": "email", "rule": "email", "required": true}），执行靠独立函数注册 - 所有规则函数必须统一签名，例如
func(value interface{}, params map[string]string) error，便于反射或 map 查找调用 - 避免在规则函数里直接 panic 或 log，错误应返回
error，由引擎聚合并关联字段名
如何设计可扩展的规则注册与匹配机制？
关键不是写死 if-else，而是用 map 做规则名到验证器的映射，并支持运行时注册。Go 没有全局注册表，所以得自己管好这个 map 的并发安全和生命周期。
使用场景：后台管理侧允许运营人员新增手机号校验规则（如“必须归属某运营商”），对应 Go 服务需热加载该规则，不重启。
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 定义注册器类型：
var validators = sync.Map{}，键为string（如"custom_mobile"），值为func(interface{}, map[string]string) error - 注册时用
validators.Store("custom_mobile", func(v interface{}, p map[string]string) error { ... })，不要用普通 map + mutex，避免漏锁 - 匹配字段规则时，先查
validators.Load(rule.Type)，查不到就返回明确错误（如ErrUnknownRule: "unknown rule 'iban'"），别静默跳过 - 参数传递用
map[string]string而非 struct，方便 JSON 配置直解析，比如{"length_min": "6", "length_max": "20"}
怎么处理嵌套字段和数组校验？
纯 flat 规则（如 {"field": "user.profile.phone", "rule": "phone"}）容易写，但实际表单常有对象嵌套或列表（如 items: [{name: "...", price: 100}]）。硬编码路径解析会很快失控。
性能影响：每次校验都做字符串 split（如按 . 分割 "user.address.city"）+ 多层 map 取值，比直接 struct 访问慢 3–5 倍；若字段深度 > 4，建议加缓存路径解析结果。
- 用
gjson或jsonpath库提取值更可靠，尤其面对未知结构的map[string]interface{}；避免手写递归取值导致 panic - 对数组字段（如
"items.#.price"），约定#为通配符，引擎需遍历所有items元素，对每个price执行相同规则 - 错误信息里必须保留原始路径（如
"items[1].price: must be > 0"），而不是笼统说"price is invalid"，否则前端无法准确定位 - 空数组或 nil slice 不触发子项校验——这是常见坑：
[]interface{}{nil}和nil行为不同，要显式判断len(val) == 0 || val == nil
如何让错误反馈对前端真正可用？
后端返回 {"errors": [{"field": "email", "message": "invalid format"}]} 看似标准，但实际中前端常需要：字段顺序、分组（必填/格式/业务）、是否阻断提交。纯字符串 message 不够。
容易踩的坑：把校验错误拼成一个长字符串（如 "email invalid, password too short"），前端无法拆解定位；或错误码用自定义整数（如 1001），却没文档同步更新。
- 错误结构体至少含：
Field string（原始路径）、Code string（如"email_format"）、Message string（带插值，如"{{.value}} is not a valid email"） - 用
text/template渲染 Message，传入map[string]interface{}{"value": actualValue}，避免字符串拼接 XSS 风险 - 对同一字段多个错误（如既为空又格式错），默认全部返回，别只报第一个；前端决定展示优先级
- HTTP 状态码统一用
400 Bad Request，不要因“业务错误”改用422——很多前端库不识别422，导致错误被吞
"min_length"，后端规则却叫 "min"，这种错位不会报编译错误，只会让表单在校验时静默失效。 
