防止SQL注入的go语言database/sql标准库最佳实践

在Go语言中使用database/sql标准库防止SQL注入，核心只有一句话：永远不要用字符串拼接的方式构造SQL语句，而是使用参数化查询（Prepared Statement），也就是用问号占位符（?）或者命名参数（如$1、$2）来代替直接拼接用户输入。只要你做到这一点，database/sql底层会自动帮你处理转义和参数绑定，SQL注入的风险基本归零。下面我把这件事从头到尾讲透，包括具体代码、常见陷阱、进阶技巧和生产环境中的注意事项。

一、SQL注入到底是怎么发生的

SQL注入的本质是：用户输入的数据被当作SQL代码的一部分执行了。比如你写了这样一段代码，把用户名直接拼进SQL里：

query := "SELECT * FROM users WHERE username = '" + username + "'"
db.Query(query)

如果用户输入的username是 admin' OR '1'='1，那最终执行的SQL就变成了：

SELECT * FROM users WHERE username = 'admin' OR '1'='1'

这条语句永远为真，攻击者直接绕过了认证。这就是最经典的SQL注入。而在Go的database/sql中，只要你用了参数化查询，这种事情根本不可能发生。

二、database/sql标准库的参数化查询用法

Go的database/sql标准库天然支持参数化查询。你只需要把SQL语句中的变量部分换成?占位符，然后把实际参数作为独立的参数传给Query、QueryRow、Exec等方法即可。

query := "SELECT * FROM users WHERE username = ? AND status = ?"
rows, err := db.Query(query, username, status)

这里的?就是占位符，database/sql在底层会调用驱动（比如mysql驱动、pq驱动等）将参数安全地绑定到Prepared Statement上，驱动会自动处理转义，确保参数只被当作数据而不是SQL代码。这是最基本也是最重要的防护手段。

对于插入操作同样适用：

stmt := "INSERT INTO orders (user_id, amount, created_at) VALUES (?, ?, ?)"
result, err := db.Exec(stmt, userID, amount, time.Now())

对于更新和删除操作也一样，不需要任何特殊处理，只要把值换成?就行。

三、使用命名参数的写法（PostgreSQL等数据库）

如果你用的是PostgreSQL，数据库驱动支持命名参数，写法更清晰：

query := "SELECT * FROM products WHERE category = $1 AND price < $2"
rows, err := db.Query(query, category, maxPrice)

这种写法的好处是参数顺序一目了然，不容易搞混。MySQL驱动不支持这种写法，但PostgreSQL的pq驱动和cockroachdb驱动都支持。具体用哪种占位符取决于你使用的数据库驱动，但核心原则不变：不要拼接，用占位符。

四、Prepared Statement的显式使用

除了直接用Query和Exec，你还可以显式地创建Prepared Statement对象，适合需要重复执行同一条SQL的场景：

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

row := stmt.QueryRow(userID)
var name string
err = row.Scan(&name)

Prepare方法会在数据库端预编译SQL语句，后续每次执行只需要传入参数，性能更好，同时安全性完全一样。注意一定要defer stmt.Close()来释放资源，否则会造成连接泄漏。

五、这些写法都是错的，千万别踩坑

很多开发者虽然知道不能拼接，但在某些场景下还是会犯错。下面列出几种典型的错误写法：

错误一：用fmt.Sprintf构造SQL：

query := fmt.Sprintf("SELECT * FROM users WHERE id = %d", userID)
rows, err := db.Query(query)

这和直接拼接没有任何区别，userID如果被篡改，照样注入。即使是数字类型，也不要这么干。

错误二：表名、列名用参数化：

// 这是不行的！表名和列名不能用?占位
query := "SELECT * FROM ? WHERE id = ?"
db.Query(query, tableName, id)

参数化查询只能用于值（value），不能用于表名、列名、ORDER BY方向等SQL结构部分。如果你需要动态表名，必须用白名单校验：

allowedTables := map[string]bool{"users": true, "orders": true}
if !allowedTables[tableName] {
    return fmt.Errorf("invalid table name")
}
query := "SELECT * FROM " + tableName + " WHERE id = ?"
db.Query(query, id)

