这个 resolver 只针对 Proxy Facade，依据 feature 名称和 FacadeClass，获取对应的 resolver. 该 resolver 晓得怎么将函数调用，投递到该 facade 的具体实现类去。

featureName：cartQuickOrderCore

最初失去理论值：cartQuickOrder

返回 resolver 的逻辑放在一个 defer 函数块里了：

当应用程序开始调用 facade 的办法时，被投递到代理类：

此时 resolver$ 蕴含的一大段在 defer 里的逻辑始终未失去执行。

所以，从语义上说，resolver 解析进去的对象，就是该 facade 实在的实现类？这个 connect 应该相当于 subscribe 办法。

果然，connect 办法会触发 defer 块内的函数调用：

触发 core module 提早加载：

加载完 QuickOrderModule 之后，从 ModuleRef 里拿到 injector，再调用这个 module 的 injector，拿到 facadeClass 对应的实现类：

功败垂成，拿到实现类 QuickOrderService 了：

此时就能够调用该实现类的办法了：

总结

Resolver 负责触发 Proxy Facade 对应的具体实现类的提早加载，加载实现后，从 Module Ref 里拿到 injector，再应用 injector 拿到 Proxy Facade 的具体实现类的实例。

更多 Jerry 的原创文章，尽在：” 汪子熙 ”: