go模块系统不支持租户级依赖隔离，因其设计为module粒度：一个go.mod对应一套版本树，无法按租户动态切换；必须通过物理隔离（各租户独立module目录）或运行时沙箱实现，前者更可靠。
为什么 go mod 本身不支持租户级依赖隔离
Go 的模块系统设计上是项目（module）粒度的，go.mod 文件作用于整个 module 根目录，所有 .go 文件共享同一套 require 和 replace 规则。多租户场景下若强行共用一个 module，会出现：不同租户依赖同一库的不同版本（如 github.com/example/lib v1.2.0 vs v2.5.0），而 go build 只能选一个版本——直接冲突或静默降级。
这不是 bug，是 Go 模块模型的明确约束：一个 module 对应一个 go.sum、一套 resolved 版本树，无法按子目录或运行时上下文动态切换。
可行路径只有两种：物理隔离 or 运行时沙箱
没有“优雅的中间方案”。要么让每个租户拥有独立构建单元，要么在运行时绕过编译期依赖绑定。实践中前者更可靠：
- 为每个租户生成独立的 module 目录（如
/tenants/a/、/tenants/b/），各自维护go.mod和vendor/ - 构建时用
GO111MODULE=on GOPROXY=... go build -mod=readonly，确保不意外写入或修改依赖 - 禁止跨租户复用
main包；租户代码必须以package main起始，且不能 import 其他租户的 internal 包
运行时沙箱（如基于 plugin 或 WASM）代价高、调试难、Go 官方已标记 plugin 为“仅 Linux”且不保证 ABI 稳定，不建议生产使用。
replace 和 exclude 在租户场景中极易误用
常见错误是试图用 replace github.com/common/lib => ./tenants/shared-lib 统一管理基础组件——这会让所有租户强制使用同一份源码，失去版本隔离能力。更糟的是，exclude 会彻底移除某版本，导致其他租户的 go.sum 校验失败。
正确做法是：
- 每个租户的
go.mod单独require所需版本，不依赖全局 replace - 若需统一 patch，用
go mod edit -replace在 CI 构建前注入，而非写死在主go.mod - 绝对不用
exclude——它不解决多版本共存，只掩盖问题
CI/CD 中必须校验租户 module 的独立性
租户代码提交后，CI 需逐个进入其目录执行：
-
go mod download确认所有依赖可拉取 -
go list -m all | grep -v 'std$'输出实际解析版本，比对是否与预期一致 -
go build -o /dev/null ./...验证无跨租户 import（如import "tenants/b/utils"应被拒绝）
最容易被忽略的是：租户 module 的 module 声明必须唯一（如 module tenants/a），否则 go mod tidy 会把依赖合并到父 module，瞬间瓦解隔离。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
