Go 的 database/sql 驱动不支持在子查询或 JOIN 条件中通过 ? 占位符动态引用表列（如 profiles.user_id），仅支持传入字面量参数；直接拼接变量易引发 SQL 注入，正确做法是将外部变量显式传入所有需参数化的位置。
go 的 database/sql 驱动不支持在子查询或 join 条件中通过 `?` 占位符动态引用表列（如 `profiles.user_id`），仅支持传入字面量参数；直接拼接变量易引发 sql 注入，正确做法是将外部变量显式传入所有需参数化的位置。
在您提供的 SQL 查询中，核心问题并非“Go 不支持列引用”，而是 SQL 参数化机制的固有限制：? 占位符只能替换标量值（如整数、字符串），不能替换标识符（如表名、列名、别名）或表达式（如 profiles.user_id）。因此，子查询中 WHERE user_id = profiles.user_id 的 profiles.user_id 是一个列引用表达式，无法被 ? 替代——而您当前的 Go 代码却试图用 args := []interface{}{userId} 去“覆盖”这个位置，但该 ? 实际上并未出现在原始 SQL 字符串中（您只在 LEFT JOIN profile ON profile.user_id = 1627 处硬编码了 1627，子查询里仍是 profiles.user_id），导致数据库执行时 profiles.user_id 在子查询上下文中解析失败（可能为 NULL 或未定义），进而使 NOT IN 过滤失效。
✅ 正确解决方案是：将用户 ID 作为参数，显式传入子查询和主 JOIN 两个位置：
query := `SELECT DISTINCT
q.id AS question_id,
q.question,
q.priority,
q.type
FROM questions q
LEFT JOIN profile p ON p.user_id = ?
LEFT JOIN group g ON g.user_id = p.user_id
WHERE q.status = 1
AND g.status = 1
AND q.id NOT IN (
SELECT DISTINCT question_id
FROM answers
WHERE user_id = ?
)`
// 注意：两个 ? 对应同一个 userId，需传入两次
rows, err := db.Query(query, userId, userId)
if err != nil {
log.Fatal("Query failed:", err)
}
defer rows.Close()
var questions []Question // 假设已定义结构体
for rows.Next() {
var q Question
if err := rows.Scan(&q.QuestionId, &q.Question, &q.Priority, &q.Type); err != nil {
log.Fatal("Scan failed:", err)
}
questions = append(questions, q)
}
if err := rows.Err(); err != nil {
log.Fatal("Rows iteration error:", err)
}
⚠️ 关键注意事项：
-
禁止字符串拼接用户输入：切勿用
fmt.Sprintf("... WHERE user_id = %d", userId)拼接 SQL，极易导致 SQL 注入； - 表名/列名需静态确定：若需动态表名（如分表场景），必须通过白名单校验后拼接，不可参数化；
-
NOT IN与 NULL 安全性：当answers表中question_id存在 NULL 时，NOT IN (...)整体返回空结果。更健壮写法是改用NOT EXISTS：AND NOT EXISTS ( SELECT 1 FROM answers a WHERE a.user_id = ? AND a.question_id = q.id ) -
使用反引号（`）书写多行 SQL：提升可读性，避免
+拼接错误； -
始终检查
rows.Err()：rows.Next()结束后调用，捕获迭代末尾潜在错误。
综上，Go 中 SQL 参数化本质是驱动层对 ? 的值绑定，而非服务端预编译的“智能列推导”。明确区分“值参数”与“结构语法”，将外部变量统一、显式地注入所有需要的位置，即可彻底解决此类过滤逻辑异常问题。
