Go模块下载不支持租户隔离，因其是构建前静态解析过程，租户共享同一go.mod/go.sum；强行隔离会破坏一致性、复现性与缓存效率，正确做法是通过条件编译、运行时数据隔离和构建环境净化实现租户差异化。
Go模块依赖下载本身不支持租户级隔离——go mod download 操作面向全局 GOPATH/GOPROXY，没有租户上下文概念，强行“隔离下载”等于在构建阶段伪造模块路径或污染缓存，反而引入供应链风险。
为什么不能为每个租户单独运行 go mod download
模块下载不是运行时行为，而是构建前的静态依赖解析过程。租户之间共享同一份源码、同一套 go.mod 和 go.sum，不存在“某租户需要 github.com/foo/bar@v1.2.0，另一租户需要同名包 v1.3.0”的合法场景——这违反 Go 的模块一致性模型。试图按租户拆分 go.sum 或重写 replace 规则，会导致：
- CI/CD 构建结果不可复现：不同租户构建出的二进制可能链接不同版本的间接依赖
-
go list -m all输出不一致，破坏依赖图谱审计能力 - proxy 缓存击穿：每个租户都触发独立 fetch，丧失 GOPROXY 共享优势
真正要隔离的是模块使用上下文，不是下载动作
租户隔离发生在运行时数据层（如 schema、tenant_id）、配置加载（如 config/tenant_a.yaml）和权限控制（如 JWT scope），而非编译期依赖。安全边界应设在：
- 模块来源可信性：强制启用
GOPROXY=https://proxy.golang.org+GOSUMDB=sum.golang.org，禁用insecure代理或本地文件路径 - 依赖锁定严格性：每次
go mod tidy后必须提交更新的go.sum，禁止go get直接修改生产依赖 - 构建环境净化：CI runner 使用干净容器，不复用
$GOCACHE或$GOPATH/pkg/mod，避免跨项目缓存污染
若租户需差异化功能，靠条件编译而非隔离下载
例如租户 A 需集成支付 SDK，租户 B 不需要——这不是靠“只给 A 下载该模块”，而是：
- 将支付逻辑封装为可选插件模块，如
github.com/yourorg/payment/stripe - 主程序通过
//go:build tenant_stripe标签控制是否链接该模块 - 构建时指定
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -tags tenant_stripe -o app-a ./cmd - 各租户对应不同构建命令和二进制产物，但共用同一套
go.mod和下载缓存
模块下载环节本就不该感知租户；把隔离压力转嫁到构建、部署和运行时，才是符合 Go 工程实践的解法。最危险的操作，是让运维手动维护 N 套 go.mod 或在 CI 中动态 patch 依赖——那不是隔离，是埋雷。
