GoLand依赖图不可用需先启用Go Modules集成并正确加载模块；图表仅显示当前打开文件的实际编译依赖，不支持原生导出，需截图或复制；第三方依赖缺失多因未打开.go文件或构建上下文不完整。
GoLand里点不出“Dependencies Diagram”？先确认模块加载状态
GoLand不会自动把有go.mod的目录识别为模块项目，右键项目根目录看到的“Reload project”不是正确操作。必须选“Load project with Go Modules”，否则图表功能完全不可用。
Settings → Go → Go Modules中Enable Go Modules integration必须勾选；若项目含多个go.mod（如子模块），每个模块目录都要单独右键 → “Mark Directory as → Go Modules Root”。
- 终端执行
go list -m all报错，大概率是GO111MODULE=on没生效 —— GoLand Terminal默认不继承shell环境变量，需在Settings → Tools → Terminal中开启Shell integration，或手动设置该变量 - 图表为空但
go list -json -deps ./能出结果？检查是否启用了//go:build ignore或构建约束未命中，这类包会被直接跳过 - 依赖图只显示本地包、标准库，第三方全无？说明当前没打开任何
.go文件 —— 图表默认只渲染“当前编辑器打开的文件”实际参与编译的依赖链
右键菜单里“Show Dependencies Diagram”导出不了PNG？没有原生导出选项
GoLand的依赖图不提供“Export as PNG/SVG”菜单项，所谓“导出”只有两种实操路径：截图（Ctrl+PrintScreen）或复制为图片（右键图表 → Copy Diagram to Clipboard）。
如果图太大导致IDE卡顿甚至假死，点击图表右上角齿轮图标，关闭Show standard library packages——标准库节点常占图中70%以上，关掉后节点数锐减，渲染可恢复响应。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 想看整个
go.mod的require关系？别在项目根目录右键，而是打开任意一个.go文件再右键调图 - 图中没出现
replace后的本地路径？正常。GoLand图表基于go list输出，而go list返回的是替换前的原始模块名，不是./local - 放大后文字糊成一片？不是DPI问题，是节点过多导致字体渲染失真。优先删减标准库、按vendor分组、或改用命令行工具生成静态图
想导出真正可用的模块级依赖图？用go mod graph + dot
go mod graph是Go原生命令，唯一能批量获取模块依赖边的方式。但它输出的是空格分隔的纯文本，不能直接喂给Graphviz的dot命令。
需清洗后才能生成DOT格式：echo "digraph G { node [shape=box];" && go mod graph | sed 's/ / -> /' | sed 's/@[^ ]*//g' | sed 's/^/"/; s/$/"/' | sed 's/ -> /" -> "/' && echo "}"，再管道给dot -Tpng -o deps.png。
-
go mod graph不处理replace和exclude，图里仍显示原始模块路径，容易误判真实依赖来源 - 大型项目务必加
head -n 500截断，否则DOT文件过大，dot可能生成百兆PNG且无法打开 - 若需反映“谁真正import了谁”，而非“谁声明了谁”，得换用
importgraph：先go install github.com/kisielk/importgraph@latest，再运行importgraph -format dot ./ | dot -Tpng -o imports.png
图表里第三方依赖显示异常？重点查go list执行上下文
GoLand依赖图底层调用go list -json -deps -f，任何影响该命令执行的因素都会导致节点缺失或错误。这不是IDE渲染问题，而是构建上下文本身不完整。
常见干扰项包括：工作目录不在模块根、GOOS/GOARCH环境变量与目标平台不一致、build tags未匹配到当前文件、或vendor启用但未勾选Settings → Go → Build Tags & Vendoring中的Enable vendoring support。
- 运行
go list -json -deps ./时若报no required module provides package，说明当前目录未被识别为有效模块，go.mod可能损坏或缺少module声明行 - 图表中看到
golang.org/x/net但看不到它依赖的golang.org/x/text？检查go list -json -deps golang.org/x/net是否真包含后者 —— 图表只展示实际参与构建的传递依赖，不是go.mod里所有间接require - 调试时发现图里没显示某包，但
dlv能断点进去？说明该包在运行期才动态加载（如plugin或reflect），静态依赖图天然无法覆盖
go.mod里写了100个require，只要某个包因构建约束、_导入或go:build被排除，它就不会出现在图中。这点最容易被忽略，也最常引发误判。 
