Unter welchen Umständen muss ich ein Versprechen widerrufen?
Promise 的设计就是一个状态机，pending 到 resolve / reject 的状态变换是单向且唯一的，没有所谓的 cancel 状态。cancel 的加入会带来更多的状态问题，并不适合 Promise 这一模式来处理（这类场景下，RxJS 这类 FRP 的方案应该更为适合）。
cancel 会带来什么状态问题呢？拿电商的退款来举例子。你买了一个东西（开始一个 pending 的 promise），然后东西还没收到（还没 resolve），你后悔了，点击了退款（把状态改为 cancel），但这时退款流程也不能立刻生效，需要审核（cancel 后不能立刻 reject），那这时候你发工资了，又不想退款了，又点了【取消退款】，这时候又是一个异步的状态更改（把 cancel 再 cancel 掉），而【取消退款】也是异步的，你还能取消【取消退款】的操作（把 cancel 在 cancel 掉前再 cancel 掉？）别忘了，这时候每一步状态变化还都可以对应到 resolve 和 reject 呢。好的同学们，接下来请画出流程的状态变化图，并编码实现这个支持 cancel 的 promise
比如页面需要1分钟刷新一次，但是接口特别慢，所以导致我下次发送请求的时候，上次的请求还没有回来，在这种情况下我就想取消上次的请求。
比如点赞，取消点赞操作 如果是使用promise当你误点赞了你想点取消赞时， 你就必须等点赞操作结束才能操作所以有了加强版的promise → observable
同时进行两个操作（两个Promise），其中一个完成了就把另一个取消掉，最后返回先成功的结果。
但是取消都是坑，例如多线程做取消意味着异步异常，就是操作到一半突然被完全打断，不给一点恢复的机会（不然取消就没意义了），所以也没有方法进行恢复或者回滚。只有纯CPU的独立的计算任务才能安全地取消。
至于取消然后取消“取消”是不会有的，规矩进入cancel状态（半死不活状态）就不能切换到其他状态就行了。
Promise 的设计就是一个状态机，pending 到 resolve / reject 的状态变换是单向且唯一的，没有所谓的 cancel 状态。cancel 的加入会带来更多的状态问题，并不适合 Promise 这一模式来处理（这类场景下，RxJS 这类 FRP 的方案应该更为适合）。
cancel 会带来什么状态问题呢？拿电商的退款来举例子。你买了一个东西（开始一个 pending 的 promise），然后东西还没收到（还没 resolve），你后悔了，点击了退款（把状态改为 cancel），但这时退款流程也不能立刻生效，需要审核（cancel 后不能立刻 reject），那这时候你发工资了，又不想退款了，又点了【取消退款】，这时候又是一个异步的状态更改（把 cancel 再 cancel 掉），而【取消退款】也是异步的，你还能取消【取消退款】的操作（把 cancel 在 cancel 掉前再 cancel 掉？）别忘了，这时候每一步状态变化还都可以对应到 resolve 和 reject 呢。好的同学们，接下来请画出流程的状态变化图，并编码实现这个支持 cancel 的 promise
比如页面需要1分钟刷新一次，但是接口特别慢，所以导致我下次发送请求的时候，上次的请求还没有回来，在这种情况下我就想取消上次的请求。
比如点赞，取消点赞操作
如果是使用promise当你误点赞了你想点取消赞时， 你就必须等点赞操作结束才能操作
所以有了加强版的promise → observable
同时进行两个操作（两个Promise），其中一个完成了就把另一个取消掉，最后返回先成功的结果。
但是取消都是坑，例如多线程做取消意味着异步异常，就是操作到一半突然被完全打断，不给一点恢复的机会（不然取消就没意义了），所以也没有方法进行恢复或者回滚。只有纯CPU的独立的计算任务才能安全地取消。
至于取消然后取消“取消”是不会有的，规矩进入cancel状态（半死不活状态）就不能切换到其他状态就行了。