本文详解 Go 使用 lib/pq（或 pgx）驱动连接 PostgreSQL 时，参数化查询必须使用 $1, $2 等位置占位符，而非 MySQL 风格的 ?；并给出安全传参、类型转换、错误处理等完整实践方案。
本文详解 go 使用 `lib/pq`（或 `pgx`）驱动连接 postgresql 时，参数化查询必须使用 `$1`, `$2` 等位置占位符，而非 mysql 风格的 `?`；并给出安全传参、类型转换、错误处理等完整实践方案。
在 Go 中通过 database/sql 操作 PostgreSQL 时，一个常见误区是直接套用 MySQL 或 SQLite 的参数占位符习惯（如 ? 或 :name），导致查询静默失败或报错。根本原因在于：PostgreSQL 原生协议仅支持 $n 形式的位置参数，而 Go 的 lib/pq（已归档）和现代主流驱动 pgx 均严格遵循该协议，不解析 ? —— 它既不会报语法错误，也不会绑定参数，而是将 ? 视为普通字符，最终导致查询逻辑失效（如 WHERE id = ? 实际匹配字符串 "?"）。
✅ 正确写法如下（以 lib/pq 为例）：
pageID := vars["id"] // 注意：此处 pageID 是 string 类型
var thisPage Page
// ✅ 使用 $1 占位符，且参数按顺序传入
err := database.QueryRow(
"SELECT page_title, page_content, page_date FROM pages WHERE id = $1",
pageID,
).Scan(&thisPage.Title, &thisPage.Content, &thisPage.Date)
⚠️ 但需特别注意：pageID 若来自 URL 路径（如 mux.Vars(r)["id"]），其类型为 string，而数据库 id 字段通常为 INTEGER 或 BIGINT。直接传入字符串会导致类型不匹配，PostgreSQL 可能拒绝隐式转换（尤其当字段为 SERIAL 或有约束时）。强烈建议在 Go 层完成类型校验与转换：
pageIDStr := vars["id"]
pageID, err := strconv.ParseInt(pageIDStr, 10, 64)
if err != nil {
http.Error(w, "Invalid page ID", http.StatusBadRequest)
return
}
err = database.QueryRow(
"SELECT page_title, page_content, page_date FROM pages WHERE id = $1",
pageID, // 传入 int64，驱动自动映射为 PostgreSQL INTEGER/BIGINT
).Scan(&thisPage.Title, &thisPage.Content, &thisPage.Date)
? 补充关键实践要点：
-
绝不拼接 SQL 字符串：避免
fmt.Sprintf("... id = %s", pageIDStr)—— 这不仅易引发 SQL 注入，还破坏查询计划缓存； -
统一使用命名结构体字段：如
page_date对应 Go 字段Date，建议数据库列名使用snake_case，Go 结构体用CamelCase，并通过Scan显式映射，提升可维护性； -
错误处理要区分场景：
QueryRow().Scan()返回sql.ErrNoRows表示未找到记录（应返回 404），而非致命错误；其他err != nil才需log.Fatal或返回 500； -
驱动升级提示：
lib/pq已于 2023 年归档，生产环境推荐迁移到github.com/jackc/pgx/v5，其对上下文取消、批量操作、类型强转支持更完善，且仍使用$1占位符，兼容现有语法。
总结：PostgreSQL 的 $1 占位符不是风格选择，而是协议强制要求。正确使用它，配合 Go 层类型预处理与严谨错误分支，才能写出安全、健壮、符合 PostgreSQL 生态规范的数据库交互代码。
