原型链状态机将通用逻辑（如transition方法）置于原型上，子实例仅存差异化配置（如rules、timeout），通过Object.create实现轻量继承，调用时自动沿原型链查找方法，规则与行为分离，内存占用低、创建销毁快、互不影响。

用原型链构建的高性能状态管理库，核心在于复用行为、隔离状态、极简实例。它不依赖 class 或复杂框架，而是靠 Object.create 建立轻量继承关系，把通用逻辑（如状态切换、超时控制、日志）统一放在原型上，每个具体状态机只保留自己的配置字段（如 rules、timeout、重试次数），内存开销小、创建销毁快、兼容性好。

原型链状态机怎么组织逻辑？

所有状态转移行为集中在基对象原型上，比如 transition(event) 方法：它通过 this.rules[this.state]?.[event] 查找目标状态，再更新 this.state。子实例无需重复写方法，只需提供自己的 rules 对象：

• loginSM.rules = { idle: { submit: 'validating' }, validating: { success: 'done', fail: 'idle' } }
• resetSM.rules = { idle: { request: 'sending' }, sending: { ok: 'success', error: 'idle' } }
• 调用 loginSM.transition('submit') 时，自动沿原型链找到基类的 transition，并用 loginSM 自身的 rules 和 state 执行

为什么它性能高？

关键在实例层几乎不存函数，只存差异化数据：

• 创建零开销：Object.create(baseSM) 不执行构造函数，也不复制方法体
• 内存占用低：实例只是普通对象，仅持有自有属性（如 timeout: 10000、maxRetries: 3）
• 销毁干净：垃圾回收器能立刻清理掉实例，无闭包或事件监听器残留
• 互不影响：改 loginSM.timeout 不会影响 formSM.timeout，因为它们是各自独立的自有属性

适合哪些场景？

特别适合需要大量短期、独立状态控制器的场合：

• 表单校验流程（每份表单一个独立状态机）
• 按钮点击防抖+加载+结果反馈的状态流转
• 动画帧控制器（不同动效对应不同规则集）
• 请求重试管理器（每个 API 调用配一套重试策略）

和主流库比有什么不同？

它不是替代 Redux 或 Zustand 的“全功能状态管理器”，而是一种底层机制设计范式：

• 不处理组件订阅、渲染优化、DevTools 集成等上层能力
• 专注解决“状态如何定义、如何迁移、如何复用”这一内核问题
• 可作为其他库的内部实现基础（比如 Zustand 的 store 创建、Reatom 的原子调度），也可直接用于轻量脚本或鸿蒙原生开发中的状态协调模块