状态机应显式引入cancelling和cancelled状态以精准管理请求取消，绑定AbortController到状态转换，统一通过CANCEL事件触发取消逻辑，并封装可中断Promise增强可控性与可测性。
在状态机中管理请求取消，核心是把“取消”当作一个明确的状态或状态转换事件，而不是仅依赖外部变量或副作用。关键在于让状态机本身感知并响应取消动作，同时确保请求发起、进行、完成、失败、取消各环节的状态流转清晰可追溯。
状态设计需包含取消相关状态
不要只用 idle、loading、success、error 四种状态。应显式引入：
- cancelling：用户触发取消，但请求尚未被中断（例如 fetch 还在传输中）
- cancelled：请求已确认终止（如 AbortSignal 触发 abort 事件，且 promise 已 reject 或被忽略）
这样状态机就能区分“正在取消”和“已经取消”，便于 UI 展示（比如显示“取消中…”或禁用重试按钮）。
将 AbortController 与状态转换绑定
每次发起请求时创建新的 AbortController，并将它的 signal 传入 fetch 或其他异步操作。更重要的是，在状态机 transition 中同步处理 signal 的生命周期：
立即学习“Java免费学习笔记（深入）”；
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 进入 loading 状态时，保存 controller 实例（如存入 state.context）
- 触发取消动作时，调用
controller.abort()，然后立即 transition 到 cancelling - 监听
signal.onabort或 catch 到AbortError后，transition 到 cancelled - 进入 success 或 error 时，自动清理 controller（避免内存泄漏）
用状态机事件统一收口取消逻辑
避免在组件任意位置直接调用 abort()。所有取消都应通过发送标准事件（如 { type: "CANCEL" }）触发状态机响应：
- 状态机在 loading 下收到
CANCEL，执行 abort 并跳转 cancelling - 在 cancelling 下再次收到
CANCEL可忽略，或记录重复取消日志 - 在 success/error/cancelled 下收到
CANCEL不做任何事（无效操作）
这种设计让取消行为可预测、可测试、可审计。
配合 Promise 封装增强可控性
原始 fetch 返回的 Promise 无法主动 resolve/reject，建议封装一层可中断的 Promise 工厂：
function cancellableFetch(url, options = {}) {
const controller = new AbortController();
const { signal } = controller;
return {
promise: fetch(url, { ...options, signal }).then(res => {
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return res.json();
}),
abort: () => controller.abort(),
controller
};
}
在状态机中调用 abort() 方法比直接操作 signal 更语义化，也方便 mock 和单元测试。
