应使用状态模式而非枚举+条件分支的典型场景包括：多层if/else判断且各分支方法名不同、新增状态需修改多处逻辑、状态转换有严格前置约束、日志监控策略差异大导致类膨胀超500行。
状态模式不是“加个 switch 就完事”的权宜之计，它真正起效的前提是：状态之间存在明确的转换边界、行为差异大、且未来大概率要增删状态。否则直接用枚举+条件分支更轻量。
什么时候该用 IState 而不是 enum + if
当你发现以下任意一种情况正在发生，就该考虑状态模式了：
- 一个类里堆了 3 层以上的
if/else if判断CurrentState，且每个分支里调用的方法名都不同（比如StartWork()/PauseWork()/StopWork()） - 新增一种状态（比如从“运行中”加一个“降频运行”）需要改 4 个以上方法，还容易漏掉某处的
switch分支 - 某些状态只允许特定输入触发转换（比如“关机中”不允许再按开机键），但当前逻辑靠人工在每个操作入口写
if (state != Shutdown) { ... }防御，越来越难维护 - 不同状态下的日志、监控指标、异常处理策略完全不同，硬塞进一个类会让单个文件超过 500 行
Context 类里别直接 new 具体状态类
Context 的职责是持有状态引用并转发调用，不是负责创建状态实例。直接 new ConcreteStateA() 会导致：
- 状态类无法被依赖注入（比如你想在
ConcreteStateB构造函数里注入ILogger） - 多个
Context实例无法共享同一个状态对象（而有些状态其实是无状态的，比如IdleState可复用） - 测试时无法 mock 状态行为（你得 patch 构造函数，而不是替换接口）
正确做法是通过构造函数或属性注入 IState 实例，或由工厂类提供：
public class DeviceContext
{
private IState _currentState;
public DeviceContext(IState initialState) => _currentState = initialState;
public void HandleInput(Input input) => _currentState.Handle(this, input);
}
Handle 方法签名里要不要传 Context
要看状态是否需要修改 Context 的内部字段或触发状态切换。绝大多数真实场景都需要，所以推荐这个签名：
void Handle(DeviceContext context, Input input);
原因很实际：
- 状态转换必须由状态自己决定（比如
LockedState收到正确密码后，主动把context.State = new UnlockedState()） - 某些状态需要读取
context.Config或写入context.Log，不传参就得暴露大量public set属性，破坏封装 - .NET 中的
Action<t></t>委托也常这么设计——回调函数需要上下文才能做事
如果某个状态纯属“只读响应”，比如 DisplayOnlyState 只负责渲染 UI，那可以不要 context 参数，但这种情况极少。
别让状态类持有对 Context 的强引用
循环引用不是语法错误，但会阻碍 GC 回收，尤其在长生命周期的 Context（如 Windows 服务中的主协调器）里，容易造成内存缓慢增长。
解决方法很简单：用弱引用或事件解耦。
- 若状态只需触发一次状态切换，改用
event Action<istate> StateChanged</istate>，由Context订阅并更新自身_currentState - 若状态需频繁读写
Context的几个字段，提取成一个只读接口（如IContextSnapshot），由Context在调用Handle前构造并传入 - 避免在状态类里写
context.DeviceManager.DoSomething()这种深度穿透调用；该由Context提供能力契约
最易被忽略的一点：状态类的生命周期应短于 Context。如果某个状态需要长期驻留（比如后台轮询），它就不该是 IState 的实现，而应是独立的服务组件。
