go反射拼sql最常因未检查nil指针导致panic，需用v.kind()==reflect.ptr&&v.isnil()判断并跳过或按null处理；优先用带db tag的结构体而非map；反射元信息应缓存避免重复遍历。
Go 反射拼 SQL 时，reflect.Value.Interface() panic：nil pointer dereference
反射取值前没检查是否为 nil，是动态拼 SQL 最常触发的 panic。尤其当 struct 字段是 *string、*int64 这类指针类型，且值为 nil 时，直接调 v.Interface() 就崩。
实操建议：
- 对每个字段先用
v.Kind() == reflect.Ptr && v.IsNil()判断是否为空指针，跳过或按 NULL 处理 - 别依赖
v.IsValid()—— 它对 nil 指针返回 true，但后续取值仍会 panic - 如果字段是接口类型（如
interface{}），需额外用v.Elem()解一层再判断，否则v.Interface()可能返回空 interface{} 而不是底层值
示例片段：
if v.Kind() == reflect.Ptr {
if v.IsNil() {
// 忽略该字段，或生成 "col IS NULL"
continue
}
v = v.Elem() // 解引用后继续处理
}
WHERE 条件动态拼接：用 map[string]interface{} 还是结构体 + 反射？
用 map 看似灵活，但丢失类型信息，SQL 参数绑定易出错；用结构体反射更安全，但字段名和数据库列名不一致时得加 tag 映射。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 优先选结构体 +
json或dbtag，比如type UserFilter struct { Name *string `db:"user_name"` }，反射时读v.Tag.Get("db") - 避免在 map 中混用
nil和空字符串 —— 前者应生成IS NULL，后者是= ''，语义完全不同 - 如果必须用 map，建议封装一层校验函数，统一处理
nil、空字符串、零值，再转成条件列表
sqlx.Named 和原生 db.Query 在反射拼 SQL 时的兼容性差异
sqlx.Named 支持命名参数（:name），但要求传入的参数是 map 或 struct；而原生 database/sql 只认 []interface{} 位置参数。反射生成的 WHERE 子句若含命名占位符，直接喂给 db.Query 会报 sql: expected 0 arguments, got 1。
实操建议：
- 反射阶段就决定参数格式：选
sqlx就保持 struct/map 不变；选原生驱动，就得把字段名+值转成两个切片：args = append(args, v.Interface())，同时维护placeholders列表（如"?"） - 别在 SQL 字符串里硬拼
:name后又用原生驱动 —— 占位符不会被识别，变成字面量，查不到数据还无报错 -
sqlx.In对IN (?)场景友好，但要求 slice 类型明确，反射中需用v.Kind() == reflect.Slice判断，并用v.Len()生成对应数量的?
性能陷阱：每次查询都 reflect.TypeOf + 遍历字段
反射本身不慢，但反复调 reflect.TypeOf 和遍历 struct 字段，在高频查询场景下会明显拖慢吞吐。尤其当 filter 结构体固定（如 UserFilter），没必要每请求都重做元信息提取。
实操建议：
- 把字段映射关系缓存到包级变量，用
sync.Once初始化一次，例如：var userFilterWhereCache = make(map[string]string) - 缓存内容至少包括：非空字段名、对应 db 列名、是否支持模糊匹配（影响生成
LIKE还是=） - 如果结构体可能变化（如微服务多版本共存），加个简单版本号或
reflect.Type.String()做 key，避免缓存污染
反射拼 SQL 的真正难点不在语法，而在 nil 处理、参数协议对齐、缓存粒度这三处。漏掉任一，线上就容易静默错查或 panic。
