goland中http proxy与goproxy无关：前者仅影响ide自身网络行为，后者由go env -w设置并控制模块下载，必须重启ide生效且需验证go env goproxy输出。
GoLand 里配的 HTTP Proxy 和 GOPROXY 不是一回事
很多人在 GoLand 设置里开了 HTTP Proxy（Settings → Appearance & Behavior → System Settings → HTTP Proxy），以为这样就能加速 go mod tidy，结果发现没用。这是因为 GoLand 的 HTTP Proxy 只影响 IDE 自身的网络行为（比如检查更新、下载插件、索引文档），并不转发给底层 go 命令。真正控制模块下载路径的是 Go 工具链自己的 GOPROXY 环境变量。
必须用 go env -w 设置 GOPROXY，不能只靠 IDE 界面
GoLand 不提供图形化界面设置 GOPROXY，它完全依赖系统或 shell 级别的 Go 环境配置。你在终端里执行：
go env -w GOPROXY=https://goproxy.cn,direct
这条命令会把配置写入 Go 的用户级配置文件（如 $HOME/go/env），所有后续调用的 go 命令（包括 GoLand 底层调用的）都会读取它。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 别用
export GOPROXY=...临时设置，GoLand 启动时不一定继承当前 shell 的环境变量（尤其 macOS 或某些 Linux 桌面环境） - 别手动改系统级环境变量（如
/etc/environment或~/.zshrc），容易和go env -w冲突，优先级混乱 - 设置后务必在终端运行
go env GOPROXY验证输出是否匹配，再在 GoLand 里点go mod tidy观察日志是否出现goproxy.cn
私有仓库必须同步配置 GONOPROXY 和 GONOSUMDB
如果你的项目依赖 gitlab.internal.company.com/my/pkg 这类内网地址，只设 GOPROXY 会导致 404 或校验失败。GoLand 执行 go get 时会严格检查这两项：
-
go env -w GONOPROXY=gitlab.internal.company.com,github.com/my-org：让这些域名跳过代理直连 -
go env -w GONOSUMDB=gitlab.internal.company.com,github.com/my-org：对应关闭 checksum 校验，否则go get会拒绝拉取（报错类似checksum mismatch） - 两个值必须完全一致，不支持通配符（
*.company.com无效），只能用逗号分隔的精确域名
GoLand 终端和构建工具可能缓存旧配置
即使你改了 GOPROXY，GoLand 的内置终端或 Run Configuration 有时仍沿用旧值，尤其在未重启 IDE 的情况下：
- 修改完
go env -w后，**必须重启 GoLand**，否则 Settings → Terminal → Shell path 下的终端可能没加载新配置 - 如果 Run → Edit Configurations → Go Build 里指定了 Environment variables，检查是否手动覆盖了
GOPROXY（这种覆盖会优先生效） - 偶尔遇到 GoLand 提示 “Module not found” 却实际能
go build成功，大概率是它的模块索引没刷新，点 File → Reload project 强制重载
go 命令。真正卡住的地方永远是 go 工具链能否连上正确的代理源——而这个开关，只在 go env 里，不在任何 GUI 设置页中。
