go 中使用 database/sql 查询 mysql 时，若在获取 *sql.rows 后立即关闭数据库连接，会导致后续 rows.next() 和 rows.scan() 失败并静默填充零值，最终得到全空结构体切片。根本原因是 defer con.close() 在函数返回时触发，使 rows 失去底层连接支持。
问题核心在于 getRowsFromSql 函数中 数据库连接的生命周期管理错误。该函数内部调用 sql.Open 创建连接，随后用 defer con.Close() 声明延迟关闭——但 defer 语句会在函数返回前执行，即 getRowsFromSql 返回 *sql.Rows 的瞬间，连接已被关闭。而 *sql.Rows 并非数据快照，它依赖活跃连接来逐行读取结果；一旦连接关闭，rows.Next() 将始终返回 false（或不可靠行为），且 rows.Scan() 不会报错，而是将所有字段设为零值（如 0、空字符串），最终导致 []Party 中每个元素字段均为零值，JSON 序列化后表现为 [{"Id":0,"Name":"","Author":"",...}] —— 看似有长度，实则为空。
✅ 正确做法是：*将连接（sql.DB）作为长期资源持有，而非每次查询新建*。`sql.DB` 是并发安全、自带连接池的句柄，应全局初始化一次，在应用生命周期内复用：
// 全局声明（推荐放在 init 或 main 中）
var db *sql.DB
func initDB() {
var err error
db, err = sql.Open("mysql", dbConnectString)
if err != nil {
log.Fatal("Failed to open database:", err)
}
// 可选：设置连接池参数
db.SetMaxOpenConns(25)
db.SetMaxIdleConns(25)
db.SetConnMaxLifetime(5 * time.Minute)
// 验证连接有效性
if err = db.Ping(); err != nil {
log.Fatal("Failed to ping database:", err)
}
}然后重写业务函数，直接使用全局 db：
func getParties(w http.ResponseWriter, r *http.Request) {
rows, err := db.Query("SELECT id, name, author, datetime, datetime_to, host, location, description, longitude, latitude, primary_image_id FROM parties")
if err != nil {
http.Error(w, "Database query failed", http.StatusInternalServerError)
log.Printf("Query error: %v", err)
return
}
defer rows.Close() // ✅ 正确：defer 在 getParties 结束时关闭 rows
parties := scanForParties(rows)
jsonBytes, err := json.Marshal(parties)
if err != nil {
http.Error(w, "JSON marshal failed", http.StatusInternalServerError)
return
}
w.Header().Set("Content-Type", "application/json")
w.Write(jsonBytes)
}
func scanForParties(rows *sql.Rows) []Party {
var parties []Party
for rows.Next() {
var p Party
// 注意：字段顺序 & 类型必须严格匹配 SELECT 列和表结构！
// 特别注意：表中字段名为 'longitude'/'latitude'，而非 'longtitude'/'latitude'（原代码拼写错误！）
err := rows.Scan(
&p.Id,
&p.Name,
&p.Author,
&p.Datetime,
&p.Datetime_to,
&p.Host,
&p.Location,
&p.Description,
&p.Longtitude, // ⚠️ 但表字段实际是 'longitude' → 必须修正映射！
&p.Latitude, // ⚠️ 同理，表字段是 'latitude'
&p.PrimaryImgId,
)
if err != nil {
log.Printf("Scan error: %v", err)
continue // 跳过有问题的行，避免中断整个查询
}
parties = append(parties, p)
}
// 检查 rows.Err() 以捕获迭代过程中的错误（如类型不匹配、NULL 扫描到非 sql.Null* 类型）
if err := rows.Err(); err != nil {
log.Printf("Rows iteration error: %v", err)
}
return parties
}⚠️ 关键修复点总结：
- 连接生命周期：弃用每次查询新建连接，改用全局复用 *sql.DB；
- defer 位置：rows.Close() 必须在使用完 rows 后 defer（如在 handler 末尾），而非在获取 rows 的辅助函数中；
- 字段名一致性：MySQL 表字段为 longitude/latitude，但 Go 结构体字段 Longtitude 拼写错误（多了一个 t），且 rows.Scan 严格按 SQL 查询列顺序绑定，必须确保列名与变量顺序、类型完全一致；
- 强制错误检查：所有 rows.Scan()、db.Query()、json.Marshal() 调用均需检查 err，Go 不抛异常，忽略错误是多数“静默失败”的根源；
- 结构体字段导出：确保 Party 字段首字母大写（已满足），否则 JSON 序列化会忽略私有字段。
最后提醒：在 App Engine 环境中，还需确认 dbConnectString 符合 Cloud SQL 连接规范（如 Unix socket 路径或公共 IP + SSL），并正确配置服务账号权限。
