sql.nullstring不能直接当string用，因为它是含string和valid字段的结构体，直接传入string参数函数会panic或混淆null与空值；必须显式检查valid再取string，scan需用指针避免valid丢失，json序列化需自定义marshaljson或转为string，orm中优先用string。
sql.NullString 为什么不能直接当 string 用
因为 sql.NullString 是个结构体，不是字符串类型，它有 String 字段和 Valid 字段。直接传给需要 string 的函数（比如 fmt.Println、json.Marshal 或 ORM 字段赋值）会 panic 或序列化出空字符串，但你根本不知道是 null 还是空值。
- 常见错误现象：
panic: json: unsupported type: sql.NullString，或字段始终显示为空，查数据库发现其实是NULL - 正确做法：必须显式检查
.Valid，再取.String—— 没有捷径 - 别依赖
fmt.Sprintf("%s", ns)，它会把Valid=false的情况转成空字符串，掩盖 null 语义
Scan 时忘记初始化 sql.NullString 变量
Go 的 sql.Rows.Scan 要求传入变量地址，而 sql.NullString 是值类型，如果声明后没取地址，Scan 会写到临时副本里，原变量不变，Valid 始终为 false。
- 错误写法：
var ns sql.NullString; row.Scan(&ns)→ 看似对，实则危险（取决于 Go 版本和扫描器实现，行为不一致） - 稳妥写法：统一用指针
ns := &sql.NullString{}; row.Scan(ns)，或声明后立即取地址var ns sql.NullString; row.Scan(&ns)（注意：必须确保ns是可寻址的局部变量） - 更安全的习惯：所有
sql.Null*类型都用指针接收，避免栈上复制导致 Valid 丢失
JSON 序列化 sql.NullString 时丢失 null 语义
默认情况下，json.Marshal 不认识 sql.NullString，会把它当普通 struct 序列化成 {"String":"xxx","Valid":true}，前端完全无法消费。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 解决方式只有两个：自己实现
MarshalJSON方法，或提前转换成可序列化的类型（如 *string） - 推荐转换方案：
func (n sql.NullString) Ptr() *string { if !n.Valid { return nil }; return &n.String }，然后用json.Marshal(map[string]interface{}{"name": ns.Ptr()}) - 注意兼容性：MySQL 的
TINYINT(1)常被映射为sql.NullBool，同样要处理Ptr()或自定义 Marshal，别只盯着 String
ORM（如 GORM）里混用 sql.NullString 和普通 string
GORM v2 默认不支持 sql.Null* 类型的自动扫描，除非字段类型明确声明且结构体 tag 配置正确；否则它会静默跳过该字段，或报 unsupported scan, storing driver.Value type <nil> into type *string</nil>。
- 使用 GORM 时，优先用
*string替代sql.NullString：GORM 能自动处理 nil 指针 ↔ NULL，语义清晰，代码更少 - 若必须用
sql.NullString（例如对接 legacy 代码），需在 struct tag 加gorm:"scanner:sql.NullString"并确保实现了Scanner/Valuer接口 - 容易踩的坑：GORM 的
Find和Raw查询行为不同——Raw必须手动 Scan 到sql.Null*变量，Find才走模型映射逻辑
Null 值的本质不是“空”，而是“未知”。Go 的类型系统不会替你记住这一点，每次从数据库出来、进 JSON、传给下游函数之前，都得亲手确认 Valid —— 少一次检查，就多一个生产环境里查不到原因的空字段。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
