go 1.16+默认启用模块模式，但go111module非on、go mod init位置错误、import路径不匹配模块名、goproxy与git凭据配置不当、vs code环境变量覆盖等均会导致模块命令失败。
Go 1.16 之后模块化（Go Modules）已是默认模式，GOROOT 和 GOPATH 不再决定项目位置，但环境变量配置不当仍会导致 go mod 命令报错、依赖拉取失败或本地包无法识别。
go version 输出正常但 go mod init 失败？检查 GO111MODULE 状态
即使 go version 能正确输出，go mod init 仍可能提示 “no modules found” 或静默跳过生成 go.mod —— 这通常是因为模块模式被关闭。
-
GO111MODULE默认值在 Go 1.16+ 是on，但若你手动设为off或在GOPATH/src下执行命令，Go 会回退到旧的 GOPATH 模式 - 运行
go env GO111MODULE查看当前值；非on时，执行go env -w GO111MODULE=on永久启用 - 临时覆盖可用
GO111MODULE=on go mod init example.com/myapp，适合 CI 或多版本共存场景
go mod init 后 import 本地 internal 包报错：路径必须匹配模块名
Go 模块对导入路径校验严格，import "myproject/internal/user" 报错 “module myproject not found” 并非路径不存在，而是模块根目录未被识别为该模块的起点。
- 确保
go mod init在项目根目录执行，且该目录下有main.go或其他 Go 文件 - 模块名（如
example.com/myapp）仅用于版本管理和远程导入，本地import语句中的路径必须以模块名为前缀，例如：import "example.com/myapp/internal/user" - 不要用相对路径或
./internal/user—— Go 不支持这种写法
go get 无法拉取私有 Git 仓库？配置 git config 与 GOPROXY 协同生效
当 go get git.example.com/internal/lib 提示 “unknown revision” 或 404，问题常出在认证或代理策略冲突，而非网络连通性。
- 先确认 Git 凭据可用：
git ls-remote https://git.example.com/internal/lib.git能成功返回 ref 列表 - 若使用 SSH，需设置
git config --global url."git@git.example.com:".insteadOf "https://git.example.com/" -
GOPROXY若设为https://proxy.golang.org,direct，私有域名会被跳过代理；但若设为direct单独值，则所有请求绕过代理，此时 Git 凭据必须全局有效 - 推荐组合：
go env -w GOPROXY="https://proxy.golang.org,direct"+git config适配私有源
vscode 中 go mod tidy 报错 “cannot find module providing package”？别忽略 .vscode/settings.json 的隐式覆盖
终端里 go mod tidy 成功，但 VS Code 自动触发时失败，大概率是编辑器读取了项目级 .vscode/settings.json 中的 "go.toolsEnvVars" 覆盖了 shell 环境。
- 检查该文件是否设置了
GOROOT、GOPATH或GO111MODULE—— 错误值会直接干扰模块解析 - VS Code 的 Go 插件默认使用
go命令所在路径推导GOROOT，手动指定反而容易出错；建议删掉go.toolsEnvVars中所有 Go 相关变量 - 重启 VS Code 后按
Ctrl+Shift+P→ “Go: Restart Language Server”，避免缓存残留
模块化不是开关，而是一套路径、命名和工具链协同约束的体系。最常被忽略的是：模块名不是“随便起的”，它决定了所有 import 路径的合法性；而 go mod 命令的执行位置，比你想象中更关键——差一层目录，就可能从模块模式退回到 GOPATH 模式。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
