## 01、痛点

我是老李，一个在 Java 后端摸爬滚打多年的开发。上个月接手一个订单系统，让我见识了什么是“状态判断地狱”。

这个订单服务最开始只支持待支付、已支付、已完成三种状态，代码很简单。后来业务发展，增加了已发货、已取消、退款中等状态。原本清晰的 `if/else` 慢慢变成横跨多个方法、多个 Service 的巨型 `switch`。状态转换逻辑散落各处：支付回调里改状态，发货接口里改状态，取消接口里判断一堆前置条件。新增一个状态，要动五六个文件；想加一个“已确认”状态，测试说不敢测，因为影响老流程。

代码逐渐变成这样：

```java
public void handle(Order order, String action) {
    if ("pay".equals(action)) {
        if (order.getStatus() == 0) { // 待支付
            order.setStatus(1); // 已支付
        } else {
            throw new RuntimeException("状态不允许支付");
        }
    } else if ("ship".equals(action)) {
        if (order.getStatus() == 1) { // 已支付
            order.setStatus(2); // 已发货
        } else {
            throw new RuntimeException("状态不允许发货");
        }
    } else if ("cancel".equals(action)) {
        if (order.getStatus() == 0 || order.getStatus() == 1) {
            order.setStatus(-1); // 已取消
        } else {
            throw new RuntimeException("状态不允许取消");
        }
    }
}
```

字符化看这段逻辑：

```
OrderService
 |
 +-- 支付: if status==0 ...
 +-- 发货: if status==1 ...
 +-- 取消: if status==0 || status==1 ...
 +-- 完成: if status==2 ...
 +-- 退款: if status==...
 ...
```

> 锐评：如果只有两三个状态且五年不变，硬上状态模式确实是过度设计；但状态超过五个、转换规则超过十条，还靠 if/else 硬扛，那代码就变成了考古现场。

设计模式真正解决的不是“代码写得不高级”，而是“变化开始失控”。状态模式尤其针对“状态多、转换复杂、非法转换难以约束”的场景。

## 02、是什么

状态模式，不是教科书里的“允许一个对象在其内部状态改变时改变它的行为”。从工程视角看，它解决一个问题：一个对象的行为依赖于它的状态，并且状态转换规则复杂时，如何让代码不变成一锅粥。

核心角色有三个：

- **Context**（上下文）：维护当前状态，对外暴露操作接口，将请求委托给当前状态对象。
- **State**（抽象状态）：定义行为接口，声明所有状态共用的方法。
- **ConcreteState**（具体状态）：实现某状态下的行为，并负责状态转换。

结构图：

```
Context (Order)
   |
   v
State (OrderState)  <-- 行为接口
   ^
   |
   +-- PendingPaymentState
   +-- PaidState
   +-- ShippedState
   +-- CompletedState
   +-- CancelledState
```

关键不是有多少个类，而是把“在不同状态下做什么”和“能不能切换到另一个状态”内聚到每个具体状态对象里。这样，每个状态自己管理允许执行的操作，非法转换在具体状态类里直接抛出异常。

状态模式与策略模式容易混淆：策略模式是主动选择算法，调用方决定用哪个策略；状态模式是状态驱动行为，当前状态决定能做什么，状态转换由状态对象自己管理。

代码坏味道到模式映射：

- 对象有多个状态，且行为依赖状态 → 状态模式
- if/else 按类型变化，主动选择算法 → 策略模式

## 03、为什么

为什么很多人学过状态模式却不会用？常见误区：

**误区一：先背模式，再找地方套。** 拿着状态模式去套一个只有“是/否”两种状态的开关，结果类翻倍，逻辑更绕。

**误区二：看到 switch 就认为必须上状态模式。** 其实一个稳定的、不超过五个分支的判断，保留 switch 可能更清晰。

**误区三：抽象层越多，架构越高级。** 状态模式会增加类数量，如果状态转换并不复杂，引入它是负担。

判断状态模式是否值得使用的标准：

1. 状态是否真实存在并且会持续增长？
2. 状态转换规则是否复杂，是否集中在多个方法里？
3. 是否存在非法状态转换需要阻止？
4. 新增状态时是否频繁影响旧逻辑？
5. 引入模式后，理解成本是否低于原来的维护成本？

判断公式：**模式收益 = 未来变化成本降低 - 当前抽象复杂度增加**。

> 锐评：十行代码解决的问题，不要写成一场架构发布会。但如果你的 `handle` 方法已经需要滚动三屏才能看完，那问题就不是发布会，而是火灾现场。

## 04、架构

设计模式实践地图，按开发问题分类。对于“状态不同导致行为不同”，对应状态模式。

完整思路：

```
需求变化
   ↓
变化点识别：对象状态影响行为，状态转换规则变多
   ↓
职责拆分：状态行为封装到具体状态类，上下文只维护当前状态
   ↓
模式选择：状态模式
   ↓
接口稳定：State 定义业务方法
   ↓
实现扩展：新增状态类，无需修改上下文和旧状态类
```

