GO111MODULE=on 不自动创建 go.mod，因模块初始化需手动执行 go mod init；它仅改变依赖解析行为，无 go.mod 时会报错而非静默生成。
GO111MODULE=on 时 go 命令为何不自动创建 go.mod？
因为 go mod init 不是自动触发的——开启模块模式只改变依赖解析行为，不代替初始化动作。你在非模块路径下执行 go build 或 go list，会报错 go: cannot find main module，而不是默默建 go.mod。
实操建议：
- 首次使用模块，必须手动运行
go mod init <module-name>，模块名一般填你最终要发布的导入路径（如github.com/you/project） - 如果当前目录已有
go.mod，GO111MODULE=on才真正生效；否则它只是“准备就绪”，但无模块上下文可作用 - 别依赖 IDE 自动初始化——有些编辑器会在后台静默调用
go mod init，导致模块名错误（比如生成成project而非github.com/you/project），后续换机器或 CI 就会拉不到私有依赖
GO111MODULE=auto 和 off 的实际区别在哪？
GO111MODULE=auto 只在当前目录或父级存在 go.mod 时才启用模块模式；GO111MODULE=off 则彻底禁用，强制走 $GOPATH/src 旧路径逻辑，哪怕目录里有 go.mod 也视而不见。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 本地
GO111MODULE=auto，go run main.go正常，但 CI 环境未设该变量，默认 fallback 到off，结果找不到依赖，报cannot find package - 误设
GO111MODULE=off后，go get仍会把包下到$GOPATH/pkg/mod（因为go get默认走模块逻辑），但编译时却拒绝读取，造成缓存污染 -
go list -m all在off模式下直接报错go: modules disabled，不是空输出
为什么 GOPATH 下的项目设 GO111MODULE=on 反而出问题？
因为模块模式和 $GOPATH 是两套独立的依赖管理体系。当项目位于 $GOPATH/src/github.com/xxx/yyy 且启用 GO111MODULE=on，go 命令会忽略 $GOPATH/src 中的代码，转而从 $GOPATH/pkg/mod 加载版本化依赖——但你的本地修改（比如正在调试的 github.com/xxx/lib）不会自动反映进去。
使用场景与应对：
- 需要本地联调多个内部库？用
replace而不是关模块：go mod edit -replace github.com/xxx/lib=../lib
- 想临时退回到 GOPATH 模式快速验证？必须同时设
GO111MODULE=off并确保没go.mod，否则go会优先报错go: modules disabled by GO111MODULE=off, but go.mod exists -
GO111MODULE=on+$GOPATH并存本身不报错，但容易掩盖replace没生效、indirect依赖漏写等问题，CI 构建时才暴露
Go 1.16+ 是否还需要显式设置 GO111MODULE？
不需要。Go 1.16 起默认值已是 on，无论是否在 $GOPATH 内，只要目录含 go.mod 就启用模块；没有则按需提示初始化。但显式设 GO111MODULE=on 仍有价值：防止低版本 Go（如 1.13–1.15）环境因未设变量而 fallback 到 auto 出现不一致。
关键细节：
- Go 1.21+ 进一步移除了
GO111MODULE=off对go mod子命令的限制——即go mod download在off下也能跑，但go build依然拒绝模块感知 - Docker 多阶段构建中，基础镜像若为
golang:1.15，必须在Dockerfile里写ENV GO111MODULE=on，否则go build会因检测到/go是 GOPATH 而切回auto模式 - Windows 上通过
set GO111MODULE=on设置后，新起的 PowerShell 实例不继承——得用$env:GO111MODULE="on"或写入系统环境变量
最常被忽略的一点：GO111MODULE 是 shell 环境变量，不是 Go 源码里的配置项。它只影响当前 shell 会话下的所有 go 命令，改完不重启终端或重 source profile，就等于没改。
