答案是必须在含main.go的项目最顶层目录执行go mod init。goland不会自动触发模块初始化，需手动在终端进入正确路径后运行go mod init github.com/yourname/yourproject，否则生成路径错乱或无法识别。
GoLand里go.mod没生成，go mod init该在哪儿执行
项目根目录没go.mod，说明还没进入模块模式，不能靠IDE自动触发。必须手动在终端里执行go mod init，且路径必须是项目最顶层文件夹（含main.go的那个目录）。
常见错误是：在子目录或错误路径下运行，结果生成了空模块或路径错乱；或者用Windows资源管理器双击打开项目，没进对目录就点开GoLand，导致IDE默认工作目录不是你想要的根目录。
- 确认当前终端位置：
pwd（macOS/Linux）或cd（Windows），确保输出是你项目的绝对路径 - 执行：
go mod init github.com/yourname/yourproject（模块名建议用将来可能托管的Git路径，非必需但推荐） - 成功后会生成
go.mod，GoLand通常几秒内自动识别并启用Go Modules支持
go get失败报“unrecognized import path”，其实是代理没生效
典型错误信息：unrecognized import path "golang.org/x/net/http2" 或 dial tcp 216.239.37.1:443: connectex: A connection attempt failed...。这不是代码问题，而是国内无法直连golang.org等域名，go get底层仍走原始地址，没走代理。
关键点在于：GoLand的Settings里配置的GOPROXY只影响IDE内部操作（比如自动补全、包索引），不影响你在Terminal里敲的go get命令——它读的是系统环境变量。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 在终端中执行：
go env -w GOPROXY=https://goproxy.cn,direct - 验证是否生效：
go env GOPROXY，输出应为https://goproxy.cn,direct - 如果用PowerShell，别漏掉
-w参数；用CMD需改用set GOPROXY=https://goproxy.cn,direct（但仅当前窗口有效）
go mod tidy反复添加又删掉同一行indirect依赖
现象：运行go mod tidy后go.mod里某行带// indirect的require忽有忽无，甚至两次连续执行结果不同。这通常是因为某个间接依赖被多个路径引入，而版本不一致，Go工具链在做“最小版本选择”（MVS）时来回摇摆。
根本原因不是命令错了，而是项目里存在冲突的版本约束。比如github.com/sirupsen/logrus被A包要求v1.8.0，又被B包要求v1.9.0，而你的main.go没直接import它，Go就按规则选一个，但下次tidy可能因缓存或顺序变化选另一个。
- 查清来源：
go list -m -json all | grep logrus或更直接：go mod graph | grep logrus - 锁定版本：
go get github.com/sirupsen/logrus@v1.9.0（显式指定，会覆盖间接引入的版本） - 注意：
indirect本身不该手动删——它是Go自动标记的，删了下次tidy还会加回来
依赖下载后放在哪儿？go.sum能不能删
依赖包实际存放位置是$GOPATH/pkg/mod（不是项目里），每个模块按路径@版本分目录存储，比如github.com/gin-gonic/gin@v1.12.0。项目里的go.mod只是声明，go.sum则是所有依赖及其子依赖的校验和快照。
go.sum绝不能删。它不是缓存，而是安全校验依据：每次go build或go run都会核对下载包的SHA256是否匹配go.sum，不匹配就报错退出。删了会导致后续构建失败，或更糟——跳过校验，引入被篡改的包。
- 想清理本地缓存？用：
go clean -modcache（清空$GOPATH/pkg/mod，不影响go.sum） - 想重生成
go.sum？删掉它，再跑一次go mod tidy（但仅限你确认所有依赖源可信） - 团队协作时，
go.sum必须提交到Git——它是可重现构建的关键一环
go.sum这种看似冗余的文件，恰恰是生产环境里最容易被误删又最难排查的单点故障。
