GoLand不直接标出未导出函数死代码，因其仅做浅层静态推断，无法构建完整调用图；需用deadcode工具扫描（如deadcode ./），配合IDE跳转、全局搜索和Safe Delete验证，再人工排查init、接口绑定、反射等隐式调用。
GoLand 本身不内置死代码检测能力，它依赖外部工具（如 deadcode）或编译器提示来识别未调用函数；你不能靠“一键清理”按钮完成这件事，必须组合命令行工具 + IDE 操作 + 人工验证。
为什么 GoLand 不直接标出未导出函数的死代码
GoLand 的代码分析聚焦于语法、类型、引用可达性，但对“是否被调用”仅做浅层静态推断：它能发现明显未使用的变量或 import，但无法构建完整的包内调用图——尤其当函数可能被 init()、包级变量初始化、reflect、接口空声明（var _ io.Writer = &MyWriter{}）间接触发时，IDE 默认保守保留。它不会把 func helper() {} 标为灰色或提示“未使用”，除非该函数连声明都没被任何 AST 节点引用（极少见）。
用 deadcode 扫描未调用的私有函数
这是目前最可靠、最轻量的方案，专为 Go 包内未导出函数设计：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 安装：
go install github.com/tsenart/deadcode@latest - 在 module 根目录下运行：
deadcode ./（扫描全部子包）或deadcode ./pkg/util（指定路径） - 输出示例：
pkg/util.go:42:6:unused func parseConfig，直接定位到行号和函数名 - 注意：默认不检查导出函数；若需一并扫描，加
-all参数：deadcode -all ./ - 误报常见场景：
var _ = parseConfig（赋值给空白标识符）、fmt.Sprintf("%s", "parseConfig")（字符串硬编码）、runtime.FuncForPC动态查找——这些都得人工确认是否真可删
配合 GoLand 快速验证和清理
扫描出结果后，别直接删，先在 IDE 内交叉验证：
- 在 GoLand 中打开报告的文件，将光标放在函数名上，按
Ctrl + Click（Windows/Linux）或Cmd + Click（Mac）——如果跳转失败、无任何引用高亮，基本确认未被调用 - 用
Ctrl + Shift + F全局搜索函数名，重点看是否出现在：init()函数里、包级变量初始化表达式中（如var x = helper()）、日志或错误信息的字符串字面量中 - 删之前，右键函数名 → Refactor → Safe Delete（不是直接按
Delete），GoLand 会尝试分析引用并弹窗警告——虽然它不一定能发现反射调用，但至少拦住显式引用 - 删完立即运行
go test ./...和关键集成流程，防止破坏隐式契约（比如某个中间件注册依赖了未导出方法的副作用）
真正容易被忽略的不是“怎么删”，而是“哪些看似没用其实不能删”：一个没被调用的 func initDB() 可能正被 init() 自动执行；一个空方法体的 Close() 可能是实现 io.Closer 所必需的接口契约。每次清理前，花 10 秒看一眼它是否出现在 init、包级变量、接口绑定或字符串中，比事后 debug 强十倍。
