go111module必须设为on，否则go mod命令失效；需执行go env -w go111module=on并验证输出为on，同时配置goproxy=https://goproxy.cn,direct以解决国内依赖拉取失败问题。
go version 能跑但 go mod 报错：GO111MODULE 没开
常见现象是 go run main.go 成功，但执行 go mod init 时提示 “no modules found” 或直接忽略、不生成 go.mod。根本原因是模块模式未启用。
现代 Go（1.16+）默认开启模块模式，但某些旧安装或手动配置可能仍处于 auto 模式——即仅在 GOPATH 外才启用。稳妥做法是显式开启：
-
go env -w GO111MODULE=on（必须执行，不是可选项） - 执行后验证：
go env GO111MODULE应输出on - 若项目已在
GOPATH/src下，GO111MODULE=on会强制走模块路径，不再依赖GOPATH
GOPROXY 配错了导致 go get 卡住或 403
国内用户不配代理，go get 基本必失败：超时、连接拒绝、证书错误、甚至返回 403（golang.org 被拦截后部分镜像返回伪造响应）。正确配置只有一条命令：
go env -w GOPROXY=https://goproxy.cn,direct-
goproxy.cn是七牛云维护的稳定镜像，比proxy.golang.org在国内更可靠 -
direct不是可选后缀，它表示“当代理找不到包时，回源官方校验”，缺了会导致私有模块或新包拉取失败 - 验证是否生效：
go env GOPROXY输出应严格匹配上述字符串
go mod init 后 go.sum 为空或 go mod tidy 不下载依赖
初始化后没依赖、go.sum 空、go mod tidy 无反应——通常不是命令问题，而是代码里没真正引用第三方包。
Go Modules 只在 import 语句实际存在且被编译器识别时才触发下载。注意：
- 确保
.go文件中有类似import "github.com/gin-gonic/gin"的语句（不是注释掉的，也不是字符串字面量） - 如果只是写了 import 但没在函数中使用，部分老版本 Go 会警告“imported and not used”，但不影响
go mod tidy行为；新版本（1.22+）已放宽该限制 -
go mod tidy必须在包含有效import的目录下运行，且当前目录是模块根目录（即有go.mod） - 若仍不生效，尝试加
-v参数：go mod tidy -v查看具体卡在哪一步
VS Code 中 gopls 报 “failed to load packages” 或补全失效
这不是编辑器问题，而是 gopls（Go 语言服务器）启动时依赖的模块环境没就绪。常见于刚新建项目、go.mod 刚生成但缓存未加载完。
别急着重装扩展，先做三件事：
- 确认终端里能正常执行
go list -m all—— 如果报错，说明模块本身有问题，编辑器必然同步失败 - 在 VS Code 中按
Ctrl+Shift+P→ 输入 “Go: Restart Language Server”，强制刷新状态 - 检查 VS Code 设置里是否禁用了
"go.useLanguageServer": true（应为true） - 首次打开项目时，右下角常有 “Installing tools…” 提示，务必等它完成，尤其
gopls和dlv；中途关闭窗口会导致工具残缺
真正容易被忽略的是：模块初始化和代理配置必须在写第一行 import 之前完成。很多人先写代码、再配环境，结果 go mod tidy 误判已有依赖而跳过下载，或者 gopls 缓存了错误状态，后续清理成本远高于一开始就对齐环境。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
