go模块不支持多套环境依赖配置，因go.mod是全局唯一且静态解析的；可行方案是用go.work+replace实现开发环境依赖替换，或通过构建标签控制不同环境的实际编译依赖。
Go 模块本身不支持“多套环境依赖配置”的概念——go.mod 是项目级的、全局唯一的依赖声明，不能像前端 package.json 那样通过 devDependencies/dependencies 分离。所谓“一键切换”，本质是绕过 Go 原生机制，用外部手段模拟不同依赖组合。
为什么 go.mod 无法直接支持 dev/prod 两套依赖？
Go 的模块系统设计上就拒绝运行时或构建时动态替换依赖：所有 require 语句在 go.mod 中都是静态解析的，go build 不识别环境变量或条件块。即使你写两个 go.mod.dev 和 go.mod.prod，Go 工具链也只认 go.mod。
-
go mod不提供类似 npm 的--only=dev或 pip 的-r requirements-dev.txt机制 -
replace和exclude是全局生效的，不能按环境开关 -
GOOS/GOARCH影响的是构建目标，不是依赖选择
可行方案：用 go.work + replace 实现本地多环境依赖隔离
如果你需要在开发阶段临时替换某个依赖（比如用本地调试版 mylib 替代远程 v1.2.0），go.work 是目前最干净的方式。它不修改 go.mod，也不污染 vendor，且仅对当前工作区生效。
- 在项目根目录执行
go work init创建go.work - 添加本地模块替代：
go work use ./local-mylib - 此时
go build会自动使用./local-mylib而非go.mod中声明的版本 - 要切回远程版本？删掉
go.work或注释掉use行，再go mod tidy
注意：go.work 只影响本地开发，CI/CD 中不会生效——所以它适合“开发/调试”环境切换，不适合“staging/prod”部署差异。
生产环境依赖差异：靠 vendor + 构建标签（build tags）间接控制
真正需要区分环境依赖的场景（比如 prod 用 prometheus/client_golang，dev 用 debug/pprof），得靠代码层面的条件编译，而不是依赖列表本身。
- 把不同环境的依赖都写进
go.mod，但只在对应文件中 import - 用构建标签隔离：比如
//go:build prod的metrics_prod.go引入监控 SDK，//go:build dev的debug_dev.go引入 pprof - 构建时指定：
go build -tags=prod或go build -tags=dev -
go mod vendor会把所有依赖拉下来，但实际链接进二进制的只有被构建标签启用的那些
这个方案的关键是：依赖列表不变，变的是哪些依赖被实际编译进去——这才是 Go 原生支持的“环境差异化”路径。
容易踩的坑：别碰 GOPROXY + 环境变量组合幻想
有人试图用 GOPROXY=https://proxy.golang.org（生产）和 GOPROXY=http://localhost:8080（开发）来切换依赖源，这是危险的：
- 代理地址只影响下载行为，不改变
go.mod中的版本锁定 - 如果本地私有代理返回了不同版本的 zip 包，会导致
go.sum校验失败，构建直接中断 -
GO111MODULE=on下，GOPROXY不影响模块解析逻辑，只影响 fetch 路径
真正需要私有依赖管理，应该用 replace + 私有仓库 URL，或者用 go.work 指向本地路径——而不是寄希望于代理“偷偷换包”。
