go模块不造成全局变量污染，但包级变量、init()函数和跨模块共享状态会引发实际污染；go.mod仅控制依赖版本与加载路径，不干预运行时内存空间，无法隔离共享的包级变量或单例。
Go 模块本身不造成全局变量污染，但包级变量、init() 函数和跨模块共享的全局状态会引发实际污染——这种污染不是 go mod 机制导致的，而是开发者把可变状态“藏”在模块边界之外的结果。
为什么 go.mod 不能阻止全局变量污染
go.mod 只控制依赖版本解析和源码加载路径，它不干预运行时行为。即使两个模块用完全不同的 github.com/a/log 版本，只要它们都读写同一个包级 var logger *zap.Logger，就仍会互相干扰。
- 模块隔离的是“代码来源”，不是“内存空间”
- 不同模块导入同一包（如
net/http）时，共享该包所有包级变量 -
replace或go.work改变路径，但不改变变量生命周期或作用域 - 常见误判：以为
go mod tidy能清理全局状态——它只清理go.sum和未引用依赖
哪些全局变量最容易跨模块污染
真正危险的不是显式定义的 var，而是那些“看起来无害”的隐式共享状态：
-
http.DefaultClient、http.DefaultServeMux：被多个模块直接复用，超时/拦截器/重试策略互相覆盖 -
rand.Seed()或未加锁的rand.NewSource()：影响所有调用rand.Intn()的模块 - 包级
sync.Map或map[string]interface{}：尤其在工具包（如pkg/cache）中被多个业务模块 import 后共用 -
log.SetOutput()或log.SetFlags()：修改后影响整个进程日志格式 - 第三方库的单例（如
jaeger.NewTracer()返回全局实例）：若未封装为依赖注入接口，就会被多处强绑定
如何验证你的模块是否已被全局污染
别靠猜。用最小可复现测试快速定位：
- 写一个空
main.go，仅 import 你怀疑的模块 A 和 B，然后go build -gcflags="-m" main.go看是否有意外的包级变量逃逸到堆上 - 在测试中并发调用两个模块的导出函数，观察是否出现
fatal error: concurrent map writes或非预期返回值 - 用
go run -race运行集成测试，race detector 会直接标出跨模块读写的包级变量位置 - 检查
go list -f '{{.Deps}}' your-module输出里是否有重复出现的底层包（如多次出现golang.org/x/net/context），说明可能存在间接共享
真正有效的隔离手段只有两种
不是加 go mod vendor，也不是换 GOPROXY——那些只解决下载问题。要切断污染链，必须从运行时结构入手：
- 把所有可变状态（logger、client、cache、config）从包级移到结构体字段，并通过构造函数传入；例如把
func DoWork() error改成type Worker struct{ client *http.Client }+func (w *Worker) DoWork() error - 禁用所有
init()中的副作用：数据库连接、环境变量读取、日志初始化全部移至显式NewXXX()函数，由调用方控制时机 - 对必须共享的底层资源（如数据库连接池），用
sync.Once+atomic.Value封装，确保首次初始化后不可再改；避免用裸var db *sql.DB - 测试时用
os.Setenv()+defer os.Unsetenv()控制环境变量，而不是依赖启动时一次读取的包级config变量
最常被忽略的一点：模块间传递指针类型（如 *sql.DB）不等于隔离——它只是把污染从“包级”下沉到了“调用链级”。真正的隔离，是让每个模块对自己的状态有完整所有权，不依赖外部任何可变上下文。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
