直接按Alt+F7（Windows/Linux）或Option+F7（macOS），光标停在函数名上即可列出所有静态调用位置；该结果基于代码结构分析，不反映运行时实际执行路径，遇泛型、反射或跨module调用可能显示“Unknown location”。
GoLand 里怎么看函数被谁调用
直接按 Alt+F7（Windows/Linux）或 Option+F7（macOS），光标停在函数名上就能列出所有调用位置。这不是运行时追踪，而是静态代码分析结果——它只告诉你“哪些地方写了这个函数调用”，不反映实际执行路径或条件分支是否命中。
常见错误是以为这个列表等于真实调用链：比如函数在 if 分支里被调用，但条件为假时根本不会执行；或者被 interface 方法间接调用，GoLand 默认不展开多态跳转（需手动启用 “Include implementations”）。
- 右键调用结果 → 勾选 “Show overloaded methods” 可看到同名方法的不同实现
- 结果窗口顶部有筛选按钮，可排除 test 文件或 vendor 代码
- 如果调用点显示为 “Unknown location”，大概率是泛型函数或反射调用，GoLand 暂无法解析
怎么查看某次请求的实际函数执行顺序
GoLand 本身不提供运行时调用链录制功能，必须靠调试器单步跟进或配合日志/trace 工具。最实用的做法是：打断点 + Step Into（F7）+ Watch 表达式观察 runtime.Caller(1) 返回值。
注意别依赖 “Evaluate Expression” 里直接调 runtime.Caller(0) —— 它返回的是调试器自身帧，不是你的业务代码位置。真正想看当前函数的调用者，得在断点处执行：runtime.Caller(1)，再用 runtime.FuncForPC(pc).Name() 解析函数名。
- Step Into 进入第三方库时可能跳到汇编，关掉 “Show disassembly”（Settings → Build → Debugger → Stepping）更清晰
- Watch 窗口里输入
runtime.Caller(1)后，右侧会显示文件、行号；再输runtime.FuncForPC(_).Name()（下划线代表上一次表达式结果）得到函数全名 - goroutine 切换时调用栈会变，务必在目标 goroutine 上暂停后再查
为什么 Call Hierarchy（Ctrl+Alt+H）有时找不到调用点
不是代码写错了，而是 GoLand 的索引没更新或作用域受限。它只分析当前 project scope 下已打开或被 module 引用的包，vendor 目录、replace 路径、未 go mod init 的目录默认不参与分析。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
典型现象：函数定义在 internal/ 包里，但调用方在另一个 module，GoLand 显示 “No usages found”。这不是 bug，是设计使然——internal 对外不可见，静态分析天然隔离。
- 强制重建索引：File → Reload project from disk，或
Ctrl+Shift+O（macOSCmd+Shift+O） - 检查 Settings → Go → GOPATH 和 Modules 是否指向正确路径，尤其多 workspace 场景
- 若用
replace重定向本地包，确保该路径已被 GoLand 识别为 module（底部状态栏应显示 module name）
生成可视化调用图要绕开哪些坑
go-callvis 是唯一能导出 SVG/PNG 调用图的主流工具，但它不理解 context 传递、interface 动态分发和 goroutine 启动点，画出来的图只是“语法可见调用”，不是“运行时真实路径”。
比如 http.HandlerFunc 注册的 handler 函数，在图中只会连到 http.ServeHTTP，不会体现中间件链；io.Reader.Read 实现类也不会自动关联到具体 struct，除非你手动加注释标记。
- 运行前先
go mod tidy，否则缺失依赖会导致图中断 - 避免用
-std参数，标准库调用边太多，图会爆炸；聚焦自己的./...包 - 输出 SVG 后用浏览器打开，右键节点可复制函数签名，但别信箭头方向——它只表示“可能调用”，不保证执行顺序
实际调试时，静态分析和运行时 trace 必须配合着用：Call Hierarchy 定位“可能在哪”，debugger 确认“这次到底走了哪条路”，而 OpenTelemetry 日志才是最终验证“跨服务、跨 goroutine 的完整链路”。三者缺一不可，但各自能力边界得拎清。