状态模式的核心是将状态转换逻辑从散落的 if/else 集中到各个状态类内部，每个状态自己决定能切换到哪些状态。这样符合开闭原则：新增状态开放，修改原有状态关闭。

## 05、实战

业务场景：订单服务需要支持五种状态：待支付、已支付、已发货、已完成、已取消。每种状态允许的操作不同：待支付可以支付、取消；已支付可以发货、取消（某些业务允许）；已发货可以确认完成；已完成和已取消是终态，不允许任何操作。

### 第一版代码

传统写法用 `switch` 或 `if/else` 堆在 OrderService 里：

```java
public void pay(Order order) {
    if (order.getStatus() == PENDING_PAYMENT) {
        order.setStatus(PAID);
    } else {
        throw new IllegalStateException("当前状态不允许支付");
    }
}

public void ship(Order order) {
    if (order.getStatus() == PAID) {
        order.setStatus(SHIPPED);
    } else {
        throw new IllegalStateException("当前状态不允许发货");
    }
}

public void complete(Order order) {
    if (order.getStatus() == SHIPPED) {
        order.setStatus(COMPLETED);
    } else {
        throw new IllegalStateException("当前状态不允许完成");
    }
}
```

代码不多，但问题在于：每个操作都重复状态判断；新增状态（比如“退款中”）要改所有操作方法；非法转换的判断散落各处；状态转换规则不直观。

### 模式重构

定义状态接口：

```java
public interface OrderState {
    void pay(OrderContext context);
    void ship(OrderContext context);
    void complete(OrderContext context);
    void cancel(OrderContext context);
}
```

上下文：

```java
public class OrderContext {
    private OrderState currentState;
    
    public OrderContext(OrderState initialState) {
        this.currentState = initialState;
    }
    
    public void setState(OrderState state) {
        this.currentState = state;
    }
    
    public void pay() { currentState.pay(this); }
    public void ship() { currentState.ship(this); }
    public void complete() { currentState.complete(this); }
    public void cancel() { currentState.cancel(this); }
}
```

具体状态类，待支付状态：

```java
public class PendingPaymentState implements OrderState {
    @Override
    public void pay(OrderContext context) {
        // 支付成功逻辑
        context.setState(new PaidState());
    }
    
    @Override
    public void ship(OrderContext context) {
        throw new IllegalStateException("待支付订单不能发货");
    }
    
    @Override
    public void complete(OrderContext context) {
        throw new IllegalStateException("待支付订单不能完成");
    }
    
    @Override
    public void cancel(OrderContext context) {
        context.setState(new CancelledState());
    }
}
```

已支付状态：

```java
public class PaidState implements OrderState {
    @Override
    public void pay(OrderContext context) {
        throw new IllegalStateException("已支付订单不能重复支付");
    }
    
    @Override
    public void ship(OrderContext context) {
        context.setState(new ShippedState());
    }
    
    @Override
    public void complete(OrderContext context) {
        throw new IllegalStateException("已支付订单不能直接完成");
    }
    
    @Override
    public void cancel(OrderContext context) {
        // 某些业务允许已支付取消，需要退款
        context.setState(new CancelledState());
    }
}
```

其他状态类似。使用示例：

```java
OrderContext order = new OrderContext(new PendingPaymentState());
order.pay();   // 状态变为已支付
order.ship();  // 状态变为已发货
order.complete(); // 状态变为已完成
order.cancel(); // 抛出异常，已完成不能取消
```

结构变化字符画：

传统写法：

```
OrderService
 |
 +-- pay(): if status==0 ...
 +-- ship(): if status==1 ...
 +-- complete(): if status==2 ...
 +-- cancel(): if status==0||1 ...
```

重构后：

```
OrderContext
 |
 v
OrderState (接口)
 |_ PendingPaymentState  -->  pay()/cancel()
 |_ PaidState             -->  ship()/cancel()
 |_ ShippedState          -->  complete()
 |_ CompletedState        -->  (终态)
 |_ CancelledState        -->  (终态)
```

### 收益

- 消除大量 if/else 和 switch，每个状态的逻辑内聚。
- 新增状态只需新增一个类，符合开闭原则。
- 非法状态转换由状态对象自己管理，语义清晰。
- 便于单元测试：可以单独测试每个状态类的行为。
- 状态转换规则显式化。

### 代价

- 类数量增加：每个状态一个类。
- 理解链路变长：调用方通过 Context 间接调用，不直接看到实际状态。
- 如果状态转换逻辑非常简单（如只有两个状态），状态模式是过度设计。

### 什么时候不要用

- 状态数量少且稳定（如只有启用/禁用）。
- 行为不依赖状态，或状态转换逻辑很简单。
- 状态转换逻辑非常固定，用 switch 反而更直观。
- 项目周期短，没有扩展需求。

> 锐评：一个只有两种支付状态且三年不变的订单系统，硬拆成六个状态类，解决的不是扩展性问题，而是阅读理解问题。

口诀：状态模式不是消灭 if/else，而是把状态变化引起的 if/else 隔离到各个状态对象里，让转换规则可维护。

## 06、洞见

从状态模式上升到设计模式的判断力。

