go vet + staticcheck 够用但需适配 gin 语义：go vet 查基础误用，staticcheck 识别 sa1025 等 gin 相关隐患，但须手动启用 sa 规则、禁用误报项（如 sa1017），并补充 grep 脚本检查 c.param 未校验、中间件漏调 c.next() 等框架特有问题。
Go 项目本身没有像前端 ESLint 那样的“框架专属静态检测器”，Gin 框架代码的静态质量检测，本质就是 Go 代码的静态质量检测——但要特别关注 Gin 特有模式带来的隐患，比如未处理 panic、中间件漏传、Context 提前释放、路由参数未校验、错误未返回等。
为什么 go vet + staticcheck 就够用，但必须配 Gin 语义规则
Go 自带的 go vet 能发现空指针解引用、无用变量、结构体字段标签错误等基础问题；staticcheck（推荐作为默认补充）能识别更深层问题，如 defer 在循环中错用、http.Error 后继续写响应体、gin.Context 方法调用顺序违规（比如 c.Abort() 后还调 c.JSON()）。但这些工具默认不理解 Gin 的生命周期契约——例如它不会警告你“在中间件里忘了调 c.Next() 导致后续 handler 不执行”，也不会检查 c.Bind() 失败后是否做了错误处理。
所以你需要：
- 启用
staticcheck的SA1019（已弃用 API）、SA1025（time.Now().Unix()应该用.UnixMilli()）等通用规则 - 手动添加对 Gin 模式敏感的检查项（见下一条）
- 避免误报：禁用
SA1017（HTTP handler 中没读 request body）——Gin 的c.ShouldBind()已隐式读取，不用额外ioutil.ReadAll
常见 Gin 代码质量问题与对应检测方式
以下问题无法靠编译器捕获，但会在运行时导致 500、静默失败或安全漏洞，必须靠静态检查提前拦截：
-
c.JSON(200, data)后继续调c.String()或c.Redirect()→ 触发staticcheck的SA1025（multiple response writes） - 使用
c.Param("id")但没校验是否为空或是否为合法数字 → 需自定义检查：grep 扫描c.Param(后是否紧跟if len(...)==0或strconv.Atoi调用 - 中间件函数签名正确但体内没调
c.Next()→ 无现成工具检测，需在 CI 中加 shell 脚本：grep -r "func.*\*gin.Context" --include="*.go" . | grep -v "c.Next()" | grep -v "//" -
router.GET("/user/:id", handler)中handler函数没接收c *gin.Context参数 → 编译直接报错，无需额外检测
如何在 CI 中低成本落地 Gin 静态检查
不必引入复杂插件或定制 AST 分析器。在 GitHub Actions 或 Jenkins 的构建步骤中插入三行命令即可覆盖 80% 风险点：
go vet ./...
staticcheck -checks=all,unparam ./...
grep -r "c\.Param(" --include="*.go" . | grep -v "if.*len.*== 0\|strconv\." && echo "⚠️ found unchecked c.Param usage" && exit 1 || true
注意：staticcheck 默认不检查测试文件，如需覆盖，显式加上 ./... ./test/...；unparam 可发现 Gin handler 中未使用的 *gin.Context 参数，这类函数往往逻辑残缺。
真正容易被忽略的是 Context 生命周期边界
所有 Gin handler 和中间件都运行在同一个 *gin.Context 实例上，而它的值是复用的。你在 goroutine 里直接传 c 并异步调用 c.JSON() 是危险的——主线程可能早已返回、c 内部缓冲区已被回收。这种问题既不会被 staticcheck 抓到，也不会 panic，只会偶发乱码或空响应。唯一可靠办法是：异步操作前用 c.Copy() 显式复制上下文，且只在 copy 后调用写响应方法。这个约束无法静态证明，只能靠团队规范 + code review 卡点。
