防止SQL注入的Go database/sql预编译语句使用要点

防止SQL注入最有效的手段就是使用Go语言database/sql包提供的预编译语句（Prepared Statements），核心原理是将SQL语句模板和用户输入参数分离，数据库引擎在编译阶段就确定了SQL结构，用户输入永远只会被当作数据值处理，而不会被解析成SQL指令。具体做法就是用占位符（?或$1、$2等命名占位符）替代拼接的用户输入，然后通过Exec、Query、QueryRow等方法传入参数，而不是用fmt.Sprintf或字符串拼接来构造SQL。

很多Go开发者在写数据库操作代码时，习惯直接把变量拼进SQL字符串里，比如写成fmt.Sprintf("SELECT * FROM users WHERE name = '%s'", name)，这种写法就是SQL注入的温床。攻击者只要在name参数里输入类似' OR '1'='1这样的内容，整条查询逻辑就被篡改了。而预编译语句从根本上杜绝了这种风险，因为参数和SQL模板在传输到数据库时是分开的，数据库不会把参数值当作SQL语法的一部分来解析。

Go的database/sql包本身并不直接提供PreparedStatement对象，而是通过db.Prepare()方法返回一个stmt对象，然后在这个stmt上执行查询。基本流程是：先Prepare，再Exec或Query，最后Close。下面是一个最简单的示例：

package main

import (
    "database/sql"
    "fmt"
    "log"

    _ "github.com/go-sql-driver/mysql"
)

func main() {
    db, err := sql.Open("mysql", "user:password@tcp(127.0.0.1:3306)/dbname")
    if err != nil {
        log.Fatal(err)
    }
    defer db.Close()

    stmt, err := db.Prepare("SELECT id, name, email FROM users WHERE id = ?")
    if err != nil {
        log.Fatal(err)
    }
    defer stmt.Close()

    var id int
    var name string
    var email string

    err = stmt.QueryRow(id).Scan(&id, &name, &email)
    if err != nil {
        log.Fatal(err)
    }

    fmt.Printf("ID: %d, Name: %s, Email: %s\n", id, name, email)
}

这里的问号?就是位置占位符，代表一个参数。QueryRow方法会自动把传入的参数绑定到对应的占位符上。注意，stmt对象是可以复用的，你可以多次调用stmt.Query或stmt.Exec，每次传入不同的参数值，这样既安全又高效，避免了重复编译SQL的开销。

需要特别注意的是，不同的数据库驱动使用的占位符语法不一样。MySQL驱动（go-sql-driver/mysql）使用问号?，PostgreSQL驱动（lib/pq或pgx）使用$1、$2、$3这种数字编号的命名占位符，SQLite驱动则两者都支持。如果你用错了占位符，代码编译不会报错，但运行时会报参数绑定错误。

// PostgreSQL 使用 $1, $2, $3 占位符
stmt, err := db.Prepare("SELECT * FROM users WHERE id = $1 AND status = $2")
if err != nil {
    log.Fatal(err)
}
defer stmt.Close()

rows, err := stmt.Query(1001, "active")
if err != nil {
    log.Fatal(err)
}
defer rows.Close()

// SQLite 同时支持 ? 和 $1
stmt, err := db.Prepare("INSERT INTO users(name, age) VALUES(?, ?)")
// 或者
stmt, err := db.Prepare("INSERT INTO users(name, age) VALUES($1, $2)")

在实际项目中，如果你需要同时支持多种数据库，建议在代码里做适配层，或者使用统一的ORM框架如GORM来屏蔽底层差异。但理解底层原理非常重要，因为ORM底层做的也是预编译和参数绑定。

预编译不仅仅用于查询，插入、更新、删除操作同样适用，而且效果一样好。下面分别给出各场景的代码示例。

插入操作使用stmt.Exec：

stmt, err := db.Prepare("INSERT INTO users(name, email, age) VALUES(?, ?, ?)")
if err != nil {
    log.Fatal(err)
}
defer stmt.Close()

result, err := stmt.Exec("张三", "zhangsan@example.com", 28)
if err != nil {
    log.Fatal(err)
}

lastID, err := result.LastInsertId()
if err != nil {
    log.Fatal(err)
}
fmt.Println("插入成功，ID:", lastID)

更新操作：

stmt, err := db.Prepare("UPDATE users SET email = ?, age = ? WHERE id = ?")
if err != nil {
    log.Fatal(err)
}
defer stmt.Close()

_, err = stmt.Exec("newemail@example.com", 29, 1001)
if err != nil {
    log.Fatal(err)
}

删除操作：

stmt, err := db.Prepare("DELETE FROM users WHERE id = ?")
if err != nil {
    log.Fatal(err)
}
defer stmt.Close()

_, err = stmt.Exec(1001)
if err != nil {
    log.Fatal(err)
}

批量操作时，可以在循环中复用同一个stmt对象，每次传入不同参数执行。这种方式比每次都Prepare新的语句要高效得多，因为SQL只需要编译一次。

实际开发中最常见的场景是动态条件查询，比如用户可以按姓名、年龄、城市等多个字段筛选，不确定哪些条件会被传入。很多人在这里就放弃了预编译，转而用字符串拼接，这是非常危险的。正确的做法是动态构建参数列表和占位符，然后一次性绑定。

