golangci-lint不读取环境变量覆盖配置，仅支持命令行--config显式指定或当前目录.golangci.yml（唯一默认识别名），无配置时回落极简默认集（仅govet、errcheck）；所谓“环境变量生效”实为命令行参数、Go构建环境（如GO111MODULE、GOPROXY）或IDE封装导致的误判。
golangci-lint 本身不读取环境变量来覆盖配置文件内容——它没有类似 Viper 那样的“环境变量 > 配置文件”优先级链。你看到的“环境变量生效”，基本都是误判，真正起作用的是命令行参数或 CI 环境中对 golangci-lint run 的调用方式。
为什么你以为环境变量在起作用？
常见错觉来源：
- 你在 shell 中 export 了
GOLANGCI_LINT_CONFIG或GOLANGCI_LINT_TIMEOUT——但这些变量 golangci-lint 官方根本不识别，属于无效设置 - CI 脚本里用了
export GO111MODULE=off，导致依赖解析失败，进而让staticcheck缺少类型信息、漏报或误报（比如 SA1019），你以为是“配置没生效”，其实是 Go 环境不一致 - IDE（如 VS Code）把
go.lintFlags里写的--config=.golangci.yml当成“环境配置”，其实这只是编辑器传给命令行的参数，不是环境变量驱动的逻辑
真正影响配置加载的只有三件事
golangci-lint 加载配置时，只认以下路径和方式，且顺序固定：
- 命令行显式指定：
--config=.golangci.yml（最高优先级，强制使用该文件） - 当前目录下存在的
.golangci.yml（唯一被默认识别的文件名；.golangci.yaml等其他后缀仅在 v1.50+ 后支持，但需明确传参启用） - 无任何配置文件时，回落到硬编码的极简默认集（仅
govet和errcheck）
它 不会 查 $HOME/.golangci.yml，不会 读 GOPATH 下的配置，不会 解析任何环境变量来拼接或覆盖 YAML 字段。
哪些地方容易被当成“环境变量优先”？
实际是命令行参数或工具链行为干扰：
-
golangci-lint run --timeout=30s：这个--timeout是命令行参数，它会覆盖.golangci.yml里的run.timeout——不是环境变量，但效果类似 - Docker 运行时加了
-e GOPROXY=https://goproxy.cn：这是为了让golangci-lint内部调用go list能正常下载模块，属于构建依赖环境，和 lint 规则配置无关 - CI 中
GOOS=linux golangci-lint run：GOOS影响的是 go toolchain 行为（比如go list -f输出），间接改变 linter 可见的符号表，不是直接改配置
想动态切换规则？别靠环境变量，用这三种办法
如果真需要不同环境启用不同 linter（如 dev 开全、CI 关掉耗时 linter），推荐：
- 维护多份配置文件：
.golangci.dev.yml和.golangci.ci.yml，CI 脚本里明确写golangci-lint run --config=.golangci.ci.yml - 用
linters.enable-all: true+linters.disable列表按需关闭，把开关逻辑写死在 YAML 里（更可审计） - CI 中用 shell 变量生成临时配置：
echo "linters: {enable: [$LINTERS]}" > .tmp.yml && golangci-lint run --config=.tmp.yml，但注意 YAML 缩进必须全空格
最常被忽略的一点：golangci-lint 的配置加载是静态的，启动那一刻就锁定了全部规则；所谓“环境变量生效”，几乎全是命令行参数、Go 构建环境或 IDE 封装层带来的副作用。盯住 --config 和 go env，比折腾不存在的环境变量前缀靠谱得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
