SQL注入的核心风险在于不可信输入被当成了SQL语句的一部分执行。Go语言虽然拥有标准库database/sql以及成熟的第三方ORM，但如果开发者习惯用字符串拼接构造查询，注入漏洞依然会出现在登录、搜索、排序、导出等常见接口中。攻击者可以通过提交带有单引号、注释符或恒真条件的字符串，改变原始SQL的过滤逻辑，轻则绕过认证，重则拖取整张数据表。因此，理解Go中SQL注入的触发方式并掌握参数化查询、动态标识符校验等编码实践，是Web后端安全建设的基础环节。
SQL注入在Go应用中的典型触发点
在Go中，最容易出现注入漏洞的代码往往集中在对用户输入进行字符串拼接后执行SQL的位置。一个典型的错误示例如下，它把name参数直接放入查询语句：
func unsafeQuery(db *sql.DB, name string) error {
query := "SELECT id, email FROM users WHERE name = '" + name + "'"
rows, err := db.Query(query)
if err != nil {
return err
}
defer rows.Close()
return nil
}
如果用户传入的是正常字符串，该函数可以工作；一旦攻击者提交admin' --这样的内容，SQL语句会变成查询name等于admin，同时注释掉后续的限制条件，可能直接绕过密码校验。即便原始语句中没有密码条件，攻击者也可以使用' OR '1'='1让WHERE条件恒为真，从而返回全量数据。
数字型参数同样不能掉以轻心。有些开发者认为数字不需要引号闭合，拼接起来风险较低，但实际上攻击者可以提交1; DROP TABLE users; --，在部分数据库驱动或复合语句开启时可能造成破坏。即使不开启多语句，攻击者也可以利用1 OR 1=1改变数值比较逻辑。Go不会自动识别这些恶意片段，因此任何未经处理的输入拼接都应当视为高风险操作。
典型触发场景还包括：模糊搜索中的LIKE条件、IN子句的列表拼接、动态排序字段ORDER BY、分页参数以及后台管理系统的批量导出功能。只要这些位置使用fmt.Sprintf、+号或模板拼接SQL，都可能成为攻击入口。安全编码的第一步，就是识别所有SQL文本与用户输入发生交叠的地方，并统一替换为参数化查询。
利用database/sql参数化查询构建安全语句
Go标准库database/sql提供了统一的预处理机制，通过?等占位符把SQL结构与参数值分离。数据库驱动会先将SQL骨架发送给数据库解析，再单独绑定参数值，因此参数内容不会改变SQL语法。安全的查询写法如下：
func safeQuery(db *sql.DB, name string) ([]string, error) {
rows, err := db.Query(
"SELECT id, email FROM users WHERE name = ?",
name,
)
if err != nil {
return nil, err
}
defer rows.Close()
var emails []string
for rows.Next() {
var id int
var email string
if err := rows.Scan(&id, &email); err != nil {
return nil, err
}
emails = append(emails, email)
}
return emails, rows.Err()
}
这里的?是MySQL驱动使用的占位符。如果换成PostgreSQL，占位符通常写成$1、$2；SQL Server则可能使用@p1。database/sql会根据驱动自动转换，开发者在绝大多数情况下只需使用驱动规定的占位符即可。无论参数中是否包含单引号、分号或注释符，数据库都只会把它当作普通的值处理，不会破坏查询结构。
对于需要重复执行的语句，还可以使用Prepare预编译，减少数据库解析开销：
stmt, err := db.Prepare("SELECT id, email FROM users WHERE name = ?")
if err != nil {
return err
}
defer stmt.Close()
rows, err := stmt.Query(name)
预处理语句不仅安全，还能提升高频查询的性能。需要注意的是，参数化查询并不意味着所有SQL片段都可以用占位符代替。数据库标识符，例如表名、列名、排序方向，以及一部分关键字，本身不能作为参数绑定。对于这些场景，需要在应用层做严格的输入校验，而不能幻想把占位符当作万能方案。
另一个常见误区是LIKE模糊查询。正确做法是把通配符拼在参数值中，而不是拼SQL字符串。例如db.Query("SELECT * FROM products WHERE title LIKE ?", "%"+keyword+"%")是安全的，因为%作为参数值的一部分不会影响SQL语法结构。相比之下，使用fmt.Sprintf("SELECT * FROM products WHERE title LIKE '%%%s%%'", keyword)则完全绕过了参数化保护，需要避免。
动态表名、列名与IN子句的校验策略
当业务需要根据用户选择动态改变ORDER BY、GROUP BY或者表名时，占位符无法派上用场。数据库不可能把标识符位置上的?当作列名解析，而只会把它当作字符串或语法错误。因此，这类动态SQL必须通过白名单映射来降低风险。例如排序字段可以建立一个允许列名到实际列名的映射：
var allowedOrderColumns = map[string]string{
"id": "id",
"username": "username",
"created": "created_at",
}
func listUsers(db *sql.DB, orderBy string) error {
column, ok := allowedOrderColumns[orderBy]
if !ok {
column = "id"
}
query := "SELECT id, username, created_at FROM users ORDER BY " + column
rows, err := db.Query(query)
if err != nil {
return err
}
defer rows.Close()
return nil
}
上述代码只允许三种排序字段，非法输入会回退到默认列id。白名单的价值在于，即使攻击者提交了id; DROP TABLE users或id DESC之类的字符串，最终进入SQL的也只有映射后的固定值，不会包含攻击载荷。表名同理，应通过枚举或映射限制，绝不可直接把用户输入拼接到表名位置。
IN子句是另一个高频但容易出错的场景。假设前端传入一组用户ID，开发者需要查询这些ID对应的记录。由于参数数量不固定，不能直接写IN (?)，但也不能把ID列表直接拼接进去。正确的做法是根据ID数量动态生成占位符，然后把切片展开传给Query：
func queryByIDs(db *sql.DB, ids []int) error {
if len(ids) == 0 {
return nil
}
placeholders := make([]string, len(ids))
args := make([]interface{}, len(ids))
for i, id := range ids {
placeholders[i] = "?"
args[i] = id
}
query := "SELECT id, username FROM users WHERE id IN (" +
strings.Join(placeholders, ",") + ")"
rows, err := db.Query(query, args...)
if err != nil {
return err
}
defer rows.Close()
return nil
}
这里占位符字符串?由程序生成，数量与用户提供的ID个数一致，并且ID值通过args...参数化传入，因此不会发生注入。还需要注意IN列表过长可能会超出数据库限制或拖慢查询，通常建议在业务层限制一次查询的ID数量，超过阈值时进行分批处理。
ORM环境下的防注入细节与安全测试
很多Go项目使用GORM等ORM框架，但ORM并不能天然免疫SQL注入。GORM在链式调用Where、Find、Create等方法时，底层使用参数绑定，安全性较高；一旦使用Raw、Exec拼接字符串，危险就会重新出现。例如下面写法存在注入风险：
db.Raw("SELECT * FROM users WHERE name = '" + name + "'").Scan(&result)
而使用GORM提供的占位符形式则是安全的：
db.Raw("SELECT * FROM users WHERE name = ?", name).Scan(&result)
对于GORM中的Order、Group、Select等接受字符串参数的方法，需要特别注意。这些方法通常会把参数直接拼入SQL，而不会当作绑定值处理。因此，如果排序字段来自前端，必须执行白名单校验。例如只允许created_at、id等固定字段，并进行方向控制，避免出现created_at; DROP TABLE users这类恶意注入。
除了编码规范，安全测试同样重要。可以在单元测试中加入典型的攻击载荷，比如' OR '1'='1、admin' --、1; DROP TABLE users; --，断言查询结果不会返回异常数据。对于SQL注入扫描，也可以借助sqlmap等工具对登录、搜索、排序接口进行自动化探测。不过工具只能发现部分问题，代码审查中关注db.Query、db.Exec、Raw、fmt.Sprintf等关键词是否与用户输入直接拼接，是更可靠的人工防线。
总结来说，Golang防止SQL注入的关键在于：能参数化的地方一律使用预处理占位符；不能参数化的动态标识符必须通过白名单严格限制；ORM的原始SQL接口需要同等警惕；再配合输入校验、输出编码和自动化测试，才能构建完整的Web安全编码防线。安全不是某个函数的事情，而是贯穿每个查询语句的工程习惯。