为何RSVP Deferred调用Promise两次会报错？两种写法差异解析

这个问题其实戳中了RSVP Deferred实现里一个容易被忽略的细节差异，我来帮你拆解清楚：

首先搞懂两种写法的本质区别 #

别小看这两种写法的差异，它们操作的根本不是同一个对象：

• deferred.promise.then().finally()：这是标准的Promise链式调用——每调用一次.then()或.finally()，都会返回一个全新的Promise实例。后续的方法都是挂载在这个新实例上的，完全不会修改原deferred.promise的状态或内部结构。
• deferred.promise.then(); deferred.promise.finally()：这是直接重复操作同一个原Promise实例，两次调用都是对着deferred.promise本身来加回调，这就踩中了RSVP的内部限制。

RSVP Deferred为什么会报错？ #

RSVP的Deferred实现和原生Promise的行为有一点区别：它的原Promise实例（就是deferred.promise）在第一次被调用.then()/.finally()这类方法后，会进入一个"已激活"的状态，而且内部可能做了严格的校验——比如不允许对同一个原实例重复注册回调，或者在状态变更后禁止再添加新的回调（虽然原生Promise完全允许这么做）。

举个具体场景：当你第一次调用deferred.promise.then()时，RSVP已经把这个Promise标记为"已处理"，当你再调用deferred.promise.finally()时，它内部的断言逻辑就会触发，认为你在重复操作一个已经被处理的Promise实例，于是抛出错误。

你提到的Deferred3修复思路是什么？ #

从你说的修复来看，Deferred3应该是通过规避直接重复操作原Promise实例来解决问题的，常见的实现思路有两种：

1. 每次获取promise都返回新的包装实例
   比如给Deferred加一个get promise()的访问器，每次调用都返回一个包装了原Deferred Promise的新Promise，这样两次调用deferred3.promise.then()和deferred3.promise.finally()时，操作的是两个独立的新Promise，它们都监听原Deferred的状态，但互相不干扰，自然不会触发RSVP的校验错误。伪代码大概是这样：

   class Deferred3 {
     constructor() {
       this._innerDeferred = RSVP.defer();
     }
     
     get promise() {
       // 每次都返回新的Promise，包装内部的deferred promise
       return new RSVP.Promise((resolve, reject) => {
         this._innerDeferred.promise.then(resolve).catch(reject);
       });
     }
     
     resolve(val) {
       this._innerDeferred.resolve(val);
     }
     
     reject(err) {
       this._innerDeferred.reject(err);
     }
   }
   

2. 修改原Promise的回调注册逻辑
   另一种思路是让原Promise兼容原生Promise的行为，允许在状态变更后重复注册回调，去掉RSVP内部的校验限制，这样不管是链式调用还是分开调用，都不会报错。

总结一下 #

• 链式调用没问题，是因为每次都生成新Promise，完全碰不到原Deferred Promise的限制；
• 分开调用同一个原Promise报错，是因为RSVP的实现不允许对同一个实例重复操作；
• Deferred3的核心修复逻辑就是避免直接重复操作同一个原Promise实例，要么包装出新实例，要么修改原实例的校验规则。

内容的提问来源于stack exchange，提问作者Charles