func searchUsers(db *sql.DB, name string, age int, city string) ([]User, error) {
    var query string
    var args []interface{}

    conditions := []string{}

    if name != "" {
        conditions = append(conditions, "name = ?")
        args = append(args, name)
    }
    if age > 0 {
        conditions = append(conditions, "age = ?")
        args = append(args, age)
    }
    if city != "" {
        conditions = append(conditions, "city = ?")
        args = append(args, city)
    }

    if len(conditions) == 0 {
        return nil, nil
    }

    query = "SELECT id, name, age, city FROM users WHERE " + strings.Join(conditions, " AND ")

    rows, err := db.Query(query, args...)
    if err != nil {
        return nil, err
    }
    defer rows.Close()

    var users []User
    for rows.Next() {
        var u User
        if err := rows.Scan(&u.ID, &u.Name, &u.Age, &u.City); err != nil {
            return nil, err
        }
        users = append(users, u)
    }
    return users, nil
}

这里的关键是：SQL模板中的占位符数量必须和args切片的长度严格对应。每个条件对应一个?和一个参数，db.Query会自动把args展开绑定到对应的占位符上。这种写法既保持了预编译的安全性，又实现了灵活的动态查询。

IN子句是另一个容易出错的地方。比如你想查询id在某个列表中的用户，不能直接把整个列表拼成一个字符串塞进占位符。正确做法是根据列表长度动态生成对应数量的占位符。

func getUsersByIDs(db *sql.DB, ids []int) ([]User, error) {
    if len(ids) == 0 {
        return nil, nil
    }

    placeholders := make([]string, len(ids))
    args := make([]interface{}, len(ids))

    for i, id := range ids {
        placeholders[i] = "?"
        args[i] = id
    }

    query := "SELECT id, name FROM users WHERE id IN (" + strings.Join(placeholders, ", ") + ")"

    rows, err := db.Query(query, args...)
    if err != nil {
        return nil, err
    }
    defer rows.Close()

    var users []User
    for rows.Next() {
        var u User
        if err := rows.Scan(&u.ID, &u.Name); err != nil {
            return nil, err
        }
        users = append(users, u)
    }
    return users, nil
}

注意，这里不能用一个占位符绑定整个切片，因为每个?只能绑定一个值。必须为每个元素生成一个独立的占位符和对应的参数。这也是为什么动态构建SQL模板时要格外小心的原因。

从性能角度看，预编译语句有两个明显优势：第一，SQL只需要编译一次，后续执行时数据库直接使用已编译的执行计划，减少了解析和优化的开销；第二，参数绑定避免了重复的字符串拼接和转义处理。在高并发场景下，这种优势会被放大。

但也有几个需要注意的点：

第一，stmt对象要及时Close。虽然defer可以保证，但在长生命周期的服务中，如果大量stmt对象不释放，会占用数据库连接资源。建议在函数级别使用defer stmt.Close()，或者使用连接池管理。

第二，Prepare失败时要处理错误。有些复杂SQL可能因为语法问题导致Prepare失败，这时候不应该继续执行。

第三，不要在循环外Prepare一个stmt然后在循环内反复Exec不同结构的SQL。预编译的前提是SQL结构相同，只是参数不同。如果SQL结构变了，需要重新Prepare。

第四，对于特别简单的一次性查询，直接用db.Query或db.Exec也可以，因为database/sql包内部会自动处理预编译。但如果是高频调用的查询，显式Prepare并复用stmt会更好。

在实际项目中，很多团队使用GORM、sqlx等ORM或数据库工具库。这些框架底层都是基于预编译语句实现的，但开发者仍然需要了解底层原理，因为框架的抽象层有时会让人忽略安全细节。比如GORM的Where条件默认就是参数化查询，但如果你用Raw()方法写原生SQL，就必须自己确保使用占位符。

// GORM 中安全的写法
var users []User
db.Where("name = ? AND age > ?", "张三", 18).Find(&users)

// 危险的写法，绝对不要这样做
db.Where("name = '" + name + "'").Find(&users)

sqlx库提供了NamedQuery等扩展功能，支持命名参数绑定，代码可读性更好，但底层仍然是预编译机制。

最后总结几个开发者常犯的错误。第一，以为用了预编译就万事大吉，实际上如果你在SQL模板里拼接了表名、列名等标识符（而非数据值），预编译是无法保护的，因为表名和列名不是数据参数，不能用占位符替代。这种情况需要用白名单校验。

第二，以为转义函数能替代预编译。手动做字符串转义不仅容易遗漏特殊字符，而且不同数据库的转义规则不同，远不如预编译可靠。

第三，在日志中打印完整的SQL语句和参数时要小心，不要把用户输入的敏感信息直接输出到日志文件中，这属于信息泄露风险。

第四，不要相信任何来自客户端的输入，即使你认为已经做了前端校验。所有数据在进入数据库之前，都必须通过参数化查询来处理。前端校验只是用户体验层面的优化，安全防线必须在后端。

总的来说，Go语言database/sql包的预编译语句是防止SQL注入最简单、最可靠的方案。只要你坚持使用占位符加参数绑定的方式，而不是字符串拼接，就能从根本上消除SQL注入风险。这不是什么高深的技术，而是每个Go后端开发者必须养成的基本编码习惯。