本文解析 Go 使用 lib/pq 驱动连接 PostgreSQL 时因误用 ? 占位符导致查询失败的根本原因，明确指出 PostgreSQL 要求使用 $1, $2 等位置参数语法，并提供完整、安全、可落地的参数化查询实践方案。
本文解析 go 使用 lib/pq 驱动连接 postgresql 时因误用 `?` 占位符导致查询失败的根本原因，明确指出 postgresql 要求使用 `$1`, `$2` 等位置参数语法，并提供完整、安全、可落地的参数化查询实践方案。
在 Go 应用中对接 PostgreSQL 数据库时，一个高频却极易被忽视的错误是：将 MySQL 或 SQLite 风格的 ? 占位符直接用于 PostgreSQL 查询语句。正如问题中所示，当开发者将原本硬编码的 WHERE id = 1 改为带参数的 WHERE id = ? 并传入 pageID 后，程序静默失败（日志仅输出 "Couldn't get page: 1"），实际却未抛出明确 SQL 错误——这是因为 lib/pq 驱动无法识别 ?，将其视为普通字符串字面量，最终生成的 SQL 等价于 WHERE id = '?'，自然查不到任何记录。
✅ 正确做法是严格遵循 PostgreSQL 的参数化语法：使用 $n 形式的位置占位符（$1, $2, …），其中 n 表示参数在 QueryRow/Exec 等方法调用中传入的顺序索引（从 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类型需与数据库字段类型兼容。若pages.id是SERIAL（即INTEGER），应确保pageID是int或int64；若来自 URL 路由（如mux.Vars(r)["id"]），它默认是string，必须显式转换：import "strconv" // ... id, err := strconv.ParseInt(pageID, 10, 64) if err != nil { http.Error(w, "Invalid ID", http.StatusBadRequest) return } err = database.QueryRow("SELECT ... WHERE id = $1", id).Scan(...) -
sql.Open()仅初始化连接池，不验证数据库连通性。务必在启动时或首次查询前调用database.Ping()进行主动健康检查：if err := database.Ping(); err != nil { log.Fatal("Failed to connect to PostgreSQL:", err) } - 始终检查
QueryRow().Scan()的返回错误，避免忽略sql.ErrNoRows（无结果）或真正的连接/语法错误。建议区分处理：if err == sql.ErrNoRows { http.Error(w, "Page not found", http.StatusNotFound) return } if err != nil { log.Printf("Database error: %v", err) http.Error(w, "Internal server error", http.StatusInternalServerError) return }
此外，还需确认驱动导入正确且连接字符串格式合规：
import (
"database/sql"
_ "github.com/lib/pq" // 注意：下划线导入，启用驱动注册
)
// 连接字符串示例（推荐使用 URL 格式）
connStr := "host=localhost port=5432 user=nirgalon dbname=cms sslmode=disable"
db, err := sql.Open("postgres", connStr)
总结：PostgreSQL 在 Go 生态中坚持标准兼容性，拒绝模糊语法。? 属于 MySQL/SQLite 语义，而 $1 才是其原生、高效、安全的参数化入口。养成「一查驱动文档、二验占位符、三做类型转换、四检所有 err」的习惯，即可彻底规避此类低级但致命的集成陷阱。
