Go Squirrel 字节切片为什么不会自动展开成 IN 列表

Go Squirrel 不会把 sq.Eq{"kind_code": []uint8{5, 9, 12}} 自动展开成 IN 列表，因为 Go 中 byte 是 uint8 的别名，[]uint8 与 []byte 是同一种类型，而字节切片本来就可以作为一个数据库参数值。若这些元素代表多个数字条件，应显式转换成 []int64 等数值切片；若它们代表二进制内容，则应保留单值语义。

官方地址：https://github.com/Masterminds/squirrel

这个选择体现了查询构造器的一项取舍：优先尊重数据库参数类型，而不是把所有 Go 切片都视为多个条件。它解决的是类型含义问题，不需要更换占位符格式，也不能仅靠给变量换个名字修复。

字节切片同时也是一个数据库参数值

想象一个查询模块同时接收两类输入：一段文件摘要的字节，以及一组长度不大的数字类型码。二者在 Go 中都可能暂存为字节切片，但前者需要比较完整内容，后者需要匹配其中任意一个数值。Squirrel 看到的是实际类型，不知道变量名 codes 或 digest 代表哪种业务含义。

标准库 database/sql/driver 把 []byte 列为可传递的值类型。Squirrel 的列表识别会先排除可作为单个驱动值的对象，再考虑数组或切片。普通数字切片进入列表处理，而 []byte 被留在单个参数的范围内。

Eq 的列表展开取决于值类型

这里描述的是 Squirrel 的 Eq 条件构造，不应外推成“只要字符串 SQL 中出现 IN，任何切片参数都会自动展开”。如果手写 Where("kind_code IN (?)", values)，一个问号本身并不表达如何生成多个占位符。应选择 Eq 的集合语义，或由应用明确构造占位符和逐项参数。

让类型表达业务意图

下面的完整示例同时展示二进制值和数字集合。它仅构造 SQL 与参数，便于读者在自己的项目中观察实际类型；没有建立数据库连接，也没有把生成的 SQL 当作数据库执行记录。

package main

import (
    "fmt"
    "log"

    sq "github.com/Masterminds/squirrel"
)

func show(label string, condition sq.Eq) {
    // 这里只生成SQL和参数，不连接数据库或执行查询。
    query, args, err := sq.Select("id").From("records").
        Where(condition).ToSql()
    if err != nil {
        log.Fatal(err)
    }
    fmt.Printf("%s: %s; 参数个数=%d\n", label, query, len(args))
    for i, arg := range args {
        fmt.Printf("参数%d 类型=%T 值=%v\n", i, arg, arg)
    }
}

func main() {
    codes := []byte{5, 9, 12}
    // 二进制内容作为单个值，保留[]byte类型。
    show("二进制等值", sq.Eq{"payload": codes})

    // 如果业务含义是数字类型码集合，逐项转换，表达IN意图。
    numbers := make([]int64, len(codes))
    for i, code := range codes {
        numbers[i] = int64(code)
    }
    show("数字集合", sq.Eq{"kind_code": numbers})
}

根据构造规则，第一项对应 payload = ?，携带一个字节切片参数；第二项对应 kind_code IN (?,?,?)，携带三个数字参数。这些是代码意图和库规则的说明，不是本文实测输出。真正执行时，列类型、SQL方言和所用驱动仍需相互匹配。

Go 不支持把整个 []byte 直接强制转换成 []int64，示例逐项转换，每个字节的0到255数值都能直接放进 int64。如果源数据是带编码的二进制协议，不能把每个字节机械地视为一个类型码，应先按协议解码。

空集合和多段二进制内容需要分别约定

空数字列表在 Eq 中生成恒假条件；但空 []byte 仍属于字节值问题，不能因为长度为0就假定它也表示“没有候选类型码”。如果参数可以为空，应在输入层先判断它的业务含义：是不加筛选、匹配空集合，还是比较空二进制值。不要让同一个 []byte 类型承担三种未说明的含义。

若要匹配多个完整二进制值，概念上应表达“二进制值的集合”，而非“一个二进制值中的多个字节”。例如外层集合与内层字节块是不同层级；是否采用嵌套字节切片还要结合驱动和列的能力确认。本文的数字转换方案只用于单字节数值集合，不适合把多块二进制标识拆散。

采用时观察参数结构，不只看SQL文字

如果生成的语句不是预期的 IN，优先检查传给 Eq 的实际类型和参数个数。SQL中的问号数量能反映部分结构，但不能替代参数类型判断。切换成 Dollar 占位符只改变占位符文本形式，不会把二进制值转成数字集合。

在团队接口中，建议直接让数字集合参数使用 []int64 或项目约定的数字类型；二进制参数使用 []byte 并写清长度、编码等要求。这样调用方不必知道构造器内部的特殊分支，也能减少后来误改查询含义的机会。没有独立性能数据时，不应声称某种改写必然更快；这里的目标是让条件表达正确。

• 确认元素代表字节内容，还是多个数字候选。
• 查看运行时实际类型，[]uint8并不避开[]byte语义。
• 需要数字 IN 时逐项转换成数字切片。
• 对空集合写出明确业务政策。
• 保持参数绑定，不把输入拼接进SQL字符串。

type Codes = []uint8 能改变行为吗？不能，类型别名不会改变原本的类型身份。为了表达数字集合，显式构造数值切片更清楚。

改成字符串列表是否合适？只有列和业务都以字符串为值时才合适。不要仅为触发 IN 而无条件改变数字的类型。

ToSql 没报错就说明查询正确吗？不说明。它表示查询构造没有报告错误，业务含义和实际数据库执行仍是另一个层面。

参考：Squirrel 字节切片官方说明、Eq 与列表识别实现、Go 数据库驱动值类型。