不能。goland的find usages仅检测显式符号引用，无法识别init()调用、包级变量初始化、反射、接口隐式实现等动态调用链，也不做前向可达性分析，故不能替代deadcode等专用死代码检测工具。
GoLand 自带的 Find Usages 能不能当死代码检测器？
不能。它只查符号是否被显式引用，对未导出函数、接口实现、反射调用、包级变量初始化等场景完全无感——比如 var _ = helper() 或 func init() { log.Println("start"); helper() }，Find Usages 会漏掉这些调用链起点。
它也不分析控制流可达性，更不会告诉你 goodbye() 在整个调用图里根本没被任何路径激活。它的定位是“跳转与重构辅助”，不是“语义级死代码扫描”。
- 适合：快速定位某个导出函数在哪被调用过
- 不适合：判断
cleanupTempFiles是否真没人用 - 风险：依赖它删函数，可能误删
init()里调用的私有函数，导致程序启动失败
为什么 GoLand 不集成 deadcode 工具？
因为 deadcode 是命令行静态分析工具，依赖完整模块构建上下文和 import 图解析，IDE 原生不提供这类深度调用图遍历能力。GoLand 的代码检查引擎（如 inspections）聚焦于语法、类型、风格问题，不模拟执行入口（main、测试函数）做前向可达性推导。
你可以在 GoLand 里手动运行 deadcode，但 IDE 不会自动触发、高亮或联动修复——它不会像“未使用导入”那样标红并提示“Remove unused import”。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 必须自己安装：
go install github.com/tsenart/deadcode@latest - 必须自己执行：
deadcode ./或deadcode ./pkg - 输出结果需人工比对：如
pkg/util.go:12:6:unused func cleanupTempFiles
在 GoLand 里怎么高效配合 deadcode 使用？
把 deadcode 当作外部工具接入，而不是等待 IDE 自动提醒。关键在于减少上下文切换和误操作风险。
- 在 Terminal 面板直接运行：
deadcode -whylive=example.com/pkg.helper ./查看为什么某个函数被判定为“活”的，避免误删 - 右键项目根目录 → Open In Terminal → 输入命令，避免路径错误
- 删函数前，先用 GoLand 的 Find Usages 查一遍该函数是否出现在
init()、包级变量赋值、reflect.Value.Call字符串中 - 删完立刻跑测试：
go test ./...，尤其注意那些没显式 import 但依赖包级 init 行为的测试
哪些情况 deadcode 会漏报或误报？
它基于静态调用图，对运行时动态行为无能为力。以下三类必须人工确认：
-
runtime.FuncForPC或日志中硬编码函数名：fmt.Errorf("failed in %s", "helper")→ deadcode 看不到字符串引用 - 空接口赋值：
var _ interface{} = helper→ 它只识别显式调用，不识别类型断言式引用 - 接口隐式实现注册：
var _ io.Closer = &MyStruct{}→ 如果MyStruct.Close没被调用，但Close函数本身被 deadcode 标为 unused，删了就破坏接口契约
真正麻烦的不是工具没报，而是它报了你不敢删——得翻 init、测试、反射、配置驱动逻辑，才能确定那行 unused func 到底是不是真的“死”。
