反射FieldByName返回空值是因为只能访问导出字段（首字母大写），小写字段即使有db tag也无法通过FieldByName获取；需确保字段名大写或遍历所有字段比对tag。
反射读取结构体字段时，FieldByName 返回空值？
因为反射默认只能访问**导出字段**（首字母大写），小写字段会被忽略，哪怕你用 Tag 标了 db:"user_name" 也没用。
常见错误现象：reflect.Value.FieldByName("name").IsValid() 返回 false，导致后续拼 SQL 时字段直接消失。
- 确保结构体字段首字母大写，例如
UserName string `db:"user_name"` - 不要试图用反射“绕过”导出规则——Go 的反射不支持访问未导出字段，这是语言设计，不是 bug
- 如果必须兼容小写字段（比如 legacy struct），得先用
reflect.TypeOf(v).NumField()遍历所有字段，再比对Tag值匹配，而不是依赖FieldByName
用 reflect.StructTag 解析 db tag 时 panic？
StructTag.Get("db") 在 tag 不存在或格式错误（比如漏引号、含非法字符）时不会 panic，但返回空字符串；真正容易 panic 的是后续调用 strings.Split(...)[0] 这类操作——没判空就切片。
使用场景：从 db:"id,pk auto_increment" 中提取列名和属性。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 永远先检查
tag := field.Tag.Get("db")是否为空，再处理 - 推荐用
strings.TrimSpace(tag)清理空格，避免因空格导致== ""判定失败 - 别硬拆空格分隔的属性，优先考虑逗号分隔（如
db:"created_at,notnull,default:now()"），更易解析也更接近主流 ORM 习惯
拼接 INSERT 语句时，reflect.Value.Interface() 导致类型丢失？
把 reflect.Value 直接塞进 fmt.Sprintf 或 SQL 参数占位符，看似能 work，但一旦字段是自定义类型（比如 type UserID int64），Interface() 返回的是底层类型，可能绕过其 Scan/Value 方法，导致数据库写入异常或类型不匹配。
性能影响：频繁调用 Interface() 不贵，但若配合类型断言（比如 v.Interface().(time.Time)）且断言失败，会 panic。
- 对基础类型（
int,string,bool等）可安全用v.Interface() - 对实现了
driver.Valuer或sql.Scanner的自定义类型，应显式调用v.Interface().(driver.Valuer).Value()获取 DB 友好值 - 更稳妥的做法：统一走
sql.Named或参数化查询，把反射值转成interface{}后交给database/sql自己处理，别手动拼字符串
为什么不用 database/sql 原生支持的 NamedQuery 而要手撸反射？
因为 NamedQuery 只支持 map 或 struct 指针传参，但**不解析嵌套结构、不支持字段 tag 映射、不生成动态列名列表**——它只做参数绑定，不做 schema 映射。
ORM 底层真正的复杂点不在“能不能拼 SQL”，而在“怎么让同一段反射逻辑同时支持 INSERT/UPDATE/SELECT WHERE，并正确处理零值、指针 nil、时间精度、JSON 字段序列化”。
- 手写反射构造器的核心价值是控制字段映射策略（比如忽略
db:"-"、自动补updated_at）、而非替代sqlx或gorm - 别在反射层做 SQL 注入过滤——那是
database/sql预编译的事；反射只负责把 struct 字段名 → 列名、字段值 → 参数值，两件事必须严格分离 - 最容易被忽略的一点：MySQL 和 PostgreSQL 对列名大小写的处理不同（前者默认忽略，后者按双引号敏感），反射生成的列名最好统一转小写或加反引号，别依赖数据库默认行为
