Go modules 不支持同一模块多版本共存，强制统一为一个版本；可通过修改 module path（如 /v2）实现逻辑隔离，或用 go.work 进行本地开发协同。
Go modules 本身不支持同一模块多版本共存
Go 的 go.mod 文件中，每个模块路径（如 github.com/gin-gonic/gin）至多只能有一个 require 条目，且 Go 工具链在构建时会强制选择一个**统一版本**（通过最小版本选择算法 MVS）。你无法像 Python 的 venv + 多 requirements.txt 或 Node.js 的嵌套 node_modules 那样，在同一构建中同时加载 v1.9.1 和 v1.10.0 的同一个模块。
常见误解场景：
– 项目 A 依赖 lib/x v1.2.0，项目 B 依赖 lib/x v1.5.0，但两者被一起 import 到主模块 → Go 会升版或降版统一为一个兼容版本（如 v1.5.0），并报错提示不兼容时拒绝构建；
– 试图在 go.mod 中写两行 require github.com/foo/bar v1.2.0 和 require github.com/foo/bar v1.3.0 → go mod tidy 会自动删掉其中一行，并警告重复声明。
替代方案：用 module path 分割实现逻辑“多版本”
真正可行的隔离方式是让不同版本“看起来是不同模块”，即修改模块路径（module path），使其在 Go 看来是独立实体。这是官方推荐的向后不兼容大版本演进方式（如从 v1 到 v2）：
- 版本号必须体现在 module path 末尾，例如：
github.com/org/pkg的 v2 版本应声明为module github.com/org/pkg/v2，并在 import 时显式写import "github.com/org/pkg/v2"； - v0/v1 版本可省略路径后缀（
github.com/org/pkg默认代表v0.x或v1.x），但一旦发布v2+，就必须带/v2、/v3等后缀； - 同一代码仓库可通过多分支 + 多
go.mod实现多 path 共存（如main分支维护v1，v2分支维护v2模块）； - 注意：不是所有库都严格遵守此规范——若某库发布了
v2.0.0却没改go.mod中的 module path，Go 仍视其为v1，此时你无法安全共存。
go.work：跨多个 module 的临时协同开发
当你需要**同时修改两个有依赖关系的本地模块**（比如正在开发 mylib，而 myapp 依赖它），又不想反复 go mod edit -replace，可用 go.work 文件做工作区管理：
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。
go 1.18
use (
./myapp
./mylib
)
启用后：
– 在 myapp 中 import "github.com/you/mylib"，实际会使用本地 ./mylib 目录下的代码，而非 go.sum 记录的远程版本；
– mylib 自身的 go.mod 仍独立，可有自己的依赖和版本；
– 这不是“运行时多版本共存”，而是编译期的源码级覆盖，仅适用于开发调试；
– 生产构建必须移除 go.work，确保所有依赖走正式版本发布流程。
容易被忽略的关键点
– replace 和 exclude 只影响当前模块的构建，不会改变被依赖方的语义；
– go list -m all 显示的是最终解析出的**扁平化版本列表**，它掩盖了路径差异 —— 你要靠 go list -f '{{.Path}} {{.Version}}' all 才能看出 github.com/foo/bar 和 github.com/foo/bar/v2 是两个条目；
– 如果第三方库未按语义化版本 + 路径分隔发布 v2+，你无法通过标准机制安全引入它的多个大版本；
– Go 没有类似 Rust 的 “feature flags” 或 Java 的 “classloader 隔离”，包级符号全局唯一，哪怕路径不同，只要导入了同一底层 package（如都 import "net/http"），就共享同一份类型定义和变量实例。
