namedarg（如sql.named）在gorm中不能直接使用，raw方法仅支持:xxx形式占位符配合map[string]interface{}参数；传sql.named会被忽略或导致错误，因其不被gorm解析，仅底层database/sql原生接口才支持。
NamedArg 在 GORM 中到底能不能用？
不能直接用。GORM 的 NamedArg（比如 sql.Named）在原生 SQL 查询中会被忽略或报错，因为 GORM 的 Session 和 DB.Raw() 并不解析 Go 标准库的 sql.Named 类型——它只认字符串键 + map 值的具名参数格式。
GORM 正确的具名参数写法是 map[string]interface{}
所有支持具名参数的 GORM 方法（如 Where、First、Raw）都要求传入 map[string]interface{}，而不是 sql.Named。GORM 会把 key 当作占位符名，自动替换成对应方言的语法（例如 PostgreSQL 用 :name，MySQL 用 ?name 或直接插值）。
db.Raw("SELECT * FROM users WHERE age > :min_age AND status = :status", map[string]interface{}{"min_age": 18, "status": "active"})- 在
Where中混用：db.Where("age > :min_age AND status = :status", map[string]interface{}{"min_age": 18, "status": "active"}).Find(&users) - 嵌套结构体字段也能展开：如果传
map[string]interface{}{"u": User{Name: "foo"}}，GORM 会尝试解构u.Name，但不推荐——容易歧义，优先用扁平 key
为什么 Raw SQL 里写 :name 却不报错？
GORM 的 Raw 方法内部做了预处理：遇到 :xxx 形式的占位符时，会查找传入的参数 map 是否含 "xxx" 键；找不到就 panic，找得到就替换为转义后的值（防注入）。这不是数据库驱动原生支持，而是 GORM 自己实现的文本替换逻辑。
- PostgreSQL 模式下，
:name会被替换成$1，并绑定参数（安全） - SQLite/MySQL 模式下，
:name可能被直接替换成带引号的字符串字面量（如'active'），依赖 GORM 的类型推断 - 别手写
?name或@name：GORM 不识别这些，只认:name（且仅在Raw字符串中生效）
NamedArg 真正能用上的唯一场景：绕过 GORM、直连 database/sql
如果你显式调用 db.Statement.ConnPool.(*sql.DB) 获取底层 *sql.DB，再用 QueryRowContext 等原生方法，这时才能用 sql.Named。但这意味着你完全脱离 GORM 的模型映射、钩子、事务管理等能力。
- 示例：
db.Statement.ConnPool.(*sql.DB).QueryRowContext(ctx, "SELECT name FROM users WHERE id = @id", sql.Named("id", 123)) - 注意：不同数据库驱动对
sql.Named支持程度不同（PostgreSQL 驱动支持:name和$1，MySQL 驱动只认?位置参数） - 这种写法和 GORM 的
NamedArg没关系——GORM 本身没导出任何NamedArg类型，纯属混淆了标准库概念
真正容易被忽略的是：GORM 的具名参数只在字符串中写 :key 才生效，且必须配 map[string]interface{}；传 sql.Named 不会报错但会被当普通值丢进参数列表，导致类型错位或 SQL 语法错误。
