GoLand 无真正安全删除功能，其 Safe Delete 因无法识别 init() 调用、字符串硬编码、接口赋值、构建标签及反射等场景而常不准；删前须 grep 查隐式调用、go mod why/go list 查跨包引用、deadcode 验证；删后必跑 race 测试并用 go tool nm 确认符号消失。
GoLand 本身不提供“安全删除未使用函数”的一键操作——它能高亮、提示、跳转，但删完是否真不影响运行，得你自己验证。编译器不报错、测试不覆盖、反射没调用，就可能删出线上问题。
为什么 GoLand 的「Safe Delete」经常不准
GoLand 的 Safe Delete（右键 → Refactor → Safe Delete）依赖静态分析，但它无法识别：
- 被
init()或包级变量初始化隐式调用的函数，比如var _ = helper() - 函数名被字符串硬编码：日志里写
"in " + runtime.FuncForPC(reflect.ValueOf(helper).Pointer()).Name()，或错误包装中拼接"failed in helper" - 被空接口赋值保留：如
var _ interface{} = helper或实现某个接口但没显式调用（var _ io.Writer = &MyWriter{}可能间接依赖Write方法） - 仅在特定构建标签下启用的调用路径，比如
//go:build integration里的测试入口
它还会把 reflect.Value.Call、plugin.Open、JSON 配置驱动的函数全部当作“不可达”，直接建议删除——这类必须人工 review。
删之前必须跑的三步验证
别信 IDE 提示，先确认函数真实存活路径：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 查是否被
init()调用：grep -r "func init" . | grep -A5 -B5 "helper" - 查是否参与包级变量初始化：
grep -n "helper()" *.go | grep "var\|const"，特别注意var x = helper()这种写法 - 查是否被其他包 import 并间接引用：运行
go mod why -m github.com/yourorg/yourpkg（如果函数在导出包里），或go list -f '{{.Deps}}' ./... | grep helper粗筛
若函数是私有的（小写首字母），且以上全无匹配，再结合 deadcode 工具二次确认：deadcode ./...。输出为空才表示真正未被任何调用链触及。
删之后必须检查的两个地方
删完不是结束，而是风险最高时刻：
- 运行所有测试：
go test -race ./...，尤其关注TestMain和集成测试，它们常通过反射或配置触发隐藏路径 - 检查构建产物符号表：
go build -gcflags="-l -N" -o tmpbin ./ && go tool nm tmpbin | grep helper，确保符号已消失；若还在，说明有未发现的引用或被内联了（加-gcflags="-m"看内联日志）
最易被忽略的是：函数被 //go:embed 或 //go:generate 注释间接依赖，或者作为 HTTP handler 注册但没出现在路由表里——这类不会出现在 deadcode 或 GoLand 分析中，只能靠代码走读和运行时日志交叉验证。
