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）都实现该接口。它们内部可封装自己的数据、策略和转移逻辑，而不是被动被切换——状态自己决定是否处理、如何处理、以及是否触发状态迁移。
链式流转：状态间通过返回值或回调主动移交控制权
责任链的“传递”不依赖外部调度器，而是由当前状态处理器自主决定：
立即学习“go语言免费学习笔记（深入）”；
- 若当前状态能完整处理请求，直接返回结果，不移交
- 若需前置校验/后置通知，可调用下一个状态（或注册的钩子），但不强制“必须传给下个”
- 若应进入新状态（如从 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）合并同类节点
不复杂但容易忽略