**洞见一：设计模式真正关注的是“变化”，不是“类”。** 状态模式解决的是状态行为变化，如果你能识别出变化点，模式自然而然会浮现。

**洞见二：好的抽象来自重复出现的变化，不是提前想象。** 状态模式在状态多时才显示出优势，一两个状态用 switch 反而更清晰。

**洞见三：设计模式的价值是降低修改半径。** 新增状态只加类，不改旧类，这就是开闭原则。

**洞见四：架构能力的重要体现，不是能设计多少层，而是知道什么时候不需要设计。**

**洞见五：Spring 框架中大量使用设计模式。** 虽然状态模式不是 Spring 核心，但 Spring State Machine 提供了更完善的状态机支持。如果业务状态非常复杂，可以引入框架，但一般项目手写状态模式已足够。

> 锐评：初级开发者喜欢把代码写出来，高级开发者开始考虑怎么变化，架构师最终考虑的是：哪些地方根本不值得抽象。

## 07、行动

学习状态模式分三阶段。

**第一阶段：理解三个角色。** 动手实现一个简单订单状态机（如本文示例），理解 Context、State、ConcreteState 的关系。

**第二阶段：从自己的项目里找状态判断。** 找到那些用 `status` 字段加 `if/else` 或 `switch` 控制业务行为的地方，识别状态、事件、转换规则。判断是否值得用状态模式：状态数是否超过三个？转换规则是否分散？是否有非法转换需要阻止？

**第三阶段：尝试重构。** 每次回答五个问题：

1. 变化点是什么？
2. 不使用模式会怎样？
3. 使用模式增加了什么复杂度？
4. 下一次新增状态需要修改几个地方？
5. 新人是否更容易理解？

七天实践计划：

- Day 1：找一个订单/工单/审批流代码，画出它的状态转换图。
- Day 2：识别当前代码中的 if/else 和 switch 判断。
- Day 3：定义 State 接口和 Context，列出所有状态。
- Day 4：实现每个 ConcreteState，填充允许操作和状态转换。
- Day 5：替换原有 Service 中的条件判断，跑通单元测试。
- Day 6：添加一个非法状态转换测试，确认异常抛出。
- Day 7：重新评估：是否过度设计？如果状态很少，改回 switch 是否更清晰？

## 08、小结

金句：状态模式不是为了让代码看起来高级，而是为了让下一次状态变更时，你不用推倒重来。

状态模式把散落在各处的状态判断收拢到状态对象里，让每个状态自己负责能做什么、下一步去哪。真正值得学的不是“状态模式”这四个字，而是识别状态变化、隔离状态行为、控制转换规则的能力。

如果读完这篇文章，你少写了一个 500 行的状态 switch，这篇文章就算没有白写。

## 09、链接与概念说明

- **GoF 是什么**：GoF（Gang of Four）指《设计模式：可复用面向对象软件的基础》四位作者，书中总结了 23 种经典设计模式，状态模式是行为型模式之一。
- **创建型/结构型/行为型**：创建型关注对象怎么创建，如工厂方法、抽象工厂、建造者；结构型关注对象如何组合，如适配器、装饰器、代理；行为型关注对象之间如何交互和职责分配，如策略、模板方法、观察者、状态。
- **SOLID 原则与设计模式的关系**：状态模式通常体现单一职责原则（每个状态类一个职责）和开闭原则（新增状态不修改原有类）。
- **开闭原则**：对扩展开放，对修改关闭。状态模式通过新增具体状态类扩展行为，而不需要修改原有状态类。
- **推荐继续阅读**：《设计模式：可复用面向对象软件的基础》（GoF 原著）、《Head First 设计模式》、《企业应用架构模式》。如需更复杂的状态机支持，可参考 Spring State Machine 官方文档。

我是老李，一个在 Java 后端摸爬滚打多年的开发。上个月接手一个订单系统，让我见识了什么是“状态判断地狱”。

《设计模式军体拳第21招》 状态模式 State——让对象行为跟着状态一起变化

从订单状态的一堆 if/else 到独立状态对象，状态模式如何隔离状态行为、控制状态流转，以及什么时候不该用。

架构师

编程语言

后端

Java订单状态判断地狱如何破局？本文通过实战案例剖析状态模式，对比if/else与模式重构方案，清晰展示状态多、转换复杂场景下的代码治理技巧。提供七天实践计划，助你掌握状态机设计精髓，降低修改半径，让新增状态不再推倒重来。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《设计模式军体拳第21招》 状态模式 State——让对象行为跟着状态一起变化-腾讯云开发者社区-腾讯云

《设计模式军体拳第21招》状态模式 State——让对象行为跟着状态一起变化

《设计模式军体拳第21招》状态模式 State——让对象行为跟着状态一起变化

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第21招》 状态模式 State——让对象行为跟着状态一起变化

《设计模式军体拳第21招》 状态模式 State——让对象行为跟着状态一起变化

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第21招》状态模式 State——让对象行为跟着状态一起变化

《设计模式军体拳第21招》状态模式 State——让对象行为跟着状态一起变化