计算属性名不是重构状态机的直接工具，它属JS/TS语言特性，无法改变Qt/BPMN等静态环境中的状态流转；真正有效的是提取状态枚举与转换表、解耦UI响应、引入DSL配置。
计算属性名本身不是重构状态机的直接工具，它属于 JavaScript/TypeScript 语言特性，而 legacy 遗留系统中的流式状态机（如 Qt QStateMachine、.NET Workflow Foundation、BPMN 引擎或自定义 C++/C# 状态流转逻辑）通常运行在静态类型、编译期绑定或 XML/DSL 驱动的环境中。因此，“用计算属性名重构”这个说法存在概念错位——它不能直接用于 Qt 的 QState 添加转换，也不能改变 BPMN 文件中 <bpmn:transition> 的 targetRef 属性。
先厘清：什么是“计算属性名”？
它指在对象字面量或类中使用方括号语法动态生成键名，例如：
const prefix = 'on';
const events = {
[`${prefix}Click`]: () => handle('click'),
[`${prefix}Hover`]: () => handle('hover')
};这种写法适用于配置驱动、事件映射、策略注册等场景，但不适用于声明状态机结构本身——因为状态机的核心是**状态节点之间的有向关系**，而非属性键的动态拼接。
真正有效的重构路径：从“if-else 地狱”走向可维护状态流
针对 legacy 系统中散落在按钮槽函数、消息处理器或 if-else 链里的状态逻辑，应聚焦三类可落地的改进：
-
提取状态定义为显式枚举 + 转换表：把原来硬编码在条件分支里的状态跳转，整理成二维映射（当前状态 × 触发事件 → 下一状态），例如：
const transitionTable = {<br> Idle: { start: 'Running', pause: 'Idle' },<br> Running: { pause: 'Paused', stop: 'Stopped' },<br> Paused: { resume: 'Running', stop: 'Stopped' }<br>};
这样既避免重复判断，又便于导出为 JSON 进行可视化或校验。 -
将 UI 响应与状态解耦：不再让
onStartButtonClicked()同时负责业务执行和界面更新，而是统一由状态进入（entered）信号触发 UI 刷新，例如 Qt 中：stateRunning->assignProperty(ui->startBtn, "enabled", false);<br>stateRunning->assignProperty(ui->statusLabel, "text", "运行中");
-
用 DSL 或配置文件替代硬编码状态图：对老旧 C++/C# 系统，可引入轻量 YAML 描述状态机拓扑，启动时解析并构建
QState或StateActivity对象树。这比手写几十个addTransition()更易测试、回滚和协同。
什么时候可以“用上”计算属性名？
它只在以下辅助环节起作用：
- 构建状态机运行时的事件分发器：根据当前状态和用户动作，动态调用对应处理函数；
- 为调试面板生成实时状态映射表（如把
StateId::kRunning映射为中文“运行中”）； - 在 TypeScript 封装层中，将 legacy C++ 导出的状态码自动转为带语义的属性访问器（如
machine.stateName返回计算后的字符串）。
归根结底，重构 legacy 状态机的关键不是语法技巧，而是把隐性状态逻辑显性化、结构化、可验证。计算属性名只是配角，真正的主角是状态图建模意识和分层解耦设计。
