根本原因是模块模式未启用或项目根目录缺失go.mod；需确认存在go.mod、勾选GoLand中Enable Go Modules integration、正确配置GOPROXY环境变量、避免项目位于GOPATH/src下。
GoLand里依赖没自动下载，go mod tidy 也不生效怎么办
根本原因通常是模块模式没真正启用，或者项目根目录缺失 go.mod。GoLand 不会自动帮你初始化模块，它只响应已存在的模块上下文。
检查点：
- 确认当前项目根目录下有 go.mod 文件；没有就手动运行 go mod init example.com/myapp
- 在 GoLand 的 File → Settings → Go → Go Modules 中，必须勾选 Enable Go Modules integration
- Environment 字段填的是环境变量键值对，不是命令行语法，正确写法是：GOPROXY=https://goproxy.cn,direct，不能带 export 或分号
- 如果项目在 GOPATH/src 下，且 GO111MODULE=auto（默认），GoLand 可能仍 fallback 到 GOPATH 模式 —— 直接删掉 GOPATH/src 下的项目，挪到任意非 GOPATH 路径再开
用 go get 安装包时版本总不对，@v1.12.0 被忽略
这不是 GoLand 的问题，是 go get 在模块模式下的行为逻辑变了：它现在本质是“升级依赖”，不是“安装包”。如果你没在代码里 import 过那个包，go get 只会把它加进 go.mod，但不会触发下载；如果已经 import 过，它才真正拉取并更新版本。
可靠做法：
- 先在 .go 文件中写上 import "github.com/gin-gonic/gin"，保存
- 再执行 go get github.com/gin-gonic/gin@v1.12.0
- 紧接着跑一次 go mod tidy，确保 go.sum 同步校验信息
- 注意：如果 go.mod 里已有该包的旧版本，go get 会覆盖；但若该包是间接依赖（indirect），直接 go get 可能不生效，得靠 go mod graph | grep 定位源头再处理
想引用本地开发中的另一个模块，replace 怎么配才不报错
replace 是多模块协作时最常用的调试手段，但容易因路径错误或模块名不匹配失败。关键不是写对语法，而是让 Go toolchain 能同时识别主模块和被替换模块的 module 声明。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
实操要点：
- 两个模块各自都有合法的 go.mod，且 module 行声明的路径（如 example.com/shared）必须完全一致，大小写、斜杠都不能错
- replace 写在主模块的 go.mod 里，格式为：replace example.com/shared => ../shared，路径是相对于主模块 go.mod 的位置
- 执行 go mod tidy 后，检查 go.mod 是否保留了这行 replace，且没有自动变成 // indirect 或消失 —— 消失说明 Go 认为路径不可达或模块名不匹配
- GoLand 的代码跳转和自动补全在 replace 生效后才能识别本地源码；如果仍跳不到，重启 GoLand 的 Go Modules 索引（File → Invalidate Caches and Restart）
依赖最终存在哪？go.sum 能删吗
所有通过 Go Modules 下载的包，物理路径都在 $GOPATH/pkg/mod 下，按模块路径 + 版本哈希组织，比如 github.com/gin-gonic/gin@v1.12.0 对应 github.com/gin-gonic/gin@v1.12.0/ 目录。GoLand 的依赖解析、跳转、补全都基于这个缓存，不是从项目里 vendor 出来的。
go.sum 绝对不能删。它不是日志，是完整性锁文件：每行记录一个模块的校验和（h1: 开头）或其依赖的校验和（go.sum 里可能有两行对应同一个模块）。删了会导致 go build 失败，报错类似 verifying github.com/sirupsen/logrus@v1.9.0: checksum mismatch。CI/CD 流程中也必须提交 go.sum，否则不同机器拉的同一版本包内容可能不一致。
