go.mod是Go依赖隔离的唯一边界，Go仅依据当前工作目录下的go.mod文件确定依赖视图，与目录位置、环境变量或虚拟环境无关；模块路径、主版本号和go.mod位置三者共同构成隔离锚点。
go.mod 是依赖隔离的唯一边界
Go 项目不靠目录位置、shell 环境变量或虚拟环境来隔离依赖，只认当前工作目录下的 go.mod 文件。只要你在项目根目录下执行 go build 或 go run，Go 就自动加载该文件声明的依赖视图，和你当前 PATH 里有没有其他 Go 二进制、GOPATH 设没设、甚至是不是在某个 IDE 的 workspace 里，统统无关。
常见错误现象：在子目录（如 /cmd/server）里运行 go run main.go 报 no required module provides package —— 因为那里没有 go.mod，Go 不知道该用哪个依赖版本；正确做法是回到项目根目录操作，或确保子目录也初始化为独立模块（需显式 go mod init 并调整 import 路径）。
- 每个
go.mod对应一个逻辑模块，模块路径（module github.com/user/proj）必须全局唯一，否则go get会混淆 -
go.sum不参与隔离逻辑，只做校验；删掉它不会破坏隔离，但下次go build会重新生成并可能拉取不同 commit - 跨目录执行命令时（如
go run ../main.go），Go 仍以当前 shell 路径为准找go.mod，不是以目标文件所在路径
主版本号变化必须体现在模块路径中
Go 不允许同一模块路径（如 github.com/org/lib）同时存在 v1 和 v2 版本——它会强制你把 v2+ 的路径写成 github.com/org/lib/v2。这不是命名习惯，是硬性规则；否则 go mod tidy 会报错，或静默降级到 v1。
典型场景：你引入了两个依赖，A require github.com/some/log v1.5.0，B require github.com/some/log v2.1.0。若后者没带 /v2 后缀，Go 会认为它是非法发布，拒绝解析；只有当 B 的 go.mod 写的是 github.com/some/log/v2 v2.1.0，才能与 A 共存。
立即学习“go语言免费学习笔记（深入）”；
- v0.x 和 v1 版本可省略路径后缀（
/v1非强制），但 v2+ 必须显式带/v2、/v3等 - 本地开发时用
replace指向未打 tag 的分支，路径也得匹配目标模块的主版本路径，否则替换失效 - CI/CD 中若用
go install安装工具（如golangci-lint），它的依赖版本不受你项目go.mod控制——这是另一个隔离层，别误以为“我锁死了依赖，工具就一定兼容”
最小版本选择（MVS）不是选最低，而是选满足所有约束的最早兼容版本
go mod tidy 或 go build 时触发的 MVS 算法，本质是在所有 require 声明的版本范围内，挑一个能同时满足全部依赖的版本。它优先选语义化版本中 PATCH 最小的那个，但前提是 MINOR 和 MAJOR 也得兼容。
比如你的 go.mod 直接 require A v1.3.0，而 A 依赖 B v1.2.0，另一依赖 C require B v1.4.0，那么最终选的是 B v1.4.0 —— 因为 v1.2.0 不满足 C 的约束，而 v1.4.0 向下兼容 v1.2.0，所以它就是“满足全部约束的最早版本”。
- MVS 不关心你本地
go.sum里有没有更老的版本记录；只要远程有更新的 patch，且满足约束，就可能升级 -
exclude和replace会绕过 MVS，但仅限于显式声明的模块；它们不改变其他依赖的版本选择逻辑 - 执行
go list -m all可看到实际选用的每个模块版本，比看go.mod更真实——后者只写“最小要求”，前者才是最终结果
多模块仓库里的 go.mod 互不继承
一个 Git 仓库里放多个 go.mod（比如 /api、/cli、/internal/pkg 各自初始化），它们之间没有父子关系。每个 go.mod 独立解析依赖，即使路径都在同一个 repo 下，也不会自动共享或传递版本约束。
容易踩的坑：你在根目录 go.mod 里 replace 了某个库，但 /cli/go.mod 没写这条，那么 cd cli && go build 就不会生效——replace 只作用于声明它的那个模块。
- 主模块（含
go.mod且被go build当前目录匹配的那个）的replace对子模块无效；要全局生效，得在每个子模块的go.mod里重复写 - 用
go work init创建工作区可统一管理多个模块，但它只是让go命令一次处理多个go.mod，并不合并依赖视图；各模块仍保持独立版本选择 - 如果子模块被主模块直接 import（如
import "example.com/repo/cli"），那它的代码会被主模块的构建过程包含，但它的go.mod仅用于校验自身依赖完整性，不影响主模块的 MVS 结果
