goland索引卡在“resolving dependencies”主因是ide模块索引与go.mod/go.sum/缓存状态不一致，需清理.idea、执行go clean -modcache、禁用自动sync、检查goproxy/gosumdb及replace配置，并验证go list -m all是否正常。
GoLand 索引卡在 “Resolving dependencies” 怎么办？
不是项目本身构建失败，而是 IDE（尤其是 GoLand）在后台反复尝试解析模块依赖，CPU 占用飙高、UI 假死、文件跳转失效——这通常不是代码问题，而是 GoLand 的 module index 与本地 go.mod / go.sum / 缓存状态不一致导致的。
常见诱因包括：项目重命名后未清理缓存、go mod init 路径错误、replace 或 exclude 规则未被 IDE 正确识别、或 GOPROXY 配置变更后索引未刷新。
- 先确认 GoLand 使用的 Go SDK 和模块模式是否匹配：Settings → Go → GOROOT 和 GOPATH 必须指向真实安装路径；
GO111MODULE应为on（不要设为auto，避免 IDE 在非标准路径下误判） - 强制重建索引：File → Close Project → 删除项目根目录下的
.idea目录（保留.git）→ 重新 Open Folder → 等待 “Indexing…” 完成（首次会慢，但比卡死强） - 禁用“自动 sync go.mod”：Settings → Go → Modules → 取消勾选 “Synchronize Go modules on startup and update on external changes”，改用手动触发
go mod tidy后点击右上角 “Reload project” 按钮
为什么 go clean -modcache 能缓解索引卡死？
GoLand 的依赖解析底层仍调用 go list -m all 等命令。如果本地模块缓存（$GOPATH/pkg/mod 或 $GOCACHE 下的 download）里存在损坏/不完整/路径错位的包（比如旧项目名残留），go list 就会阻塞或返回异常结果，GoLand 便陷入无限等待。
go clean -modcache 不是清空所有缓存，而是精准删除 $GOPATH/pkg/mod 下所有已解压的模块源码（不影响 download/ 中的 zip 和 hash 文件），让后续 go mod tidy 强制重新拉取并解压——这对修复“路径变更后索引找不到包”特别有效。
- 执行前先
go mod tidy确保go.mod是干净且可解析的（无报错） - 运行
go clean -modcache，等待命令结束（通常几秒到一分钟） - 再在 GoLand 中手动 Reload project，观察 “Resolving dependencies” 是否快速完成
- 若仍卡住，说明问题不在缓存，而在
go.mod中的replace指向了本地不存在的路径，或require项引用了私有仓库但未配置GOPRIVATE
CI 构建正常，但 GoLand 卡死：重点查这三个地方
开发环境和 CI 环境行为不一致，往往暴露的是 IDE 配置盲区，而非代码问题。
-
GOPROXY差异：CI 通常显式设为https://goproxy.cn，而 GoLand 默认读系统环境变量——检查 Settings → Go → Environment Variables 里是否漏配GOPROXY，或被 IDE 自带的 proxy 设置覆盖 -
GOSUMDB阻塞：若项目含私有模块且未设GOSUMDB=off或GOSUMDB=sum.golang.org+insecure，GoLand 在校验 checksum 时可能超时卡住（尤其网络策略严格时） - vendor 干扰：即使项目启用了 Modules，若存在
vendor/目录且 GoLand 启用了 “Use vendor directory”，它会优先扫描 vendor 而非模块缓存——而 vendor 中若有 symlink 或损坏文件，索引极易崩溃；建议删掉vendor/或在 Settings → Go → Vendor 中禁用该选项
真正卡死的根源，往往藏在 go.mod 里一行不起眼的 replace 或环境变量里一个没生效的 GOPRIVATE。与其反复重启 IDE，不如先用终端跑通 go list -m all —— 如果它卡住，GoLand 一定也卡；如果它秒出结果，那问题 100% 出在 IDE 配置层。
