go 的 database/sql 不支持直接在 in 子句传 slice 参数，因预编译绑定只接受单值；需手动构建 ? 占位符序列并展开 slice 为独立参数，空 slice 需特殊处理，sqlx.in 仅为语法糖且不解决根本限制。
Go 的 database/sql 不支持直接在 IN 子句里传 slice 参数
你写 WHERE id IN (?)，然后用 exec(..., []int{1,2,3})，会报错：sql: converting argument $1 type: unsupported type []int, a slice of int。这不是 bug，是设计如此——database/sql 的占位符只接受单值，不展开 slice。
根本原因：SQL 预编译语句的参数绑定发生在数据库驱动层，而 IN 后面需要的是多个独立参数（?, ?, ?），不是“一个 slice 参数”。
- 别试图用字符串拼接
IN (1,2,3)—— 有 SQL 注入风险，且类型无法校验 - 别用
fmt.Sprintf拼IN (%s)再填入问号串 —— 容易漏转义、类型错位、空 slice 时语法错误 - PostgreSQL 用户注意：
ANY($1)可替代IN，但只适用于lib/pq或pgx，标准database/sql+pgx/v4仍需手动展开
手动构建问号序列 + 展开 slice 是最通用解法
核心动作就两步：算出需要几个 ?，再把 slice 里的每个元素单独作为参数传进去。没有魔法函数，必须自己做。
示例场景：查一批用户 ID 对应的记录：
// ids = []int64{101, 202, 303}
placeholders := make([]string, len(ids))
args := make([]interface{}, len(ids))
for i, id := range ids {
placeholders[i] = "?"
args[i] = id
}
query := "SELECT * FROM users WHERE id IN (" + strings.Join(placeholders, ",") + ")"
rows, err := db.Query(query, args...)
- 空 slice 要单独处理：
if len(ids) == 0，直接返回空结果或 panic，否则IN ()语法错误 - MySQL 最大参数数默认 65535，但实际受
max_allowed_packet限制；超量时得拆成多个查询或改用临时表 - SQLite 对参数数无硬限制，但过长 SQL 可能触发
SQLITE_TOOBIG
用 sqlx.In 简化但别忽略它的约束
sqlx 提供了 sqlx.In 辅助函数，帮你生成带问号的 query 和展开后的 args，但它只是语法糖，没绕过底层限制。
query, args, _ := sqlx.In("SELECT * FROM users WHERE id IN (?)", ids)
query = db.Rebind(query) // MySQL 驱动需重写 ? 为 %s，PostgreSQL 需重写为 $1, $2...
rows, _ := db.Query(query, args...)
-
sqlx.In不处理空 slice，调用前必须检查len(ids) > 0 -
db.Rebind必须调用，否则 MySQL 驱动会把?当字面量，查不到数据 - 它不校验 slice 元素类型，传
[]interface{}混合类型可能 runtime panic
IN 查询性能差？先确认是不是真瓶颈
很多人一看到 IN 就想优化，但实际慢的往往不是 IN 本身，而是没走索引、返回字段太多、或一次性查几千条。
- 确保
IN字段有索引，复合索引要注意最左匹配 - 避免
SELECT *，只取必要字段，尤其避开大 text/blob 列 - 如果
ids来自另一个子查询，优先考虑JOIN或物化中间结果，而不是先查出 ID 再 IN - PostgreSQL 用户可测
WHERE id = ANY(ARRAY[101,202,303])，有时比 IN 快，且支持空数组（ANY(ARRAY[]::int[])返回空）
IN 多值查询本身没有银弹，关键在参数生成逻辑是否健壮、是否覆盖空值/边界、是否和驱动行为对齐。写完记得压测下 1000+ ID 的 case，别只验了三个值就上线。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
