go项目中不应使用全局变量，而应通过未导出包级变量+init初始化+只读getter或带锁访问来安全共享资源；避免在并发handler中直接操作包级变量，推荐依赖注入而非隐式单例。
Go 项目里不该有“全局变量”这个概念，只有受控的、有明确生命周期和访问边界的包级变量。 直接导出可读可写的 var 是高危操作，尤其在并发场景下极易引发数据竞争或上下文污染。真正需要的不是“怎么定义全局变量”，而是“怎么让配置、连接、状态等关键资源，在需要的地方安全、清晰、可控地被使用”。
导出变量名首字母大写 ≠ 安全共享
很多人以为只要把 var Config *Config 写在包顶层、首字母大写，就能跨包安全使用——这是最大的误解。导出只是解决了“能不能访问”的问题，完全没解决“能不能并发读写”“会不会被意外修改”“初始化时机是否可靠”这三个核心风险。
- 如果多个包同时执行
Config = loadFromEnv()，结果不可预测； - 如果某个 handler 直接改了
Config.Timeout，所有后续请求都会受影响； - 若
Config在 init() 之前就被其他包引用（比如被 import cycle 触发），可能拿到 nil 或零值。
用 init() + unexported var + getter 封装初始化逻辑
真正安全的一次性初始化，靠的是分离“存储”和“访问”。底层变量必须小写（未导出），初始化逻辑收束到 init()，对外只暴露带锁或无状态的读取接口。
- 声明：
var config *Config（小写，不导出）； - 初始化：
func init() { config = loadConfig() }（仅执行一次，且在 main 之前）； - 访问：
func GetConfig() *Config { return config }（简单读取，无锁，前提是 config 不变）； - 若需动态更新（如热重载），则加
sync.RWMutex，读用RUnlock，写用Lock，并确保写操作是原子替换（config = newConfig），而非字段级修改。
避免在 handler 或中间件里直接引用包级变量
HTTP handler、Gin middleware 这类代码天然并发执行，直接读写包级变量等于裸奔。常见错误是把 db *sql.DB 或 cache map[string]Item 暴露为导出变量，然后在 func index(c *gin.Context) 里直接操作。
- 正确做法：把依赖注入到 handler 闭包或结构体中，例如
router.GET("/user", makeUserHandler(db, cache))； - 更现代的做法：用构造函数返回 struct 实例，把依赖作为字段传入，handler 方法绑定到该 struct 上；
- 绝对不要在 handler 里做
globalCache[key] = val这类操作——除非你已经用sync.Map或加锁保护，且确认 key 是请求隔离的（比如带 traceID 前缀）。
真正该淘汰的，是“跨包共享状态”的思维惯性
很多所谓“全局变量需求”，其实源于初始化顺序混乱、依赖传递不清晰、或测试难隔离。比如日志实例、数据库连接池、配置解析器——它们本该是应用启动时一次性构建、通过参数或 DI 容器注入各模块的实体，而不是靠 logrus.StandardLogger() 这种隐式单例来“方便”。
最容易被忽略的一点：**即使你用了 sync.Mutex 保护一个 map，也无法防止业务逻辑误用它来存请求级上下文（比如把当前用户 ID 存进去），这比不加锁还危险——它掩盖了设计缺陷。** 真正健壮的架构，会让“哪里能写、谁有权写、写完谁负责清理”一目了然，而不是靠文档或约定来约束。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
