goland 本身不检测废弃代码，需集成 staticcheck 才能精准识别未使用函数、变量、类型等；safe delete 不可靠，需结合 staticcheck、全局搜索、依赖分析及运行时验证确保安全删除。
GoLand 本身不检测废弃代码，得靠 staticcheck 集成
GoLand 的 Inspect Code 和默认检查器对未使用函数、变量、类型几乎无感知——它依赖 Go 编译器和 go vet 的能力，而 go vet 默认关闭 -unused 检查（因历史误报率高）。真正能精准识别 func legacyHandler()、var unusedConfig 或私有结构体字段的，是 staticcheck。它不是 GoLand 内置功能，必须手动接入。
实操建议：
- 安装：
go install honnef.co/go/tools/cmd/staticcheck@latest（确保$GOPATH/bin在$PATH中） - 在 GoLand → Settings → Tools → Staticcheck 中启用，并勾选
Run staticcheck on the fly - 关键配置项：
--checks=all（或显式加--checks=SA4006,SA4010,SA4016），避免漏掉未读取变量、未调用方法等 - 若项目含
//go:build ignore或测试专用包，需在 GoLand 的 Staticcheck 设置里填入-ignore="SA.*:.*_test.go"，否则测试桩会大量误报
别信 GoLand 的 “Safe Delete”，它只看 import 和符号引用
右键 → Refactor → Safe Delete 看似智能，但它只分析当前文件内是否被其他 Go 文件 import 或直接调用，完全忽略反射、字符串拼接、配置驱动等运行时加载路径。比如 reflect.Value.Call 调用的 legacy.Process()，或 JSON 配置中指定的 "handler": "legacy_v1"，Safe Delete 会直接放行——删完就 panic。
实操建议：
- 删前先跑
staticcheck ./...，确认无SA4006（未使用符号）、SA4010（未实现接口方法）残留 - 搜索整个项目：
grep -r "legacy\|v1\|old" --include="*.go" .，重点查字符串字面量、结构体 tag、JSON key、HTTP 路由注册点 - 删函数前，检查是否有
http.HandleFunc("/old", ...)或router.POST("/api/v1/xxx", legacy.Handler)这类隐式引用 - 删包前，执行
go mod graph | grep your-legacy-package，确认没有间接依赖链
用 go:build 标签让废弃代码“编译即失效”
有些代码不能立刻删除（如灰度中旧协议 handler），但必须阻止新分支、新构建流程再引用它。仅靠注释或命名约定毫无约束力。//go:build !v2 这类标签能让 Go 编译器在特定构建条件下彻底忽略该文件——不是跳过执行，是根本不会解析、类型检查、生成 AST。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
实操建议：
- 在废弃文件顶部加单行构建标签：
//go:build old_version（不要用!new_version，易逻辑翻转） - 构建时明确禁用：
go build -tags="" ./...（空 tags 会让所有old_version文件失效） - CI 中强制：在
go build命令后加-tags=""，并配合staticcheck -fail，一旦某文件被意外启用就立即失败 - 避免多条件标签：
//go:build old_version && !test容易因构建环境差异导致行为不一致，拆成handler_old.go和handler_old_test.go更可靠
删完别急着提交，先验证 runtime 行为
静态工具能揪出“没被调用”的代码，但无法保证“删了之后逻辑仍完整”。比如一个被删掉的中间件可能默默承担了日志埋点或 auth header 清洗；一个被删的私有字段可能被 json.Unmarshal 依赖做零值填充。这些只有运行时才能暴露。
实操建议：
- 删完立刻跑：
go test -race ./...（竞态检查可能暴露被删函数留下的 goroutine 泄漏） - 启动服务后 curl 所有已知 endpoint，尤其注意 500、404、panic 日志；用
curl -v http://localhost:8080/debug/pprof/goroutine?debug=2看是否有残留 goroutine - 检查日志关键词：
nil pointer、invalid memory address、unimplemented——这些常是删了但没删干净的信号 - 如果项目用 Bazel/Nix，删完后必须重跑
bazel build //... && bazel test //...，它们的依赖图比go build更严格
最危险的不是删错，而是删了一半——比如删了 handler 却忘了删对应路由注册，或删了结构体字段却没改 JSON unmarshal 逻辑。工具只能帮你定位“哪些可能废弃”，最终判断得靠你对业务路径的理解。
