go语言单机多项目共存依赖每个项目根目录的go.mod文件，其位置决定模块边界；go run报错多因工作目录与go.mod不匹配，需确保终端路径与go.mod所在目录一致，并强制启用go111module=on。
Go 语言单机多项目共存，根本不需要“隔离环境”或“虚拟空间”，靠的是每个项目根目录下独立的 go.mod 文件 —— 没它，就不是 Go Module 项目；有它，且位置对，就能各自运行、互不干扰。
为什么 go run 报错 “cannot find module providing package”
这不是依赖没下载，而是当前工作目录和 go.mod 不匹配。Go 命令只认当前目录（或向上最近一层）有没有 go.mod，找不到就退化成 GOPATH 模式，然后失败。
- 用
pwd（macOS/Linux）或cd（Windows）确认终端当前路径，必须和go.mod所在目录完全一致 - VSCode 打开项目时，必须「打开文件夹」，而不是双击
main.go—— 否则 IDE 不会加载模块上下文，gopls无法解析 import - GoLand 如果识别异常，右键项目根目录 → “Mark Directory as” → “Sources Root”
- 别在父目录下执行
go run ./...：如果子目录有独立go.mod，它会被忽略，导致导入路径解析错误
多个 go.mod 共存时，如何避免依赖互相污染
Go 不会自动把同级或子目录下的 go.mod 当作“子模块”纳入主构建 —— 它们只是独立模块。所谓“污染”，其实是人为跨模块 import 或没管好 replace。
- 每个
go.mod必须位于自己模块的根目录，且模块路径（module github.com/user/project）要真实可路由，不能随便写myapp - 子模块（如
./pkg/util）若被主模块引用，主模块go.mod中需显式replace github.com/user/util => ./pkg/util，否则go build会去远程拉取 -
go mod tidy必须在每个模块根目录单独执行 —— 主模块 tidy 不会更新子模块的go.sum，CI 构建前应逐个cd进去 tidy -
go clean -modcache是清全局缓存，对多项目隔离无实质帮助；真正隔离靠的是每个模块自己的go.sum和本地replace状态
GO111MODULE=auto 为什么在某些目录下失效
这个默认值只在“不在 GOPATH/src 下”才开启 Module；一旦你误把项目放在 $GOPATH/src/xxx 里，Go 就自动关掉 Module，回到老式 GOPATH 模式 —— 这是绝大多数人踩坑的根源。
- 永远设为
go env -w GO111MODULE=on，强制启用，一劳永逸 -
go env GOPATH只用于 legacy 场景，新项目完全不用关心它的值；但如果你的GOROOT为空，说明 PATH 没导对，不是没装 Go - PowerShell 和 CMD 的环境变量不共享，
go env结果必须和你执行go run的终端一致 - Mac/Linux 手动解压安装 Go 后，务必把
/usr/local/go/bin（或你解压的实际 bin 路径）加进~/.zshrc或~/.bash_profile，再source
真正容易被忽略的点是：go.mod 文件的存在位置，决定了整个项目的模块边界 —— 它不是配置项，是 Go 工具链识别项目的唯一信号。放错一层目录，就等于换了一个项目。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
