调用层次图不是重构工具，而是诊断入口，用于定位函数调用关系以判断删、提、并等重构动作，需配合rename、extract method等操作落地。

直接说结论：调用层次图（Call Hierarchy）本身不是重构工具，而是诊断入口——它帮你快速定位“哪些函数被谁调用、被调了多少次”，从而判断是否该删、该提、该合并。真要重构，得配合 Rename、Extract Method 或 Inline 才能落地。

为什么先看调用层次图再动手重构

很多团队一上来就删函数或拆包，结果发现某处测试里还藏着一个冷门调用，跑不起来。调用层次图能暴露这种“表面没用、实际还在用”的隐性依赖。尤其在老项目里，utils 包里一堆命名模糊的函数（比如 DoSomething、HandleData），光看定义没法判断是否可删，必须看谁在调它、在哪调、调了几回。

右键函数名 → Find Usages 也能查调用，但它是扁平列表；而调用层次图（快捷键 Ctrl+Alt+H / Cmd+Option+H）是树状结构，一眼看出调用链深度和分支数量——比如某个 parseConfig 函数被 3 个服务初始化调用，其中 2 个只用到前半段逻辑，这就提示你：该提取子函数了。

GoLand 2026.1.1

GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。

下载

识别三类典型冗余模式

调用层次图里出现以下结构，基本就是重构信号：

• 单点高频调用：一个函数被超过 5 处不同模块调用，且参数/返回值高度一致 → 考虑提升为公共接口，或检查是否该拆成更细粒度函数
• 调用链过深：A → B → C → D → E，且中间 B/C/D 都只做简单包装、无实质逻辑 → 可用 Inline 把 B/C/D 内联进 A，减少跳转开销
• 跨包循环调用：在图中看到 pkgA → pkgB → pkgA 的闭环 → 这是架构坏味道，必须解耦，通常需要引入中间接口或重构领域边界

重构时最容易踩的坑

调用层次图只告诉你“谁调了谁”，不告诉你“能不能动”。实际操作中常翻车的点有：

• 忽略测试文件里的调用：默认 Find Usages 不包含 _test.go，但调用层次图会显示。删函数前务必确认测试里没 mock 它或直接调用它
• 误判私有方法的可见性范围：Go 中小写字母开头的函数只能被同包调用，但调用层次图可能把其他包里同名函数也列进来（尤其 IDE 缓存未刷新）。右键调用点 → Go to Declaration 确认是不是真引用
• 重构后没更新 go.mod 依赖：如果把函数从 pkgA 提取到新包 pkgC，旧包的 go.mod 不会自动加 require。手动运行 go mod tidy，否则 CI 会失败

调用层次图的价值不在“图”本身，而在它迫使你停下来问一句：这个函数存在的理由，现在还成立吗？真正难的不是怎么按快捷键，而是判断哪一层调用该保留、哪一层该抹掉——这需要你对业务上下文比对 IDE 更熟。