golangci-lint报错SQL rows未关闭：goroutine关闭合规性及忽略方法

1. 这种在goroutine中关闭rows的模式是否属于不良实践？ #

是的，这种模式存在明显风险，属于不推荐的实践，核心原因包括：

• 连接泄漏风险：你已经发现，如果在启动goroutine前出现错误，rows的Close()永远不会被调用，必须在错误分支显式判断并关闭rows（注意要先判断rows是否非nil，避免nil指针panic）。
• 并发安全问题：sql.Rows并非并发安全类型，若主goroutine未完全移交控制权就启动子goroutine，或两者同时操作rows，可能引发不可预期的异常。
• 连接池占用问题：子goroutine的生命周期不受主goroutine控制，一旦子goroutine因阻塞、panic等异常无法执行defer rows.Close()，会导致数据库连接长时间被占用，耗尽连接池资源。

更稳妥的做法是尽量在同一个goroutine内完成rows的遍历与关闭；如果必须用goroutine处理，建议先在主goroutine中读取完所有数据，再将数据传递给子goroutine，而非直接传递sql.Rows指针。

2. 这是golangci-lint的误报吗？ #

不算完全意义上的误报，这是工具的检测局限性导致的：
sqlclosecheck规则的核心逻辑是追踪当前代码路径中是否存在rows.Close()调用，它无法跨goroutine识别后续的defer关闭操作。从工具的检测视角来看，当前goroutine没有关闭rows，所以触发报错。但这个报错也间接提醒了你这种模式存在的潜在风险。

3. 如何让golangci-lint忽略该报错？ #

如果暂时无法重构代码，有两种方式可以忽略该报错：

• 单行忽略：在创建rows的代码行末尾添加注释，指定忽略sqlclosecheck规则：

  rows, err := ... //nolint:sqlclosecheck
  

• 局部配置忽略：在项目的.golangci.yml配置文件中，针对sqlclosecheck规则添加特定例外（不推荐全局关闭，建议仅针对目标文件或函数）：

  linters-settings:
    sqlclosecheck:
      exclude-functions:
        - "yourPackage.funcThatDoesSomethingWithRows"
  

补充：错误分支的正确处理方式 #

针对你补充的代码，错误分支必须显式处理rows的关闭，示例如下：

rows, err := db.QueryContext(ctx, "SELECT ...")
if err != nil {
    // 先判断rows是否非nil，避免nil指针panic
    if rows != nil {
        _ = rows.Close()
    }
    return fmt.Errorf("query failed: %w", err)
}
go funcThatDoesSomethingWithRows(rows)

内容的提问来源于stack exchange，提问作者Gilo