如何在 Golang Web 开发中防止 SQL 注入并过滤危险字符串

在 Go 的 Web 开发中，大家最常被问到的安全问题就是 “SQL 注入”。可以明确告诉你：只要你不手贱去拼 SQL 字符串，95% 的注入攻击就跟你没关系了。至于“过滤危险字符串”这种操作，它更多是用来制造心理安慰的，并不是防护的核心。 先看 Go 标准库 `database/sql`。它本身没有内置防注入能力，但把决定权交给了你：只要把用户的输入当作参数传递进去，而不是强行拼接到 SQL 字符串里，底层驱动（比如 `go-sql-driver/mysql` 或 `lib/pq`）就会在数据库协议层面帮你隔离“结构”和“值”。这就是所谓的参数化查询。 具体用法也很清晰： - MySQL / SQLite 用 `?` 占位符：`db.Query("SELECT * FROM users WHERE id = ?", userID)` - PostgreSQL 用 `$1`、`$2`：`db.Query("SELECT * FROM users WHERE id = $1 AND status = $2", userID, status)` - 注意别混用，否则会直接报错 `sql: expected 1 arguments, got 0` 甚至 panic - 千万别用 `fmt.Sprintf("WHERE id = %d", userID)` 或者 `"WHERE id = '" + username + "'"`，这类写法哪怕你自认为加了单引号或转义，照样可以绕过 那么问题来了：表名、列名、`ORDER BY` 这种东西能用占位符吗？答案是不能。`?` 和 `$1` 只能替代表达式中的“值”，无法替代 SQL 的结构。因为数据库在解析阶段就必须知道查哪张表、按哪个字段排序，这些信息不能在运行时绑定。 正确的做法是走白名单校验。比如排序字段，你可以提前定义一个合法的字段集合：`validSortFields := map[string]bool{"created_at": true, "score": true}`，查到不存在的字段直接拒绝。排序方向（`ASC` / `DESC`）也一样，需要白名单检查。对于分表场景，最好用常量映射来处理，比如 `switch input { case "prod": table = "users_prod"; case "test": table = "users_test" }`，别手贱去拼 `"users_" + input`。 再来说说 `IN` 子句和动态条件。用户传来的 ID 列表（比如 `[]int64{1,2,3}`），绝对不能直接用 `strings.Join` 塞进 SQL 字符串，那等于把注入的大门直接敞开。 如果是 GORM，正确写法是 `db.Where("id IN ?", ids)`，GORM 会自动把它展开为 `IN (?, ?, ?)` 并绑定参数。原生 `database/sql` 推荐用 `sqlx.In` 来辅助处理：先构造 `query, args, _ := sqlx.In("SELECT * FROM users WHERE id IN (?)", ids)`，然后再调用 `db.Query(query, args...)`。手动拼接 `"IN (" + strings.Join(idsStrs, ",") + ")"` 就是高危操作，万一某个 ID 被注入成 `"1, (SELECT password FROM admins)"`，后果你懂的。另外，空切片一定要单独处理：`len(ids) == 0` 时应该直接跳过该条件，避免生成 `IN ()` 导致语法错误。 这里还要提醒一下：`sql.NullString` 或 `interface{}` 并不是什么“安全包装”。`sql.NullString` 解决的是数据库 `NULL` 值的映射问题，跟防注入完全不沾边。如果你把它参数化后放进拼接的 SQL 里，照样等于裸奔。从 JSON 解析出的 `map[string]interface{}` 更不能直接丢给 `db.Query`，必须先断言类型：`if v, ok := data["id"].(int); ok { ... }`。另外，`sql.RawBytes` 是底层字节切片，不能直接当作可插占位符的值，需要先转成 `string` 或 `[]byte`。 还要注意日志输出。如果你打印 SQL 时，`query` 是拼接出来的字符串，那日志系统本身就可能成为注入的出口。打印原始 SQL 时，务必确认它来自预编译语句。即使是 ORM 中的 `Raw()` 也不是免死金牌：`db.Raw("SELECT * FROM " + tableName)` 和 `db.Raw("WHERE name = ?", name)` 的安全性根本不是一个级别。 最后要说一个最容易被忽视的点：参数化查询只管执行前的安全，不管执行后的数据处理。比如你用 `int` 去接收 `BIGINT` 字段，在 32 位系统上会丢高位；用 `string` 去接收可能为 `NULL` 的列，`Scan` 会直接 panic。这些问题虽然不会导致注入，但会让业务逻辑在静默中间出错，掩盖真正的风险。 > 总结一下：**参数化查询是防注入的第一道、也是最有效的一道防线**，但它的适用范围是有限度的，结构部分必须靠白名单来解决。剩下的，就是你在写代码时多留个心眼。