原型链状态机将通用逻辑（如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 的原子调度），也可直接用于轻量脚本或鸿蒙原生开发中的状态协调模块
