Go Modules不支持默认多版本共存，仅能通过/v2路径分隔、独立go.mod构建边界及replace灰度控制实现逻辑多版本共存，核心依赖模块路径唯一性与导入隔离。
多版本并行开发不是 Go Modules 的默认能力，它不能像 Python 的 virtualenv 或 Java 的 classloader 那样为不同子模块加载同一包的不同版本。你真正能做的，是通过结构隔离 + 版本路径分隔 + 构建边界控制，让“逻辑上多个版本共存”成为可管理、可验证、可灰度的工程实践。
用 /v2 路径分隔实现真正的多版本共存
Go 只认模块路径（module path）作为唯一标识。github.com/user/lib 和 github.com/user/lib/v2 是两个完全独立的模块，可同时存在于同一构建中。
- 必须满足语义化版本规范：v2.0.0+ 发布时，
go.mod中的module行必须显式包含/v2，例如module github.com/user/lib/v2 - 如果只改 tag 不改路径（如打 v2.0.0 但
module还是github.com/user/lib），Go 会当作+incompatible版本处理，无法与 v1 共存，且极易引发类型不匹配 - v1 和 v2 的 import 路径必须不同：
import "github.com/user/lib"vsimport "github.com/user/lib/v2"，编译器不会混淆 - 常见错误：升级时漏改
go.mod中的 module 路径，导致go list -m all显示两个版本但实际只加载了 v1 —— 因为 v2 没被任何 import 引用
用独立 go.mod 划分构建边界，避免版本污染
一个仓库里多个 go.mod 文件（如 /cmd/frontend、/cmd/backend、/pkg/core），本质是多个独立模块。它们各自 require 不同版本，只要不被同一个 go build 命令统一导入，就不会触发 MVS（最小版本选择）强制统一。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 关键限制：不能在
frontend中import backend，否则构建时会合并依赖图，MVS 就会介入 - 推荐做法：用 API 协议（HTTP/gRPC）或接口抽象解耦，而非直接 import 包；每个命令目录单独
go build ./... -
go mod graph查不到跨模块的依赖关系——因为它们根本不在同一个构建图里 - CI 中需分别运行
go build ./cmd/frontend和go build ./cmd/backend，不能go build ./...一锅端
用 replace + 本地 fork 控制灰度升级节奏
replace 不是解决冲突的终点，而是给新旧版本争取共存时间窗口的杠杆。它让你在不改上游、不等发布的情况下，先跑通 v2 的核心路径。
- 示例：把主模块的
github.com/old/lib替换为本地兼容分支：replace github.com/old/lib => ./forks/lib-v2-compat - 必须配合
go mod tidy：replace 后要重新计算依赖，否则间接依赖仍可能拉入旧版 - 严禁提交带本地路径的 replace（如
./local-fix）到主干；上线前必须换成远程 commit hash 或 tagged version - 容易踩坑：replace 后没跑
go test ./...，结果只测了主模块，没覆盖被 replace 影响的间接依赖路径
最易被忽略的一点：多版本并行不是靠“同时存在”来降低风险，而是靠“构建隔离”和“导入隔离”来控制影响范围。一旦某个 import 语句跨过路径或模块边界，Go 就会强制收敛——这时候你面对的不是多版本共存，而是明确的编译失败，得立刻决策：升、降、还是拆。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
