goland 不具备深度语义检测能力，冗余导入和未使用变量依赖 go vet、gopls 等工具及手动开启的三项检查：unused import、unused symbol、unreachable code；真正判定冗余需结合 go mod tidy 和全场景构建测试验证。
GoLand 本身不提供“冗余导入包”或“未使用变量”的深度语义级检测能力，它依赖的是 Go 工具链（如 go vet、gopls）和内置的轻量级静态分析。真正能发现 import 冗余、未调用函数、死代码的，是开启对应检查项后的实时高亮+快速修复，不是靠菜单点一下就出报告。
为什么 GoLand 的“冗余 import”提示有时不准
GoLand 默认启用的 Unused import 检查，只扫描当前文件的 import 语句是否被该文件内代码引用。它不会：
- 识别
import _ "github.com/lib/pq"这类空白导入是否仍有init()副作用（比如注册 SQL 驱动） - 感知
//go:build integration下的条件导入——若当前构建标签未启用，它会标红，但删掉后可能测试失败 - 跟踪测试文件（
_test.go）里的引用：你删了main.go的 import，但handler_test.go还用着，GoLand 不会跨文件联动判断该 import 是否真冗余
必须手动开启的三项关键检查
默认这些是关闭的，需进设置手动打开：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
-
Settings → Editor → Inspections → Go → Unused import：勾选并设为
Warning级别，实时标灰未使用的import行 -
Settings → Editor → Inspections → Go → Unused symbol：检测未被调用的函数、方法、变量（注意：不覆盖导出符号，
func Foo()即使没调用也不会报） -
Settings → Editor → Inspections → Go → Unreachable code：标出
return后的代码、if false { ... }这类确定执行不到的逻辑
配合 go mod tidy 才算闭环
GoLand 提示的“未使用 import”，只是文件级线索；真正决定模块是否该从 go.mod 中移除的，是 go mod tidy 的结果。操作顺序必须是：
- 先在 GoLand 里按
Alt + Enter快速删掉标灰的import行（它会同步删go.mod里的require吗？不会） - 删完所有标灰项后，在终端执行
go mod tidy -v，观察输出中是否有removing unused - 若某模块在 GoLand 里没标灰（比如被
_test.go引用），但tidy没删它——说明它仍被测试依赖，不能动
容易忽略的陷阱：测试文件和构建标签
最常踩的坑是清理完主逻辑，忘了跑测试就提交：
-
go test ./必须通过，否则go mod tidy可能保留了测试专用模块（如github.com/stretchr/testify），而 GoLand 的检查默认不扫描测试文件 - 若项目有
//go:build e2e或//go:build !windows，需在 GoLand 的Run Configurations里为测试配置对应Build tags，否则检查会漏掉条件引入的包 - GoLand 的
Unused symbol对init()函数永远静默——哪怕你删了所有调用它的代码，只要文件里还有func init() { ... }，它就不会提示
真正的冗余不是看编辑器标不标灰，而是看 go mod why -m xxx 返回 main module does not need module，且 go test -tags=integration ./ 和 go build -o app ./ 全部通过。其他都是中间线索。
