go语言中不存在模块级全局变量冲突，变量作用域天然受限于包名；所谓“冲突”实为跨包误用可导出变量或多个包定义语义不同的同名包级变量所致，根本原因是作用域滥用而非模块问题。
全局变量冲突根本不是模块问题，而是作用域滥用
Go 里没有“模块级全局变量冲突”这种事——var 声明在包（package）内，作用域天然受限于包名。所谓“冲突”，90% 是以下两种情况之一：跨包误用可导出变量，或多个包各自定义同名但语义不同的包级变量，然后被同一处代码 import 后直接调用，导致行为错乱。
比如你在 pkgA 和 pkgB 都声明了 var Config *Config，又在 main.go 里同时 import 它们并写 pkgA.Config = ...、pkgB.Config = ... ——这不是模块冲突，是设计失当：两个包不该共享同一配置实例，也不该暴露可变的顶层变量。
避免跨包共享可变全局状态
只要不把可变状态暴露成 exported 变量（首字母大写），就不可能被其他包意外修改。真正安全的做法是：
- 所有包级变量用小写开头，如
var config *config，仅限本包内部使用 - 若需对外提供配置，返回只读副本或封装为方法，例如
func GetConfig() *Config，内部返回config的深拷贝或不可变视图 - 绝不写
var DB *sql.DB这种可导出变量；改用func NewDB(...) (*sql.DB, error)或依赖注入方式传入 - 如果必须初始化一次（如日志句柄），用
sync.Once+ 小写变量封装，不导出句柄本身
多模块项目中“同名包变量”的实际风险
当你有多个 module（比如 github.com/org/core 和 github.com/org/api），它们各自有个 utils 包，都定义了 var ErrTimeout error ——这完全合法，不会冲突。Go 编译器按完整 import 路径区分，core/utils.ErrTimeout 和 api/utils.ErrTimeout 是两个独立符号。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
真正危险的是：
- 两个模块都
import "github.com/org/shared"，而这个 shared 模块暴露了可变全局变量，结果 A 模块改了它，B 模块读到脏值 - 用
replace把不同版本的同一模块指向本地路径，但本地路径下包结构没统一（比如一个用shared/v1，另一个用shared），导致编译器加载两份同名包，变量重复初始化 - 测试时用
go test ./...扫描所有子目录，某些init()函数里偷偷初始化了全局状态，互相干扰
替代方案：用结构体封装 + 显式传递
几乎所有需要“全局上下文”的场景，都可以用更可控的方式替代：
- HTTP handler 中不要依赖
var ctx *Context，改用闭包绑定：router.GET("/user", handleUser(ctx))，其中handleUser返回func(http.ResponseWriter, *http.Request) - CLI 命令逻辑里避免
var rootCmd = &cobra.Command{...}直接赋值，改为func newRootCmd(cfg Config) *cobra.Command，把配置作为参数传入 - 数据库迁移、定时任务等后台逻辑，统一接收一个
App结构体指针，里面聚合所有依赖项，而不是从各处零散取全局变量
最易被忽略的一点：即使你写了完美的封装，如果某个第三方库（比如老版本的 gopkg.in/yaml.v2）内部用了可导出全局变量且未加锁，它仍可能在并发调用时出问题——这时别硬扛，升级库或 fork 修复，别试图用 sync.Mutex 包裹它的调用点，那只是掩盖症状。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
