状态接口应仅声明合法操作响应，不包含切换逻辑；切换由上下文统一决策；状态须用指针持有并初始化；避免nil panic；流转规则应收口至上下文表驱动管理。
状态接口定义要避免暴露内部状态变更方法
Go 没有继承，状态模式靠接口 + 组合实现，但容易误把 Play、Pause 这类行为塞进状态接口里——这会让状态对象自己决定“下一步该切到哪个状态”，破坏上下文（播放器）对流转逻辑的控制权。
正确做法是：状态接口只声明「对当前状态合法的操作响应」，不包含状态切换逻辑；所有切换由上下文统一决策。
-
State接口只含HandlePlay()、HandlePause()等无返回值方法，具体怎么响应由实现决定 - 状态切换动作（如 “暂停态 → 播放态”）必须在
Player的方法里显式调用p.currentState = &PlayingState{player: p} - 如果让
PausedState.HandlePlay()自己 new 一个PlayingState并赋给p.currentState，会导致状态对象越权，且难以测试和拦截流转
播放器上下文需持有状态指针而非值类型
用值类型存状态（比如 currentState PlayingState）会导致每次切换都复制整个结构体，更严重的是：状态内部回调 player 时，修改的是副本，不是原始播放器实例。
常见错误现象：PlayingState 调用 p.player.Pause() 后，实际播放器没暂停，日志也正常打印——因为 p.player 指向的是旧副本。
立即学习“go语言免费学习笔记（深入）”；
- 始终用指针字段：
currentState State，且所有状态实现都接收*Player构造 - 初始化时确保传入同一地址：
p.currentState = &PlayingState{player: p}，不是&PlayingState{player: *p} - 检查
fmt.Printf("%p", p)和各状态中fmt.Printf("%p", s.player)是否一致
空状态或未初始化状态触发 panic 的典型场景
刚创建 Player{} 时 currentState 是 nil，此时直接调用 p.Play() 就会 panic: nil pointer dereference —— 这是上线后最常踩的坑。
不是所有状态都需要“默认初始态”，但播放器必须明确起始点。视频播放器合理起点是 StoppedState 或 ReadyState，而非留空。
- 构造函数里强制初始化：
func NewPlayer() *Player { return &Player{currentState: &StoppedState{}} } - 避免在
State接口方法里做非空判断（如if s == nil），那说明调用方已失控 - 单元测试第一行就测
player := NewPlayer(); player.Play()是否 panic
状态流转条件分散导致难以维护
把“什么条件下能从 A 切到 B”写死在各个状态的 Handle 方法里，时间一长，没人敢动播放逻辑——因为新增一个 Seek() 操作，得改 4 个状态文件里的 4 个方法。
真正可控的做法是把流转规则收口到播放器内部，用表驱动或策略映射管理。
- 定义流转表：
transitionMap[StateName][Event] = TargetStateName，比如{"Paused": {"Play": "Playing"}} -
Player.Play()先查表确认当前状态是否允许 Play，再执行对应状态的HandlePlay()和切换 - 这样加新事件（如
Buffering）只需改一张 map，不碰任何状态实现
状态模式本身不难，难的是让状态之间不互相 hold 引用、不越权改上下文、流转逻辑不散落在各处。一旦出现“改一个状态，三个其他状态开始报错”，基本就是上下文和状态边界的契约被打破了。
