Go中状态模式减少if else的关键是用map[State]func(*Context) error查表执行，将状态判断下沉到注册表，避免业务逻辑中重复条件分支。
状态模式在 Go 中为什么能减少 if else
因为 Go 没有继承和虚函数，直接照搬传统 OOP 的状态模式（比如 Java 里让每个状态实现 State 接口）容易写成一堆空接口+类型断言，反而更难维护。真正有效的替代方式是：用 func 类型封装状态行为，配合结构体字段存储当前状态标识，把“判断逻辑”从调用方下沉到状态注册表里。
用 map[string]func() 替代 if else 的实际写法
核心不是抽象出多少接口，而是让状态流转变成查表+执行。每个状态对应一个闭包或普通函数，避免在业务逻辑里反复写 if s.state == "pending" { ... } else if s.state == "done" { ... }。
- 状态名用
string或自定义enum类型（如type State string），便于日志、调试和序列化 - 行为函数签名统一为
func(*Context) error，保证可组合性和错误传播 - 注册表用
map[State]func(*Context) error，初始化时一次性注入，运行时只做一次查表 - 禁止在状态函数内部再写大段条件分支——那只是把 if else 搬到了另一个地方
type State string
const (
Pending State = "pending"
Running State = "running"
Done State = "done"
)
type Context struct {
state State
data map[string]interface{}
}
type StateHandler func(*Context) error
var stateHandlers = map[State]StateHandler{
Pending: func(c *Context) error {
c.data["started_at"] = time.Now()
c.state = Running
return nil
},
Running: func(c *Context) error {
if len(c.data["result"].(string)) > 0 {
c.state = Done
}
return nil
},
Done: func(c *Context) error {
return errors.New("already done")
},
}
func (c *Context) Handle() error {
handler, ok := stateHandlers[c.state]
if !ok {
return fmt.Errorf("no handler for state %q", c.state)
}
return handler(c)
}
什么时候不该用状态模式而该用 switch
如果状态数少（≤4）、行为简单（每种状态就 1–2 行逻辑）、且不涉及异步或外部依赖，硬套状态模式反而增加间接层。Go 原生 switch 编译后是跳转表，性能好、可读性高、IDE 支持全（比如自动补全 case、检查漏掉的枚举值）。
-
switch更适合「状态即控制流」场景，比如 HTTP 请求处理中根据req.Method分发 - 状态模式更适合「状态带生命周期行为」场景，比如订单从创建→支付→发货→完成，每步要校验前置条件、触发事件、更新时间戳
- 混用常见错误：把
switch里的每个case拆成独立函数，但没抽离共享上下文，导致参数越来越多
嵌入式状态机与 goroutine 安全的关键点
Go 里状态变更常伴随并发操作（比如定时器触发状态切换、HTTP handler 并发调用 Handle()），必须明确谁负责同步。不要假设「结构体方法天然线程安全」。
立即学习“go语言免费学习笔记（深入）”；
- 最简方案：所有状态变更方法加
mu sync.RWMutex，读操作用RLock()，写操作用Lock() - 进阶方案：用
chan StateTransition把状态变更转为消息，由单个 goroutine 串行处理（类似 actor 模型） - 绝对避免：在状态函数里启动新 goroutine 并直接修改
c.state—— 竞态检测工具（go run -race）大概率报错 - 测试时务必覆盖「并发调用同一状态方法」和「状态正在变更时读取
c.state」两种情况
