go mod tidy失败时应优先查看终端报错最后一行的require路径，用go mod graph | grep定位引入模块及版本冲突，检查go.sum是否含同一包多哈希，并验证replace指向路径是否存在匹配go.mod。
go mod tidy 执行失败时如何定位冲突根源
GoLand 本身不主动扫描“潜在”依赖冲突，它只在你执行 go mod tidy 或保存 go.mod 文件时触发校验。真正暴露冲突的通常是命令行报错，比如 go: errors parsing go.mod 或 require github.com/some/pkg v1.2.0: version "v1.2.0" invalid: unknown revision。这类错误不是 GoLand 隐藏的，而是模块解析器明确拒绝加载。
关键动作是：不要跳过终端输出，尤其注意最后一行的 require 行和它前面的 github.com/xxx/yyy 路径——那才是冲突源头包。
- 打开
Terminal面板（Alt+F12），手动运行go mod graph | grep xxx查看该包被哪些模块间接引入，版本是否不一致 - 检查
go.sum中同一包是否存在多个哈希（说明本地缓存里混了不同版本） - 若项目含 replace 指令，确认其指向路径下确实存在
go.mod且版本号与 require 行兼容
GoLand 的 Dependencies 工具窗口怎么看实际生效版本
菜单栏 View → Tool Windows → Dependencies 显示的是当前 go.mod 解析后的扁平化依赖树，但它默认只展示“最终选用版本”，不显示冲突点。要看出矛盾，得主动展开每个节点：
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 点击包名旁的三角箭头，展开所有 transitive 引入路径
- 如果同一包出现多个版本（如
github.com/gogo/protobuf v1.3.2和v1.4.0），说明有版本分歧；GoLand 会用粗体标出被选中的那个 - 右键某个版本 → Jump to Declaration 可直接跳到它在哪个
require行被声明 - 注意灰色字体的包：表示未被实际引用（import），但因其他依赖间接拉入，可考虑用
go mod vendor后清理
修改 import 语句后依赖没自动更新怎么办
GoLand 默认不会在你删掉一个 import _ "net/http/pprof" 后立刻删掉 go.mod 里的对应 require。这是设计使然——模块依赖是 project-level 的，不是 file-level 的。所以常见误判是：“我删了 import，为什么 go.mod 还在？”
- 必须手动触发同步：按快捷键
Ctrl+Shift+O（Windows/Linux）或Cmd+Shift+O（macOS），即 Optimize Imports - 或者右键项目根目录 → Reload project，强制 GoLand 重新解析整个模块图
- 如果仍残留无用依赖，运行
go mod tidy -v查看详细日志，它会明确告诉你哪些 require 是“unused”并准备删除 - 别依赖 “Auto-import on paste” 选项——它只管加 import，不管删
为什么 go list -m all 不显示冲突但运行时报错
go list -m all 只列出当前 resolve 出来的版本，不校验 checksum 或网络可达性。真正卡住的往往在下载阶段，比如私有仓库权限失效、代理配置失效、或 GOPROXY 返回了损坏的 zip 包。
- 先验证代理：在 Terminal 运行
go env GOPROXY，确认值为https://proxy.golang.org,direct或国内镜像（如https://goproxy.cn） - 临时关闭代理测试：
GO_PROXY=direct go list -m all，看是否报no required module provides package - 清空模块缓存：
go clean -modcache，再重试go mod tidy——很多“版本存在但校验失败”的问题源于本地缓存损坏 - 检查
go.mod中是否有replace指向本地路径，而该路径下go.mod的 module 名与 replace 声明不一致（大小写、路径拼写错误）
Settings → Go → Modules 里有个 Use GOPROXY 开关，默认勾选，但它只影响 IDE 内部的代码补全和跳转，不影响终端里 go mod 命令的实际行为。调试依赖问题时，永远以终端命令输出为准，IDE 界面只是辅助视图。
