goland 打开项目时自动下载依赖需满足三个前提：项目根目录存在有效 go.mod、go111module=on 已启用、goproxy 配置可访问；若底部无“downloading modules…”提示，说明自动下载未触发。
GoLand 打开项目时自动下载依赖是否生效
GoLand 默认会在项目打开或 go.mod 变更后触发模块下载，但这个行为依赖三个前提：项目根目录存在有效的 go.mod、GO111MODULE=on 已启用、GOPROXY 配置可访问。如果没反应，大概率是其中一项未满足。
检查方式很简单：go env GO111MODULE 输出应为 on；go env GOPROXY 应非空（推荐值为 https://goproxy.cn,direct）；且当前打开的文件夹里必须有 go.mod——不是子目录，也不是误放在 src 里。
- 若
go.mod是手动创建但内容为空或格式错误（比如缺少module行），GoLand 不会识别为有效模块 - 右键项目 → “Reload project” 不会触发下载，必须等 GoLand 自动检测到
go.mod变更或重启 IDE - 首次打开时底部状态栏会显示 “Downloading modules…”，若无此提示，说明自动下载逻辑根本没启动
VSCode 中 gopls 无法拉取依赖的典型卡点
VSCode 依赖 gopls 提供包解析和跳转能力，但它本身不负责下载模块——它只读取本地缓存（$GOPATH/pkg/mod）。所以你看到 “cannot find package” 错误，往往不是 gopls 坏了，而是模块根本没下下来。
关键动作不是重装插件，而是确认两件事：gopls 是否在正确的模块根目录下运行、以及环境变量是否被它读到。
- 打开命令面板（
Ctrl+Shift+P），执行Go: Restart Language Server—— 这会强制 gopls 重新加载当前工作区的go.env - 确保 VSCode 的“打开文件夹”路径就是
go.mod所在目录，否则 gopls 退化为 GOPATH 模式，完全无视go.mod -
go.toolsEnvVars设置必须写在 VSCode 的用户设置或工作区设置里，且需包含GO111MODULE和GOPROXY，仅改系统环境变量无效
IDEA 导入 Go 项目后依赖未就绪怎么办
IntelliJ IDEA（含 GoLand）导入项目时不会自动执行 go mod tidy 或 go mod download，它只做索引准备。所谓“自动下载”，实际是指后续编辑、构建、运行等操作触发的按需拉取，而不是导入瞬间就全量下载。
如果你刚导入就立刻写 import "github.com/gin-gonic/gin" 并期望立刻补全，大概率失败——因为此时 gin 还没进本地缓存。
- 最直接的解法：在项目根目录终端运行
go mod tidy，它会补全缺失依赖并写入go.mod，接着再运行go mod download显式拉取 - 右键
go.mod文件 → “Load Go Modules” 是 IDEA 提供的快捷入口，本质就是执行go mod tidy - 不要依赖 “Auto-import” 功能来触发下载——它只处理已缓存的包，对未下载的第三方包无效
为什么 build/run 能下载而 IDE 不行
根本区别在于：命令行 go build 和 go run 是构建驱动型下载，只要 import 路径合法且未缓存，就会实时 fetch；而 IDE 的语言服务（如 gopls）是缓存驱动型，只查本地已有模块，不主动联网。
这意味着即使你用 go run main.go 成功跑起来，IDE 仍可能报红——因为 gopls 没刷新缓存视图。
- 运行一次
go build -v后，立刻执行Go: Restart Language Server，让 gopls 重新扫描缓存目录 - 某些 IDE 插件（如旧版 Go plugin）会把
go.sum校验失败的模块直接过滤掉，导致即使已下载也无法识别，此时要运行go mod verify确认完整性 - 替换路径（
replace）指向远程 Git 地址时，go mod download会跳过它，但go build会在构建时才拉——这种差异会让 IDE 和命令行行为不一致
gopls 启动时读取的环境快照，而不是实时监听 $GOPATH/pkg/mod 目录变化。改完 GOPROXY 或 go.mod 后，不重启语言服务器，IDE 就永远不知道新模块在哪。
