golangci-lint 是当前唯一能真正落地 golang 开发规范的工具，它通过调度 revive、staticcheck、govet 等多个 linter 统一管控启用项、严重等级与退出码；单用 go vet 或 staticcheck 无法覆盖命名风格、导出注释、接口后缀等规范类检查。
golangci-lint 是当前唯一能真正落地 Golang 开发规范的工具——它不自己检查，而是调度 revive、staticcheck、govet 等多个 linter，统一控制启用项、严重等级和退出码。单用 go vet 或 staticcheck 都无法覆盖命名风格、导出注释、接口后缀等规范类问题。
为什么不能只靠 go vet ./
go vet 专注语义正确性，不处理风格：它不会报函数名用了下划线、导出变量没写注释、接口没以 er 结尾。它能发现 fmt.Printf("%d", "hello") 这类运行时错，但对 GetUserByID 写成 get_user_by_id 完全沉默。
常见误操作：
- 在 CI 中只跑
go vet ./，结果团队命名五花八门，PR 里全是风格争议 - 手动加
-printf、-shadow等子检查，却漏掉unmarshal——导致json.Unmarshal(b, &v)里v类型不匹配也无警告 - 用
go vet main.go单文件模式，跨包调用、类型定义看不到，大量问题漏检
必须配 .golangci.yml 才算启用规范检查
文件名、位置、缩进三者错一个，配置就等于没写：
- 文件名必须是
.golangci.yml（不是.golangci.yaml，也不是golangci.yml） - 必须放在
go.mod所在目录（monorepo 中每个 module 都要单独放一份） - 缩进只能用空格；
linters-settings和run是顶层字段，不是linters的子项
关键配置段示例（启用规范类检查）：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
linters-settings:
revive:
severity: error
rules:
- name: exported
severity: error
- name: var-naming
severity: warning
- name: interface-name
severity: error
注意：exported 设为 error 才会阻断 CI；var-naming 先设 warning 观察，避免因历史代码太多直接卡死流水线。
哪些 linter 必须显式开启才有效
默认只开约 10 个基础 linter（如 govet、errcheck），真正管规范和深度质量的都关着：
-
revive：替代已归档的golint，检查命名、注释、接口后缀——必须在linters.enable里显式加进去 -
staticcheck：报SA1019（弃用 API）、SA1021（空循环）、nil 解引用风险——默认关闭，不加就等于没用 -
unused：发现未使用的变量、函数、import——哪怕写了var _ = fmt.Println也不警告，除非启用 -
goconst：识别重复字符串（HTTP 状态码、SQL 模板），业务逻辑密集项目尤其关键
别用 --enable-all：会拉起 50+ linter，其中不少已废弃或对中文注释/泛型误报严重（如旧版 lll）。
CI 失败但本地正常？先查这三处硬性差异
环境不一致比代码问题更常卡住流水线：
-
GO111MODULE：CI 默认可能为off，导致go list -deps解析失败，报packa...截断错误 -
GOPATH和GOPROXY：本地可能走私有 proxy，CI 走官方，某些 linter 依赖的包版本不一致 - IDE 缓存：GoLand / VS Code 可能缓存旧配置，改完
.golangci.yml后需重启或手动触发 “Reload golangci-lint config”
最易被忽略的是 govet 子检查未生效：写了 json.Unmarshal(b, &v) 却没警告？说明 .golangci.yml 里缺 linters-settings.govet.checks，得明确写 ["printf", "shadow", "unmarshal", "atomic"]，不能只靠默认白名单。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
