如何在Golang中实现状态+责任链模式_对象状态变化与请求处理

Go中可组合状态模式与责任链模式，使每个状态实现Handler接口成为可插拔处理器，通过Context管理状态流转，适用于多状态、行为差异大且需审计的场景。

在 Go 语言中，状态模式（State Pattern）和责任链模式（Chain of Responsibility）可以组合使用，解决“对象行为随状态变化而动态改变，且请求需按条件逐级处理”的典型场景。这种组合不是简单拼接，而是让每个状态本身成为一个可插拔的处理器节点，形成一条“带状态感知的责任链”。

状态即处理器：每个状态实现统一 Handler 接口

核心思路是将状态抽象为符合责任链规范的处理器。定义一个通用接口，既表达“我能处理请求”，也隐含“我代表某种状态”：

// Handler 是责任链节点，也是状态的载体
type Handler interface {
    Handle(ctx context.Context, req Request) (Response, error)
    GetStateName() string // 便于日志、调试或决策
}

每个具体状态（如 IdleState、ProcessingState、FailedState）都实现该接口。它们内部可封装自己的数据、策略和转移逻辑，而不是被动被切换——状态自己决定是否处理、如何处理、以及是否触发状态迁移。

链式流转：状态间通过返回值或回调主动移交控制权

责任链的“传递”不依赖外部调度器，而是由当前状态处理器自主决定：

• 若当前状态能完整处理请求，直接返回结果，不移交
• 若需前置校验/后置通知，可调用下一个状态（或注册的钩子），但不强制“必须传给下个”
• 若应进入新状态（如从 Idle → Processing），则更新上下文中的当前 handler，并可选择同步重试或异步触发

示例片段：

func (s *ProcessingState) Handle(ctx context.Context, req Request) (Response, error) {
    // 执行实际业务逻辑
    resp, err := s.doWork(ctx, req)
    if err != nil {
        // 失败时主动切换到 FailedState
        s.ctx.SetCurrentHandler(s.failedHandler)
        return Response{}, err
    }
    // 成功后切到 DoneState，并返回结果
    s.ctx.SetCurrentHandler(s.doneHandler)
    return resp, nil
}

上下文解耦：Context 封装状态生命周期与链路管理

定义一个轻量 Context 结构，持有当前 handler、状态历史、取消信号等，避免全局变量或层层传参：

type StateContext struct {
    mu sync.RWMutex
    current Handler
    history []string
    cancel func()
}
func (c *StateContext) SetCurrentHandler(h Handler) {
    c.mu.Lock()
    c.current = h
    c.history = append(c.history, h.GetStateName())
    c.mu.Unlock()
}
func (c *StateContext) Handle(ctx context.Context, req Request) (Response, error) {
    c.mu.RLock()
    h := c.current
    c.mu.RUnlock()
    if h == nil {
        return Response{}, errors.New("no active state")
    }
    return h.Handle(ctx, req)
}

这样，业务代码只需操作 Context，完全 unaware 具体状态类型或链路结构。

实用建议：何时用？怎么避免滥用？

这种组合适合以下情况：

• 对象有明确、有限的状态集合（如订单：created → paid → shipped → delivered → cancelled）
• 不同状态下对同一请求（如 “确认收货”）的响应逻辑差异大，且可能引发状态跃迁
• 需要审计状态变更路径、支持回滚或条件跳转（例如超时自动从 Processing → Timeout）

避免过度设计：

• 状态少于 3 个、逻辑简单时，用 if-else 或 map[string]func 更清晰
• 不要把所有字段都塞进状态结构体——只放影响行为的必要状态数据
• 责任链层级不宜超过 4～5 层，否则调试困难；可用组合（Composite Handler）合并同类节点

不复杂但容易忽略