go中全局变量是状态管理最危险的捷径，因其导致并发不安全、测试难隔离、多租户混乱且违反依赖显式化；应将状态绑定到具体实例，用组合+接口驱动流转，仅极少数场景（如连接池）可用sync.map或atomic.value安全实现。
Go 中的全局变量是状态管理最危险的捷径——它让并发安全、测试隔离和状态追踪全部失效。除非你明确需要进程级单例（如日志器、配置缓存），否则所有业务状态都应绑定到具体对象实例上，用组合 + 接口驱动流转。
为什么全局状态在 Go 里特别容易出问题
Go 的 goroutine 轻量但共享内存，而全局变量天然跨 goroutine 可见。一旦多个请求并发修改同一个 var currentUser *User 或 var orderStatusMap = make(map[string]string)，就立刻触发竞态（fatal error: concurrent map writes）或静默数据污染。
- 测试时无法重置：一个测试用例改了全局
config.Env，下一个测试就跑偏 - 无法支持多租户：SaaS 场景下，不同客户订单状态混在同一个 map 里，逻辑必然错乱
- 违反依赖显式化原则：函数签名不体现状态依赖，调用方根本不知道自己在读写什么
替代方案：用上下文结构体 + 状态接口封装状态
把状态从“到处可见”变成“必须显式传入”，才是 Go 式解法。比如订单状态，不要用 var orderState = "pending"，而是定义 Order 结构体并持有 state OrderState 字段。
-
OrderState是接口，声明Pay(*Order) error、Ship(*Order) error等方法 - 每个具体状态（
PendingState、PaidState）实现该接口，只处理自己允许的操作 - 状态切换由
Order.SetState(newState OrderState)统一控制，内部可加校验、日志、回调
这样，状态生命周期与 *Order 实例绑定，goroutine 安全、可测试、可审计。
立即学习“go语言免费学习笔记（深入）”；
哪些场景真需要“全局”，又该怎么安全地做
极少数情况确实需要跨实例共享状态，比如连接池、指标计数器、配置快照。这时必须用标准库提供的同步机制，且禁止直接暴露可变变量。
- 用
sync.Map替代普通map，避免手动加锁 - 用
atomic.Value存储不可变配置（如atomic.LoadPointer读取新配置指针） - 对外只暴露函数而非变量：提供
GetDB() *sql.DB而非导出var DB *sql.DB - 初始化阶段一次性设置，运行时禁止修改（如
config := loadConfig(); globalConfig = config）
真正难的不是写状态逻辑，而是守住“状态归属边界”——每个状态必须清楚地属于谁、由谁负责生命周期、谁有权修改。一旦让状态飘在全局，后面加日志、加权限、加灰度，全都会变成修修补补的苦活。
