本文详解如何在 go + martini + postgresql 应用中，将 http 路由中的 uri 参数（如 `/post/1` 中的 `1`）安全、正确地传入 sql 查询，避免字符串拼接漏洞，并解决常见作用域与占位符误用问题。
在 Web 开发中，将 URI 路径段（如 /post/1 中的 1）映射为数据库查询条件是高频需求。但初学者常误将参数直接嵌入 SQL 字符串（如 WHERE id = params["idnumber"]），这不仅导致语法错误（params 未定义），更会引发严重 SQL 注入风险，且无法通过类型校验。
核心原则：永远使用参数化查询（Prepared Statement），禁止字符串拼接 SQL。
Martini 框架通过路由参数（如 :idnumber）将值注入处理函数的参数列表，但需显式声明接收——Martini 不自动注入 params 对象，而是支持通过函数签名按名称或类型绑定。因此，正确的做法是：在处理器函数中声明 idnumber string（或 int64）参数，Martini 会自动解析并注入该路由段的值。
以下是修复后的完整示例代码（关键修改已加注释）：
package main
import (
"fmt"
"net/http"
"strconv"
"github.com/go-martini/martini"
"database/sql"
_ "github.com/lib/pq"
)
func SetupDB() *sql.DB {
db, err := sql.Open("postgres", "user=postgres password=apassword dbname=lesson4 sslmode=disable")
PanicIf(err)
return db
}
func PanicIf(err error) {
if err != nil {
panic(err)
}
}
func main() {
m := martini.Classic()
m.Map(SetupDB())
// ✅ 正确：声明 idnumber string 参数，Martini 自动注入路由值
m.Get("/post/:idnumber", func(rw http.ResponseWriter, r *http.Request, db *sql.DB, idnumber string) {
// ✅ 正确：使用 $1 占位符 + 参数化查询，防止 SQL 注入
// ❌ 错误：db.Query(`... id = params["idnumber"]`) —— params 未定义，且是字符串字面量
rows, err := db.Query(
"SELECT title, author, description FROM books WHERE id = $1",
idnumber, // 参数自动转换为 int4（PostgreSQL 支持字符串→整数隐式转换）
)
PanicIf(err)
defer rows.Close()
// 检查是否有匹配记录
if !rows.Next() {
http.Error(rw, "Post not found", http.StatusNotFound)
return
}
var title, author, description string
err = rows.Scan(&title, &author, &description)
PanicIf(err)
fmt.Fprintf(rw, "Title: %s\nAuthor: %s\nDescription: %s\n", title, author, description)
})
m.Run()
}关键要点说明：
- 参数绑定机制：Martini 依据函数参数名（idnumber string）自动匹配路由中 :idnumber 的值，无需访问 params 字典；
- SQL 安全性：$1 是 PostgreSQL 的占位符语法，database/sql 驱动会将 idnumber 作为独立参数传递给数据库，彻底隔离数据与 SQL 结构；
-
类型兼容性：虽然 idnumber 是 string 类型，但 PostgreSQL 的 int4 列可接受字符串形式的数字（如 "1"），驱动会自动处理转换；若需更强类型保障，可提前转换：
id, err := strconv.ParseInt(idnumber, 10, 64) PanicIf(err) rows, err := db.Query("SELECT ... WHERE id = $1", id) - 健壮性增强：添加 rows.Next() 检查确保至少有一行结果，避免空查询返回静默成功；
- 错误处理建议：生产环境应使用结构化日志替代 PanicIf，并对 rows.Scan 错误做细粒度判断（如 sql.ErrNoRows）。
总结：URI 参数到 SQL 查询的桥梁，不是字符串拼接，而是框架参数绑定 + 数据库驱动参数化查询。遵循此模式，既能保证功能正确性，又能筑牢安全底线。