错误三：用字符串拼接构造IN子句：

// 错误写法
ids := "1,2,3"
query := "SELECT * FROM users WHERE id IN (" + ids + ")"

// 正确写法：动态生成占位符
placeholders := make([]string, len(idList))
args := make([]interface{}, len(idList))
for i, id := range idList {
    placeholders[i] = "?"
    args[i] = id
}
query := "SELECT * FROM users WHERE id IN (" + strings.Join(placeholders, ",") + ")"
db.Query(query, args...)

IN子句是最容易出错的地方之一，因为你不知道有多少个参数，必须动态构建占位符。上面的写法是安全且通用的。

六、事务中的参数化查询同样要注意

在事务中执行SQL，很多人会忘记继续使用参数化：

tx, err := db.Begin()
if err != nil {
    log.Fatal(err)
}
defer tx.Rollback()

// 正确
stmt, err := tx.Prepare("UPDATE accounts SET balance = balance - ? WHERE id = ?")
if err != nil {
    return err
}
defer stmt.Close()

_, err = stmt.Exec(amount, fromID)
if err != nil {
    return err
}

_, err = stmt.Exec(amount, toID)
if err != nil {
    return err
}

err = tx.Commit()

事务里的每一条SQL都要遵循同样的原则。尤其是涉及资金操作的场景，一个疏忽就可能导致严重后果。

七、结合其他安全措施形成纵深防御

参数化查询是防止SQL注入的第一道也是最重要的一道防线，但在生产环境中，你还需要配合其他措施：

第一，最小权限原则。数据库连接使用的账号只给必要的权限，不要用root账号连接业务数据库。比如一个只读服务就只给SELECT权限。

第二，输入验证。虽然参数化查询已经解决了注入问题，但你仍然应该在应用层对输入做基本校验，比如长度限制、格式校验、类型检查等。这不是防注入，而是防其他类型的攻击和脏数据。

第三，使用连接池和超时控制。database/sql自带连接池，合理设置MaxOpenConns、MaxIdleConns和ConnMaxLifetime，防止连接耗尽。同时设置合理的查询超时：

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
rows, err := db.QueryContext(ctx, query, args...)

第四，记录审计日志。对所有涉及数据修改的操作记录日志，方便事后排查问题。

八、常见数据库驱动的注意事项

Go的database/sql是标准库，具体的参数绑定行为由底层驱动决定。以下是几个常用驱动的要点：

MySQL驱动（go-sql-driver/mysql）：使用?占位符，支持多语句执行（但建议关闭），需要注意charset设置。

PostgreSQL驱动（lib/pq或pgx）：支持$1、$2命名参数，pgx还提供了更高性能的接口和更好的类型支持。

SQLite驱动（mattn/go-sqlite3或modernc.org/sqlite）：同样支持?，但SQLite本身对参数化支持有限，注意不要在SQLite中使用某些不安全的函数。

不管你用哪个驱动，只要你坚持用占位符传参，安全性就是有保障的。

九、性能层面的考量

有人担心参数化查询会影响性能，实际上恰恰相反。Prepared Statement在数据库端预编译一次，后续重复执行时省去了解析和编译的开销，在高并发场景下性能更优。尤其是批量操作时，先Prepare再循环Exec，比每次都重新发送完整SQL要快得多。

另外，database/sql的连接池本身也做了优化，你不需要手动管理连接的创建和销毁，标准库已经帮你处理好了。只要合理配置连接池参数，性能不会成为瓶颈。

十、总结：一句话记住核心原则

防止SQL注入在Go语言中没有任何技术难度，你只需要记住一个铁律：所有用户输入、外部数据，一律通过参数化查询传入，绝不拼接。表名列名等结构性内容用白名单校验，其余全部用?或$N占位。做到这一点，你的数据库操作在SQL注入层面就是安全的。剩下的就是工程实践层面的事情——权限控制、输入校验、日志审计、超时管理，把这些做好，你的数据库层就真正做到了安全可靠。

防止SQL注入的go语言database/sql标准库最佳实践

服务指南

帮助中心