Go atomic.Bool 怎么做运行时功能开关：并发读取、灰度切换与回滚

线上服务刚上线新的推荐排序逻辑，产品希望先切10%的流量做试用，真出问题的时候几秒内就能关停，不用等下一轮发版。Go 里直接用 atomic.Bool 存这个运行时功能开关就很合适：正常业务请求路径用 Load() 读状态，后台管理入口用 Store() 改状态，全程不用给高频的读请求加互斥锁，体验很顺畅。

先把功能开关收敛成单一清晰的状态

这个场景下，开关只需要回答一个问题：当前能不能走新的排序逻辑。它不需要存流量百分比、不需要做请求鉴权，更不要顺手把其他杂七杂八的配置字段都塞到同一个原子变量里。状态越纯粹，切换和回滚的时候越容易做校验，不容易出边界问题。

package feature

import "sync/atomic"

type Switch struct {
    recommendation atomic.Bool
}

func NewSwitch(enabled bool) *Switch {
    s := &Switch{}
    s.recommendation.Store(enabled)
    return s
}

func (s *Switch) RecommendationEnabled() bool {
    return s.recommendation.Load()
}

func (s *Switch) SetRecommendation(enabled bool) {
    s.recommendation.Store(enabled)
}

写操作统一调用 Store、读操作统一调用 Load，是用这个类型最核心的约束。不要把 atomic.Bool 当成普通bool字段直接赋值，也别随便把它的指针复制传到其他结构体里；原子类型初始化完成之后，就应该固定在声明的位置不挪动。

业务请求路径里只做一次 Load 读取

判断开关的逻辑最好放在请求的入口附近。每个请求刚进来就读一次拿到确定的布尔值，后续所有下游函数都用这个普通布尔值做参数，代码写起来好测试，也不会出现同一个请求执行过程中前后两次读到不一样的开关状态的情况。

func (h *Handler) Recommend(w http.ResponseWriter, r *http.Request) {
    useNewRanker := h.switches.RecommendationEnabled()

    var result []Item
    if useNewRanker {
        result = h.newRanker.Rank(r.Context())
    } else {
        result = h.legacyRanker.Rank(r.Context())
    }

    writeJSON(w, result)
}

这里要求“一次读取”不是为了炫性能优化技巧，而是保证单个请求的执行语义更稳定。比如运维刚好在请求跑了一半的时候切开关，这个请求还是会完整走之前选定的逻辑路径，后续新进来的请求才会用新的开关状态。如果一个请求里需要同时依赖多个开关状态，也建议在入口统一读取完拼成一份不可变的决策对象再往下传。

为什么不用普通 bool 加互斥锁实现？

普通 bool 加锁当然也能实现完全一样的业务逻辑，但所有读写操作都必须严格遵守同一把锁的约束。功能开关是典型的读多写少的共享状态，用 atomic.Bool 可以把并发同步的语义直接封装在字段内部，能大幅减少业务代码里漏加锁的低级错误。但要注意它也不能替代需要多个字段同时保证一致性的事务类场景。

灰度比例和开关状态要拆成两层判断

“正式放开新功能入口”和“只允许10%的用户用新功能”是两个完全独立的判断逻辑。最轻量化的实现可以先拿 atomic.Bool 当总闸门，再通过用户ID的稳定哈希来匹配灰度人群：

func (h *Handler) useNewRanker(userID string) bool {
    if !h.switches.RecommendationEnabled() {
        return false
    }
    return bucket(userID) 

总闸门处于关闭状态的时候，所有用户都进不了新逻辑；总闸门打开之后，也只有命中灰度规则的用户才会走新逻辑分支。不要用随机数在每次请求里重新抽样分配流量，不然同一个用户连续刷新页面可能一会儿走新逻辑一会儿走旧逻辑，线上排查问题的时候日志数据会非常乱，很难定位根因。

回滚动作必须能被日志和监控指标佐证

开关切换接口至少要记录开关名称、切换前的旧值、切换后的新值、操作人身份和操作原因这几个核心信息。业务监控指标也要分别统计 ranker_new_total、ranker_legacy_total 两条路径的请求量和错误计数。如果只看服务总请求成功率，很可能掩盖新逻辑已经导致小部分用户请求异常的问题。

func (h *Admin) DisableRecommendation(w http.ResponseWriter, r *http.Request) {
    h.switches.SetRecommendation(false)
    h.logger.Info("feature switch changed",
        "name", "recommendation",
        "enabled", false,
        "reason", "rank error spike",
    )
    w.WriteHeader(http.StatusNoContent)
}

执行回滚之后要留一段完整的业务观测窗口：确认新逻辑的请求计数不再上涨、旧逻辑的请求量恢复到对应水位、错误率和延迟指标都回到基线水平。如果你的服务是多实例部署的，进程内的 atomic.Bool 只会修改当前实例的状态；生产环境要通过配置中心、数据库或者管理广播把同一个开关状态同步到所有实例，还要同步记录配置的版本号避免不一致。

相关问题

atomic.Bool 能直接存跨实例的全局开关吗？

不行。它只能保证当前 Go 进程内部的并发读写安全。跨实例的状态一致性需要依赖外部存储或者配置分发机制，atomic.Bool 只是每个实例拿到新配置之后，用来做本地安全承载的容器而已。

开关关掉之后，已经在跑的新请求会受影响吗？

请求已经在入口处读到 true 状态的话，通常会完整走完当前的新逻辑路径；关闭操作只会影响后续新进来的请求的读取结果。如果要求开关切完立刻终止所有正在执行的新逻辑请求，就要在更细的业务执行阶段加取消信号或者版本校验，这已经不是单个布尔开关能覆盖的场景了。

什么时候应该换成 atomic.Value ？

当你的状态不再是单个布尔值，而是同时包含流量比例、版本号、规则集等多个字段，而且要求每次都读到同一份完整的快照时，就可以把整个不可变的配置对象放进 atomic.Value 里。不要用多个独立的原子字段拼凑出一份需要强一致的配置，很容易出时序问题。

把功能开关限定在可快速回退的边界上

atomic.Bool 最大的价值，就是把“能不能走新逻辑”这个判断变成一个成本极低、可观测、能秒级回退的状态。入口处只读一次、管理侧收拢切换逻辑、灰度规则独立计算、新旧路径指标分开统计，把这几件事做扎实，开关才不会变成藏在业务代码深处没人敢碰的临时变量。