结构体字段与数据库列名不一致时，必须通过显式标签（如db:"user_name"或gorm:"column:user_name"）映射，否则默认驼峰转蛇形规则不可靠且易导致漏赋值或静默失败。
直接说结论：别用 interface{} 做中间层做属性转换，优先选泛型 + 显式字段映射；框架能省代码，但掩盖不了字段语义错配和空值逻辑缺失的问题。
struct 字段名和数据库列名不一致怎么映射
这是最常踩的坑——结构体字段是 UserName，数据库列却是 user_name，不加 tag 就会漏赋值。
- 必须显式用
db:"user_name"或json:"user_name"等 tag 标注，GORM、XORM、mapstructure都依赖它 - 别指望“自动下划线转驼峰”：GORM 的
SingularTable和命名策略只影响表名/字段名生成，不改变运行时映射行为 - 如果列名完全动态（比如 pivot 查询），就别硬套 ORM，改用
[]map[string]interface{}+ 泛型转换函数，自己控字段提取逻辑
time.Time 字段查出来总是 0001-01-01 怎么办
不是框架 bug，是 scan 阶段类型没对上。MySQL 的 DATETIME NULL 和 Go 的 time.Time 不兼容。
- 字段允许 NULL？Go 结构体必须声明为
*time.Time，否则 NULL 被跳过，留零值 - 字段不允许 NULL？确保数据库该列设了
NOT NULL DEFAULT CURRENT_TIMESTAMP，避免插入时为 NULL - 用 GORM 时，别漏掉
gorm:"type:datetime;not null"这类显式类型声明，尤其在 MySQL 8+ 严格模式下
用 mapstructure 做 map → struct 转换要注意什么
它本身不支持泛型，但能被泛型函数安全调用——前提是配置得当，否则错误难定位。
- 关掉
WeaklyTypedInput: true：虽然能让"123"自动转int，但会掩盖字段类型定义错误，API 层建议保持 strict - 每行数据都要包装错误上下文：
fmt.Errorf("row %d: %w", i, err)，否则你永远不知道是第几条记录崩了 - 时间字段要注册自定义解码器：
decoder.RegisterCustomTypeMap(reflect.TypeOf(time.Time{}), func(value string) (interface{}, error) { ... })，ISO8601 字符串不会自动识别成time.Time
什么时候该放弃框架，手写转换逻辑
框架简化的是“标准路径”，但现实里常走“野路子”。以下三类情况，手写更稳、更快、更可控：
- 对接老系统，SQL 返回列名混乱、无固定 schema（比如
SELECT * FROM dynamic_table WHERE type = ?） - 需要统一处理多种数据源：MySQL 行、CSV 行、HTTP JSON 响应，字段语义相同但格式各异
- 性能 profiling 确认
Rows.Scan是瓶颈，且字段数固定、结构简单——这时用泛型 +unsafe.Slice直接内存拷贝，比反射快 3–5 倍
真正容易被忽略的是字段空值的业务含义：数据库里 age 是 NULL，到底是“未填写”还是“不适用”？框架不管这个，得靠你加一层校验或用 sql.NullInt64 显式区分。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
