请求发出去了，不代表只能硬等。AbortController负责发出“取消”指令，AbortSignal负责把这句话传给支持它的异步API。fetch、响应… · @BaiBtw · TwKit

@BaiBtw

请求发出去了，不代表只能硬等。AbortController负责发出“取消”指令，AbortSignal负责把这句话传给支持它的异步API。fetch、响应体读取、流都能接这套机制；它不是给任意Promise装个万能刹车。 三种用法，别混成一团： • 手动取消：新建控制器，把它的signal传进fetch，用户点取消时调用控制器的abort()。 • 超时取消：AbortSignal的timeout(5000)生成一个5秒超时信号，直接作为fetch的signal选项。 • 多条件取消：AbortSignal的any()把多个信号合成一个，任意一个取消，组合信号就取消。比如“用户点取消”与“等待超时”，谁先到就触发。 下载视频是个直观例子：每次点击下载都创建新控制器，下载按钮启动fetch，取消按钮调用abort()。默认手动取消会让fetch以AbortError拒绝；单独使用超时信号时，超时对应TimeoutError，别把它和网络故障一锅端。 两处坑挺容易漏： 1. 信号一旦取消就不能复活。拿已取消的signal再发fetch，会立即被拒绝。还有，fetch已返回响应，不代表响应体读完了；这时取消，后面的读取仍可能抛AbortError。 2. 自己加的abort监听器，fetch不会替你收拾。once: true只在事件真正触发后移除；任务正常完成而没取消时，监听器可能还挂着。给监听器起名，在finally里移除，成功失败都收尾。 自己写可取消API也一样：先检查是否已取消，再监听取消事件，停止尚未完成的工作，并用取消原因拒绝Promise；正常完成时清理监听器。 控制器和信号已广泛支持，但any、timeout等新方法各有兼容范围，不能拿“支持AbortController”当整套能力都到齐了。取消机制省的是失控等待，不是错误处理和清理逻辑。

曝光 19 · 评论 1 · 点赞 1 · 书签 0