Beego中全局变量并发不安全，因每个请求由独立goroutine处理，counter++或map写操作非原子，易丢数据、panic；应使用sync.Mutex、sync.Map或依赖注入+Context传递替代。
Beego 项目里直接在 handler 或中间件里读写全局变量（比如 var counter int、var cache map[string]interface{}），大概率会出错——不是“可能”，是“一定”会在并发请求下丢数据、panic 或返回错误值。
为什么 Beego 的全局变量在多协程下不安全
Beego 基于 Go 的 net/http，每个 HTTP 请求默认由一个独立 goroutine 处理。如果你在某个 handler 里做 counter++，或往 cache["key"] = value 写数据，多个 goroutine 会同时读写同一块内存，而 Go 不保证这些操作的原子性。
-
counter++实际是“读-改-写”三步，中间可能被其他 goroutine 插入 -
map类型本身不是并发安全的，哪怕只是len(cache)都可能 panic - Beego 的
AppConfig、BeeLogger等内置对象虽做了同步封装，但你自己定义的变量不会自动获得保护
用 sync.Mutex 或 sync.RWMutex 包裹临界区
这是最直接、可控的方式，适合读多写少或写操作明确的场景。别试图靠“我只读不写”来绕过——只要存在任何写操作，就必须加锁。
- 定义时带上锁：
var mu sync.RWMutex和var cache = make(map[string]interface{}) - 读操作用
mu.RLock()/mu.RUnlock()，写操作用mu.Lock()/mu.Unlock() - 避免在锁内做耗时操作（如 HTTP 调用、DB 查询），否则会阻塞其他 goroutine
- 不要 defer 解锁后还访问共享变量，容易死锁或读到脏数据
改用 sync.Map 替代普通 map
如果只是做键值缓存、且读远多于写，sync.Map 是更轻量的选择——它内部做了分段锁优化，比手动加 sync.Mutex 更适合高频读场景。
- 声明：
var cache sync.Map - 写：
cache.Store("key", value) - 读：
if v, ok := cache.Load("key"); ok { ... } - 注意：
sync.Map不支持遍历（range）、不支持len()，需用Range()回调处理 - 不适合频繁写+复杂逻辑，它的优势在“简单存取”，不是通用替代品
Beego 中更推荐的解法：依赖注入 + Context 传递
全局变量本质是设计坏味道。Beego 支持通过 Controller.Ctx.Input.Data 或自定义中间件注入上下文对象，把状态绑定到单次请求生命周期，彻底避开并发问题。
- 在中间件中初始化一次结构体实例（含字段、锁、缓存等），存入
ctx.Input.Data["ctxdata"] - 后续 controller 可安全使用该实例，无需担心跨请求污染
- 配合
context.Context传递超时、取消信号，便于资源回收和优雅终止 - 测试友好：每个测试用例可构造独立上下文，不依赖全局状态
真正难的不是加锁，而是判断哪些变量“看起来只读”实则被多个 goroutine 暗中修改——比如日志器、配置快照、计数器、临时缓存。这类变量一旦暴露在 handler 层，就该默认视为并发不安全，必须显式保护或重构作用域。
