用 go tool trace 捕获真实执行路径比静态分析更可靠，因其能记录函数调用栈、goroutine 生命周期和 GC 事件，从而识别从未被调度的函数，尤其适用于依赖环境变量或外部服务的条件分支。
用 go tool trace 捕获真实执行路径比静态分析更可靠
静态扫描（比如 go list -f '{{.Deps}}' 或第三方工具）容易把条件分支里未触发的代码误判为“死逻辑”，尤其当分支依赖环境变量、配置或外部服务响应时。真正没被执行的逻辑，得靠运行时证据说话。go tool trace 能记录函数调用栈、goroutine 生命周期和 GC 事件，从中可反推出哪些 func 根本没进过调度器。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在典型业务路径（如 HTTP handler、CLI 命令入口）中加
runtime/trace.Start和defer runtime/trace.Stop() - 用
go tool trace trace.out打开可视化界面，点开 “View traces” → “Goroutines”，筛选出生命周期极短或从未处于 “running” 状态的 goroutine，再回溯其启动函数 - 重点关注被
go func() { ... }()启动但从未被调度的匿名函数——它们常是废弃的异步兜底逻辑
配合 go build -gcflags="-m -m" 查看编译期内联与未引用警告
Go 编译器在开启二级优化（-m -m）时，会对未被任何调用链引用的函数输出 can inline 或 deadcode 提示，这是比覆盖率更底层的信号。但注意：它只对包内可见函数有效，func init() 和导出函数（首字母大写）默认不会被标记为 deadcode，哪怕实际没被调用。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 逐个子包执行
go build -gcflags="-m -m" ./pkg/name 2>&1 | grep "func.*unused"，过滤出明确提示未使用的函数名 - 对
init()函数，需额外检查是否被 import 的副作用触发——如果该包只被_导入且无其他引用，它的init()就是可疑目标 - 若函数被反射（
reflect.Value.Call）或插件机制调用，-m -m会误报，需人工核验调用点是否存在reflect.TypeOf(&T{}).Method类型查找
用 go test -coverprofile=cp.out 结合 go tool cover 定位零覆盖函数
覆盖率本身不等于执行证据，但“0% 行覆盖 + 非测试文件”是强提示。关键在于排除测试专用逻辑（如 testHelper()）和故意跳过的分支（如 if false { ... }）。真正的历史遗留逻辑往往连测试都没覆盖，且长期无人维护。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 运行全量测试：
go test -coverprofile=cp.out -covermode=count ./...，避免只测主包遗漏依赖子包 - 用
go tool cover -func=cp.out | grep " 0.0%"列出所有零覆盖函数，重点筛掉文件名含_test.go或函数名含test、bench的条目 - 对零覆盖函数，用
git log -S "func name" -p查最后一次修改时间——如果超过 12 个月且提交信息含 “refactor”、“migrate”、“deprecated”，基本可确认已废弃
删除前必须验证 go mod graph 是否存在隐式依赖
有些函数看似孤立，实则被其他模块通过接口实现、类型断言或 plugin.Open 动态加载。直接删会导致构建失败或 panic，但错误信息可能非常模糊（比如 undefined: xxx 却找不到引用位置）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对目标函数所在包，运行
go mod graph | grep "your-module-name"，观察是否有外部模块显式依赖它；再反向查go list -deps ./... | grep "target-package"确认是否被间接引入 - 临时注释函数体，仅保留签名，然后跑
go build ./...—— 如果构建通过，说明无硬依赖；如果失败，错误里出现的cannot use ... as ... value in assignment往往暴露了接口实现关系 - 对疑似被插件或配置驱动的逻辑，搜索整个代码库：
grep -r "your-func-name" --include="*.go" .，特别留意 JSON/YAML 配置文件中的字符串字面量，它们可能作为函数名被plugin.Lookup或反射调用
最麻烦的是跨二进制边界的调用：一个函数在 A 服务里定义，但被 B 服务通过 RPC 或消息体里的函数名字符串调用。这种只能靠文档、部署清单或流量日志交叉验证，没有自动化银弹。
