对象状态迁移本质是将流程逻辑从if-else中解耦，通过state字段+显式校验驱动行为变化；需用enum定义状态、封装变更方法、校验合法性，小规模用switch更轻量，复杂流程才用state模式或spring state machine，并发下必须数据库条件更新+应用层校验。
对象状态迁移的本质是把流程逻辑从if-else里拎出来
Java里没有原生的“状态机”语法，所谓对象状态迁移，其实是用对象的state字段配合显式判断来驱动行为变化。它不是炫技，而是当一个对象生命周期里有明确阶段（比如订单：待支付→已支付→发货中→已完成），且每个阶段允许的操作、能触发的事件、校验规则都不同，硬写一堆if (order.getState() == "PAID") { ... }很快会失控。
常见错误现象：NullPointerException频发、状态被非法跳转（比如从“已取消”直接变“已完成”）、并发下状态覆盖（两个线程同时把state从“待审核”改成“通过”和“拒绝”）。
- 状态值必须用
enum而非String或int，避免拼写错和越界 - 状态变更必须封装在方法里，比如
order.confirmPayment()，而不是直接order.setState("PAID") - 所有状态变更入口要加校验：当前状态是否允许执行该操作？目标状态是否合法？
用State模式避免if-else爆炸但别过度设计
State模式确实能把分散的状态判断收拢到各自State子类里，但它的代价是类数量激增。真实项目里，5个以内状态、变更路径清晰、不常改，直接用switch + enum更轻量；超过7个状态、存在嵌套子流程（比如“审核中”又分初审/复审）、未来可能接入外部规则引擎，再上State模式。
容易踩的坑：Context对象持有State引用后，忘了在状态变更时更新引用；或者把业务逻辑全塞进State类，导致Context变成空壳，违背面向对象职责分离。
立即学习“Java免费学习笔记（深入）”；
-
State类只负责“这个状态下能做什么”，不负责“做完之后怎么通知别人”——那是Context的事 - 避免在
State方法里直接修改Context的其他字段，只调用Context提供的受控接口（如context.transitionTo(new PaidState())） - 如果状态变更需异步或跨服务，
State里不要写HTTP调用，应抛出StateTransitionEvent由外部监听
Spring State Machine适合复杂流程但启动成本高
当状态图带条件分支、需要持久化历史、支持暂停恢复、甚至要图形化配置，spring-statemachine是少有的靠谱选择。但它不是给单个Order对象用的，而是为整个“订单履约流程”建模，背后是状态机实例、事件队列、状态存储三件套。
典型误用：把StateMachine注入到每个OrderService方法里，每次操作都重建实例；或者用EnumStateMachine却手动维护StateMachinePersist，结果状态丢了没人知道。
- 必须配
PersistingStateMachineInterceptor，否则JVM重启后状态全丢 - 状态事件名用
Enum定义（如Event.CONFIRM_PAYMENT），别用字符串，避免StateMachine.send(Event.of("confirm_payment"))这种魔法值 - 调试时打开
logging.level.org.springframework.statemachine=DEBUG，关键日志在StateMachineLogger里，不是控制台默认输出
状态一致性最难的是并发和分布式场景
单机下用synchronized或ReentrantLock能拦住并发修改，但微服务里一个订单状态可能被支付服务、库存服务、物流服务同时读写。这时候setState不再是简单赋值，而是一次带条件的数据库更新。
最容易被忽略的点：乐观锁只防覆盖，不防业务逻辑冲突。比如两个请求都读到state = "PENDING"，都通过校验，然后一个想变"PAID"，一个想变"CANCELLED"，乐观锁版本号相同，都能成功提交。
- 数据库更新必须带状态前置条件：
UPDATE order SET state = 'PAID', version = version + 1 WHERE id = ? AND state = 'PENDING' AND version = ? - 应用层要检查
JDBC update count是否为1，不是1就说明状态已被他人改过，需重试或抛IllegalStateException - 跨服务状态协同别靠“查完再改”，要用Saga模式或本地消息表，确保最终一致
状态迁移看着只是改个字段，真正卡住人的永远是“谁在什么时候、以什么理由、能不能改、改完别人信不信”。没想清楚约束和边界，模式堆再多也救不了。
