全局配置被覆盖是因误用init()、包级变量或单例模式导致共享状态被多次修改。应避免init()中初始化配置，改用显式函数调用；采用依赖注入替代全局变量；命令行参数使用独立flagset隔离。
为什么全局配置会被覆盖？
Go 项目中所谓“全局配置覆盖冲突”，通常不是 Go 语言本身的机制问题，而是开发者误用 init()、包级变量或单例模式导致的副作用。典型场景是：多个模块（尤其是非 main 包）在 init() 中调用同一配置初始化函数（如 log.SetOutput()、http.DefaultClient.Timeout 或自定义的 Config.Load()），而这些函数修改的是共享的全局状态。一旦执行顺序不可控（比如测试时 go test 自动注入的 flag.Parse() 提前触发了某包的 init()），配置就被提前覆盖，后续逻辑读到的就是错的状态。
避免 init() 中做配置初始化
这是最直接有效的预防点。只要不把配置加载逻辑塞进 init()，就能切断隐式执行链。
- 把配置加载封装成显式函数，例如
config.LoadFromEnv()或db.Init(cfg)，由main()或测试 setup 显式调用 - 禁止在任何非
main包的init()里调用flag.Parse()、log.SetFlags()、net/http.DefaultTransport修改等操作 - 若必须兼容旧代码，可用
sync.Once包裹初始化逻辑，但前提是该逻辑本身是幂等的——否则仍会因首次调用者不同而写入不同值
用依赖注入替代全局单例
真正解耦的关键不是“怎么保护全局变量”，而是“别用全局变量”。所有需要配置的组件（日志、DB、HTTP 客户端）应通过构造函数或接口传入，而非从包级变量里取。
- 定义接口，如
type Logger interface { Info(...interface{}) }，让业务逻辑只依赖接口，不依赖log包本身 - 在
main()中构建具体实现（如zerolog.New(os.Stdout)），然后传给各服务实例：svc := NewService(logger, db) - 测试时可轻松注入 mock 实现，彻底避开真实全局状态干扰
- 避免使用类似
package config导出var Global *Config的模式；改为func NewConfig() *Config+ 显式传递
flag 参数冲突时用 FlagSet 隔离
当多个子包都定义命令行参数（尤其在测试或 CLI 工具中），flag.Parse() 的全局性会导致参数被多次解析或覆盖。解决方案是放弃默认 flag.CommandLine，改用独立 flag.FlagSet。
- 每个需要参数的模块创建自己的
fs := flag.NewFlagSet("module-name", flag.ContinueOnError) - 用
fs.String()、fs.Int()等注册参数，再调用fs.Parse(os.Args[1:])（注意跳过os.Args[0]） - 主程序统一解析后，把解析结果结构体传给各模块，而不是让模块自己去读全局
flag - 测试中可传入伪造的
[]string{"-debug", "-port=8080"}给fs.Parse()，完全隔离环境
真正麻烦的从来不是“怎么修覆盖”，而是“谁在没打招呼的情况下改了它”。只要配置不靠隐式执行、不靠包级变量、不靠全局 flag，冲突就自然消失。剩下要做的，只是确保每个模块对自己的依赖负责，而不是指望别人别碰全局状态。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
