Go 的 database/sql 不支持将切片直接传入单个 ? 占位符，必须手动构建等长 ? 序列并展开为 []interface{} 参数；空切片需提前判断，否则生成 IN () 会报语法错误。
Go 的 database/sql 包不支持把切片直接塞进单个 ? 占位符里——比如 WHERE id IN (?) 配 []int{1,2,3} 会报错或逻辑错误，必须为每个值单独生成一个 ? 并逐个传参。
database/sql 中手动构建 IN 占位符的通用写法
核心是两件事：把原始切片转成 []interface{}，再按长度拼出对应数量的 ? 字符串。常见错误是忘记类型转换或空切片没处理。
- 空切片必须提前判断，否则生成
IN ()会导致 SQL 语法错误 -
[]int、[]string等不能直接传给db.Query，得用循环或reflect转成[]interface{} - 占位符字符串建议用
strings.Repeat("?,", n-1) + "?"，避免末尾多逗号 - SQL 拼接时注意空格和括号位置，例如
"WHERE id IN (" + placeholders + ")"
sqlx.In() 是最省心的替代方案
sqlx.In() 就是为这事设计的：它自动拆开切片、替换 (?)、返回新 SQL 和参数列表，不用手写循环。但要注意它只处理第一个 ?，且要求输入 SQL 中的 IN 子句必须写成 IN (?) 形式。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 调用后要拿返回的
sql和args一起传给db.Query或db.Select - 如果 SQL 里还有其他
?（比如AND status = ?），sqlx.In()不会动它们，顺序得自己对齐 - 底层仍是动态占位符 +
[]interface{}展开，安全性跟手写一致
使用 Gendry 或 Goqu 构建带 IN 条件的查询
这类查询构建器把 IN 当作普通条件处理，写法更接近 SQL 语义，适合中大型项目。但要注意它们内部仍依赖 sqlx.In() 或类似逻辑，不是魔法。
立即学习“go语言免费学习笔记（深入）”；
- Gendry 中写
"status in": []int{1,2,3}，自动转成status IN (?, ?, ?) - Goqu 用
goqu.C("id").In([]int{1,2,3})，生成的 SQL 可读性高，也支持嵌套条件 - 构建器通常自带空值过滤，但
IN切片为空时行为不统一——有的跳过整个条件，有的仍生成IN ()，得看文档
真正容易被忽略的是边界情况：空切片、含 nil 元素的切片、跨驱动兼容性（MySQL 用 ?，PostgreSQL 用 $1）。哪怕用了 sqlx.In()，也要确认返回的 SQL 是否符合目标驱动的占位符规则。
