golangci-lint本身不检测内存泄漏，仅通过显式启用staticcheck（如SA1021、SA1016）、govet（lostcancel、httpresponse）和gosec等linter间接识别资源泄漏风险，需在.golangci.yml中精确配置并提交至Git以保障CI与IDE一致。
golangci-lint 本身不检测内存泄漏
它不是内存分析工具，不会扫描 goroutine 泄漏、os.File 未关闭、或 http.Client 长连接堆积等问题。你看到的“内存泄漏警告”大概率是误判——比如 staticcheck 报的 SA1021（循环中滥用 time.After）本质是 goroutine 泄漏风险，不是堆内存泄漏；而 go vet 的 lostcancel 检查的是 context.WithCancel 未被 defer cancel，也属于资源生命周期失控。
真正能暴露内存隐患的 linter 组合
必须显式启用并调优以下 linter，否则默认配置下它们多数是禁用的：
-
staticcheck：启用后可捕获SA1019（调用弃用 API，如旧版http.Transport配置易致连接泄漏）、SA1021（time.After在循环中创建无限 goroutine）、SA1016（未检查io.Read返回值，可能跳过io.EOF导致连接不关闭） -
govet：需开启lostcancel和httpresponse子检查项，后者会标记未调用resp.Body.Close()的 HTTP 请求 -
gosec：检测硬编码 token、不安全的net/http配置（如http.DefaultClient复用不当引发连接池耗尽）
在 .golangci.yml 中要这样写：
linters-settings:
govet:
enable-all: true
disable:
- fieldalignment
staticcheck:
checks: ["all"]
linters:
enable:
- govet
- staticcheck
- gosec
为什么 .golangci.yml 必须提交到 Git？
CI 流水线和本地 GoLand 必须用同一份配置，否则会出现“IDE 里没报错，CI 却失败”的脱节。常见坑点：
- 路径写错：
golangci-lint二进制路径在 GoLand 设置里必须填绝对路径（如/home/you/go/bin/golangci-lint），不能依赖$PATH - staticcheck 被默认禁用：即使你启用了它，若没在
linters-settings.staticcheck.checks里设["all"]或明确列出SA1021，它就完全不运行 - 忽略测试文件：
run.tests: true必须打开，否则TestMain里漏掉defer db.Close()这类泄漏点会被跳过
静态检查只是第一道防线
真正的内存泄漏往往发生在运行时——比如 channel 缓冲区积压、sync.Map 无限制增长、或 context 超时未传播。golangci-lint 再怎么配，也替代不了 pprof 堆快照比对、runtime.ReadMemStats 监控、以及 go tool trace 分析 goroutine 状态。别把静态检查当银弹，尤其当服务 RSS 内存持续上涨却找不到代码线索时，优先看运行时指标而非 lint 结果。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
