必须修改.golangci.yml配置文件：通过disable字段禁用整个linter（如unused），或在linters-settings中针对revive等工具禁用具体规则（如exported）；goland仅展示结果，不控制检查逻辑，改ide的severity滑块无效。
GoLand 里 golangci-lint 检查太严，怎么关掉部分规则？
GoLand 默认不直接控制检查“级别”，它只是把 golangci-lint 的输出展示出来。所谓“调低级别”，本质是改 .golangci.yml 配置，让某些 linter 或具体规则不生效。
常见误操作：在 GoLand 设置里调“Severity”滑块——那只是改 IDE 对已有警告的显示颜色或是否弹窗，不影响实际检查结果，也不影响 CI。
- 真正起作用的是
.golangci.yml中的disable和linters-settings部分 - 比如想跳过所有未使用变量警告，加一行：
disable: ["unused"] - 若只想关掉某条规则（如 revive 的 exported 检查），写成：
linters-settings: revive: rules: [{name: "exported", disabled: true}] - 别碰
run.skip-dirs来“绕过检查”——那是排除目录，不是降低强度
为什么改了配置，GoLand 还在报旧错误？
GoLand 的 Go 插件默认会缓存上次运行的 golangci-lint 结果，且不会自动监听 .golangci.yml 变更。
- 必须手动触发重载：右键项目 → Reload project，或执行
File → Reload project from disk - 确认插件用了你刚改的配置：设置里搜
go.lintTool，确保路径指向项目根目录下的.golangci.yml（不是全局默认） - 如果用的是
golangci-lint run命令行，也要加--config=.golangci.yml，否则它可能读不到你改的版本 - 重启 GoLand 有时比 reload 更可靠，尤其当你改了
disable后仍看到已禁用的 linter 报错
哪些规则最常被团队主动关掉？
不是所有警告都值得修复，尤其在迁移期或 legacy 代码里。以下几类规则关闭前需评估，但实践中确实高频豁免：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
-
lll（行长限制）：纯风格偏好，golangci-lint默认就不启用，开了也建议关掉 -
stylecheck中的命名规则（如ST1017）：对测试文件、mock、生成代码可整体禁用 -
revive的exported规则：内部工具包或 protoc 生成代码里常有未导出但需保留的符号 -
goconst：字符串重复检测误报率高，且和业务逻辑强相关，不如人工判断
注意：errcheck、staticcheck、govet 这三个别关——它们报的大多是 runtime panic 或资源泄漏风险，不是“风格问题”。
CI 和本地不一致？大概率是配置没对齐
GoLand 里看着“调低了”，但 CI 还在红，往往因为两件事没做：
- CI 脚本里没显式传
--config=.golangci.yml，导致它用默认配置（只开govet和errcheck） -
.golangci.yml放错位置：必须和go.mod在同一级目录；放在src/或config/下无效 - 多 module 项目（monorepo）中，每个子 module 都要单独放一份
.golangci.yml，GoLand 只读当前打开 module 的那份
最稳妥做法：每次改完配置，都在终端跑一遍 golangci-lint run --config=.golangci.yml --out-format=tab，看输出是否和 GoLand 里一致——不一致就说明 IDE 没加载对。
