这篇文章记录了我在工作中犯的一个错误。如下图，我在构造函数中注入了一个新的依赖：protectedcheckoutService:CheckoutService当同时满足以下条件时，客户会遇到编译错误：(1)客户已经升级到新的minorversion，也就是我引入的这个新依赖的版本。(2)客户端在之前扩展了CheckoutDeliveryService(3)客户端在自己扩展类的构造函数中调用了父类的构造函数super。因为客户端是老版本升级的，我的新版本引入的checkoutService入参没有在构造函数中传入，所以会遇到语法错误。正确的做法如下图所示：)protectcheckoutService?:CheckoutService){}使用@Optional修饰这个新引入的构造函数入参。同时代码中的逻辑也需要改动，需要同时处理checkoutService为空或者不为空的情况。protectedisCheckoutDetailsLoading$:Observable=this.checkoutService?this.checkoutService.isLoading():this.checkoutStore.pipe(select(CheckoutSelectors.getCheckoutLoading));如果checkoutService不为空，则使用checkoutService.isLoading返回的Observable；否则，对于旧版本的情况，使用旧版本的实现从checkoutStore中获取结帐加载的读取状态。服务代码修改后，相应的单元测试代码也会受到影响。今天的isSetDeliveryModeBusyflag，决定它值的第二个输入条件，已经从checkoutService.isLoading变成了isCheckoutDetailsLoading。因此，在单元测试代码中，我们需要创建一个全局的isCheckoutLoading$Observable对象：然后创建一个mockCheckoutService类，在内部返回这个全局的isCheckoutLoading$Observable对象。这样，每当我们需要修改CheckoutService.isLoading的返回值时，就可以通过调用isCheckoutLoading$的next方法灵活控制。重要的是要强调保持大型API的稳定性是一项挑战。如果您要更改API库，请考虑更改的广泛影响，并尝试预测可能出现的任何问题。更多杰瑞原创文章在这里：《王子熙》。
