用 map[string]interface{} 作为过滤条件载体最现实，因 go 结构体类型在编译期固定，reflect 无法真正动态构建新 struct 类型；应配合字段白名单、后缀约定（如 "__gt"）和数据库列名映射来安全使用。
用 reflect 动态构建结构体字段过滤条件不现实
Go 的结构体字段在编译期就固定，reflect 可以读取字段名和值，但无法在运行时“组装”出新的结构体类型——类型系统不允许。所谓“动态组装过滤条件”，本质是动态生成查询逻辑（比如 SQL WHERE 子句、map 匹配规则或 ORM 查询对象），而不是构造新 struct 类型。
常见误操作是试图用 reflect.StructOf 拼字段再实例化，这只能用于极少数元编程场景（如自动生成 mock 结构），且字段名/类型/标签全得硬编码，完全违背“动态过滤”的初衷。
推荐方案：用 map[string]interface{} 作为过滤条件载体
这是最轻量、最通用的做法，适配 JSON API 请求、数据库查询参数、内存 slice 筛选等场景。关键在于明确字段名（字符串）和期望值的对应关系，而非结构体本身。
-
map[string]interface{}能直接接收 HTTP 查询参数或 JSON body，无需预定义结构 - 字段名拼写错误会直接导致过滤失效（无编译检查），建议配合白名单校验：
validFields := map[string]bool{"name": true, "status": true, "created_at": true} - 对数值范围、模糊匹配等复杂条件，可约定特殊 key 后缀，例如
"age__gt"、"name__contains"，解析时按__分割处理 - 注意
nil值语义：HTTP 参数缺失时是 key 不存在，而显式传null是nil，两者在过滤逻辑中通常含义不同
结合 sqlx 或 gorm 构建 WHERE 子句时的坑
直接把 map[string]interface{} 丢给 ORM 不安全，容易 SQL 注入或类型错位。必须做两层转换：字段名映射 + 值类型归一化。
- 数据库列名可能和 Go 字段名不一致（如
User.Name→user_name），需维护structTag解析逻辑，或用sqlx.DB.Mapper统一处理 - 时间类型字段不能直接塞
time.Time进 map 再传给sqlx.NamedExec，要先转成字符串或使用database/sql支持的类型（如*time.Time） - 空字符串
""和nil在 WHERE 中行为不同：前者是= ''，后者常被忽略或转为IS NULL，需显式区分 - 示例片段（
sqlx）：var whereParts []string var args []interface{} for k, v := range filters { if v == nil { continue } colName := getDBColumnName(k) // 自定义映射函数 whereParts = append(whereParts, colName+" = ?") args = append(args, v) } query := "SELECT * FROM users WHERE " + strings.Join(whereParts, " AND ") db.Select(&users, query, args...)
需要强类型保障时，用函数式选项模式替代“动态结构体”
如果业务要求字段必须有编译期检查（比如只允许对 User 的特定字段过滤），就放弃“动态组装结构体”的想法，改用可组合的函数构建器。
- 定义过滤器函数类型：
type UserFilter func(*sqlx.Stmt) *sqlx.Stmt，每个条件是一个闭包，内部拼 SQL 片段或绑定参数 - 提供链式方法：
ByStatus("active").ByCreatedAtAfter(time.Now().AddDate(0,0,-7))，最终调用Build()返回完整查询 - 优势：字段名、类型、约束都在编译期检查；支持 IDE 自动补全；可复用、可测试
- 劣势：每新增一个结构体就得重写一套过滤器，不适合泛型元数据服务
真正难的不是“怎么拼结构体”，而是厘清过滤条件的语义边界——哪些该由前端传字符串控制，哪些必须由后端代码硬编码校验。多数时候，map[string]interface{} 加字段白名单已经够用；一旦开始纠结“动态结构体”，往往说明接口设计或领域模型还没收敛。
