应仅用反射做元数据映射，SQL构建交由预编译语句+参数绑定；需检查nil指针、缓存反射结果、避免动态拼接表名列名，并正确处理tag、嵌入字段、interface{}和自定义类型。
直接用 reflect 拼 SQL 字符串是危险且不可靠的，它不处理主键、空值语义、转义、时间格式或 SQL 注入防护；真正安全的做法是只用反射做元数据映射，SQL 构建交给预编译语句 + 参数绑定。
字段为 nil 指针时调 v.Interface() 必 panic
结构体字段如 *string、*int64 为 nil 时，未检查就调 v.Interface() 会触发 nil pointer dereference。
- 必须先判断：
v.Kind() == reflect.Ptr && v.IsNil()，再决定跳过、生成IS NULL或填默认值 -
v.IsValid()对 nil 指针返回 true，不能替代v.IsNil() - 若字段是
interface{}类型，需先v.Elem()解一层再判断，否则v.Interface()返回空 interface{} 而非底层值
结构体字段名和数据库列名不一致时，别硬写 map
用 map[string]interface{} 动态传参看似灵活，但丢失类型信息，参数绑定易错，且无法区分 nil（应为 IS NULL）和空字符串（应为 = ''）。
- 优先用带
dbtag 的结构体，例如：Name *string `db:"user_name"` - 反射时统一读
v.Tag.Get("db")，为空字符串则跳过该字段，为"-"则显式忽略 - 嵌入匿名字段（
Anonymous == true）且 tag 含",inline"时，需递归展开并拼接前缀（如extra_created_at），否则字段丢失或错位
命名参数（:name）和位置参数（?）不能混用
反射生成的 WHERE 子句若含 :name 占位符，直接喂给 database/sql 的 db.Query() 会报 sql: expected 0 arguments, got 1 —— 因为原生驱动只认 []interface{} 位置参数。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 选
sqlx就全程保持 struct / map 不变，由sqlx.Named()处理 - 选原生驱动，就得在反射阶段拆出两个切片：
args = append(args, v.Interface())和placeholders = append(placeholders, "?") -
sqlx.In()对IN (?)友好，但要求字段是 slice 类型，需用v.Kind() == reflect.Slice判断，并按v.Len()生成等量?
别在运行时反复调 reflect.TypeOf() 和遍历字段
每次查询都做 reflect.TypeOf(t).NumField() 遍历，是典型性能陷阱；字段映射关系是静态的，应该缓存。
- 首次解析后，把
map[string]string（字段名 → 列名）和字段顺序列表存为包级变量或 sync.Map - 避免在循环中重复调
v.FieldByName()—— 它比遍历NumField()更慢，且对小写字段无效（仅导出字段可访问） - 自定义类型（如
type UserID int64）若实现了driver.Valuer，应显式调v.Interface().(driver.Valuer).Value()，而非直接塞进 SQL 字符串
最常被忽略的一点：database/sql 的 Query 和 Exec 要求 SQL 是确定性字符串，反射拼出的动态表名或列名（如 "SELECT * FROM " + tableName）无法被预编译，会导致连接池复用失效、SQL 注入风险上升，以及 MySQL 的 query cache 失效。真正需要动态表名的场景，应通过白名单校验 + 显式允许，而非放任反射自由拼接。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
