这个 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 的具体实现类的实例。

我们在 Windows10 安装 git 客户端之后，注意到安装文件夹下有 git-bash.exe 和 git-cmd.exe 两个执行文件。有什么区别吗？

参考这个 StackOverflow 讨论链接.

Git CMD 就像带有 git 命令的常规 Windows 命令提示符。 它允许您通过命令行使用所有 Git 功能。 如果您已经熟悉 Windows cmd 并且您只在 Windows 上工作，则很有用。

Git Bash 在 Windows 上模拟 bash 环境。 它允许您在命令行中使用所有 git 功能以及大多数标准 unix 命令。 如果您习惯了 Linux 并希望保持相同的习惯，则很有用。

git bash

Git 的核心是一组命令行实用程序，旨在在 Unix 风格的命令行环境中执行。 Linux 和 macOS 等现代操作系统都包含内置的 Unix 命令行终端。 这使得 Linux 和 macOS 在使用 Git 时成为互补的操作系统。 Microsoft Windows 使用 Windows 命令提示符，一种非 Unix 终端环境。

Git Bash 是一个适用于 Microsoft Windows 环境的应用程序，它为 Git 命令行体验提供了一个模拟层。 Bash 是 Bourne Again Shell 的首字母缩写词。 shell 是一种终端应用程序，用于通过书面命令与操作系统交互。 Bash 是 Linux 和 macOS 上流行的默认 shell。 Git Bash 是在 Windows 操作系统上安装 Bash、一些常见的 bash 实用程序和 Git 的包。

例如，下面这个 run.sh 是一个 bash 脚本文件：

无论是 windows cmd 还是 powershell，都无法直接运行 bash 脚本文件，错误如下图所示：

然而通过 git bash 可以在 Windows10 机器上无障碍的运行 bash script：