Go111MODULE=on 时 go mod 强制启用，不看 vendor/
只要环境变量 GO111MODULE=on，无论项目是否在 $GOPATH 内，也无论有没有 go.mod 文件，所有 go 命令（go build、go run、go test 等）都会进入模块模式。此时 vendor/ 目录被完全忽略——哪怕它存在且内容完整，也不会被加载。
常见错误现象：go build 报错 cannot load xxx: cannot find module providing package xxx，但明明 vendor/ 里有这个包。原因就是 GO111MODULE=on 下 vendor 已失效，必须靠 go.mod 声明依赖。
- 如果要保留 vendor，必须设为
GO111MODULE=off或auto且项目在$GOPATH/src下（已不推荐） -
GO111MODULE=on是 Go 1.16+ 默认行为，不用显式设置，但显式设成on可避免因工作目录位置导致的意外降级 - CI/CD 中建议固定设为
GO111MODULE=on，防止本地开发和构建环境行为不一致
GO111MODULE=auto 的真实触发逻辑
GO111MODULE=auto 不是“智能判断”，而是简单规则：当前目录或任意父目录存在 go.mod 文件 → 启用模块；否则退回到 GOPATH 模式（即 GO111MODULE=off 行为）。
容易踩的坑：
立即学习“go语言免费学习笔记（深入）”；
- 项目根目录没
go.mod，但上层某个目录（比如用户家目录）不小心建了go.mod→ 整个子树都被强制进模块模式，可能引发意料外的依赖解析 - 执行
go mod init后没提交go.mod，团队成员 clone 下来首次运行go build就会 fallback 到 GOPATH 模式，行为不一致 - Windows 下路径大小写不敏感，但
go工具链对go.mod文件名大小写敏感，Go.Mod不会被识别
向后兼容的关键不是开关，是 go.sum 和 replace
Go 语言本身没有“运行时兼容开关”，模块兼容性靠的是 go.mod 中声明的依赖版本 + go.sum 校验 + 必要时用 replace 临时覆盖。所谓“向后兼容处理”，本质是让新版本代码能跑在旧模块约束下，或让旧代码适配新依赖。
典型场景：
- 升级一个间接依赖（比如
golang.org/x/net）导致编译失败，但主依赖还没发新版 → 在go.mod加replace golang.org/x/net => golang.org/x/net v0.7.0 - 私有仓库迁移后 URL 变了，但老模块还在引用旧地址 → 用
replace old.example.com => new.example.com -
go.sum不该手动改，但 CI 报checksum mismatch时，应先确认是否有人绕过go mod直接改了vendor/或go.mod，而不是删go.sum了事
Go 1.21+ 的隐性变化：GO111MODULE 不再影响 go install 的路径解析
从 Go 1.21 开始，go install 命令不再读取 GO111MODULE 来决定是否走模块模式，而是统一按模块方式解析路径。这意味着即使设为 GO111MODULE=off，go install example.com/cmd/foo@latest 仍会尝试走代理下载并缓存模块，而不是去 $GOPATH/bin 找本地源码。
影响明显的行为：
-
go install ./cmd/...在GO111MODULE=off下不再生效，会报错go install: no modules specified - 想用传统 GOPATH 方式安装本地命令？必须显式加
@latest或指定 commit，例如go install ./cmd/foo@v0.1.0 - 很多旧脚本里写的
GO111MODULE=off go install ./...在 Go 1.21+ 上直接挂掉，这是最常被忽略的 breaking change
GO111MODULE=off，有人用 auto，还都往同一个 go.mod 提 PR —— 这时候 require 行顺序、indirect 标记、甚至空行都会变成 merge 冲突点。 
