goland不支持一键清理未使用变量和常量，仅高亮提示，因go编译器不检查局部变量/私有常量是否未用，ide遵循相同保守策略；需用staticcheck等工具扫描，并人工核验反射、标签、go:generate等隐式引用，再通过go build -gcflags="-l -n"和go tool nm验证符号清除。
GoLand 不支持一键清理未使用的变量和常量——它能高亮、提示、重构，但不会自动删除，尤其对局部变量、包级私有常量（const debug = true）或被字符串引用的标识符，IDE 默认保持沉默。
为什么 GoLand 不删未用变量和常量
Go 编译器本身不报未使用局部变量错误（仅对函数参数、返回值、包级变量/常量做检查），而 GoLand 遵循相同语义：它只标记那些编译器会拒绝的冗余项（如 var x int 声明后完全未读写），对“声明了但没显式使用”的常量、闭包捕获变量、反射目标名等，一律不干预。
-
const MaxRetries = 3即使全项目没出现MaxRetries字符串，也不会被标红——除非它被赋值给一个未用变量或参与未用计算 - 函数内
err := doSomething()后没处理err，GoLand 可能标黄（Warning），但不会删这行——因为err可能被defer func() { log.Println(err) }()捕获 - 包级
var _ = initHelper()这种副作用初始化，会被识别为“已使用”，即使initHelper函数本身未被其他地方调用
用 go vet + staticcheck 扫描真实未用符号
GoLand 的静态分析覆盖有限，真正可靠的检测得靠命令行工具。重点不是“有没有用”，而是“能不能被编译器证明不可达”：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 运行
go vet -v ./...：它会报告unusedwrite（写入但未读取）、lostcancel等，但对常量无感 - 安装
staticcheck：go install honnef.co/go/tools/cmd/staticcheck@latest - 执行
staticcheck -checks='SA9003' ./...：专门检测未使用的常量、变量、类型别名（SA9003是“unused symbol”检查） - 注意：
staticcheck会把var _ io.Closer = &MyStruct{}当作“已使用”，但若只是const _ = "debug"，它会标出——这类才是安全可删的
删之前必须人工核对的三类隐式引用
工具扫出来的“未用”，不等于“可删”。以下情况删了就 panic 或静默错位：
- 被
runtime.FuncForPC或日志上下文硬编码：比如log.Printf("in %s", "handleRequest")，而handleRequest是个未调用函数名 - 作为结构体字段标签值：
type User struct { Name string `json:"name"` }——"name"是字符串字面量，不是变量，但若你定义了const NameTag = "name"并用于此，删它就破 JSON 序列化 - 在
//go:generate注释里被引用：比如//go:generate stringer -type=State，而State是个未用常量定义的枚举类型
删完必须验证的两个动作
删掉一个 const 或 var 后，别只信 IDE 的绿色对勾：
- 跑
go build -gcflags="-l -N" ./...：关优化、关内联，强制暴露所有符号；再用go tool nm ./mybinary | grep MyConstName，确认符号真没了（避免 DCE 没生效却以为清干净了） - 执行
go test -tags=integration ./...（或你项目实际用的构建 tag）：很多常量只在特定 tag 下才参与逻辑，主流程测试根本测不到
真正容易被忽略的是包级常量参与的编译期条件判断——比如 const debug = false 被 //go:build debug 文件引用，删它会导致构建失败，而工具扫描时根本看不到这种跨文件、跨构建约束的依赖。
