本文作为学习的感悟记录，阅读本文之前需要熟读相关的官方文档。

declearable（components, directives, pipes）的作用域由NgModule来控制，而service的作用域由分层依赖注入机制来控制。
每一个component实例都有一个注入器，因此一个component tree对应了一个与之平行的injector tree。相关文档

组件的注入器可能是一个injector tree中更高级的祖先注入器的代理（如果某个component本身没有providers），但这只是提升效率的实现细节，我们不用在乎这点差异，在你的脑海里只要想象成每个组件都有自己的注入器就可以了。

我们可以将provider注册在module injector中，也可以注册在injector tree的某一个节点上。相关文档

NgModule的providers注册的顺序:先注册imported modules中的providers（按照imports数组中的顺序），再注册NgModule.providers数组中的provider，如果注册了重复的provider token，后注册的覆盖先注册的。相关文档
@Injectable的作用是在编译时让TypeScript编译器将constructor中的依赖信息保存在class metadata中，运行时注入器通过metadata中的信息来决定注入什么。如果service1需要在constructor中注入service2但service1却没有任何装饰器，那么TypeScript编译器就不会保存service1的依赖信息，那么在运行时创建service1的时候就会报错(注入器不知道要注入什么)。相关文档
除了可以用被注入的class本身或InjectionToken作为Provider token以外，使用class-interface也能获得诸多好处（为编辑器提供editor tooling，narrowing interface有助于解耦，占用资源少，可以用来注入父组件）。
如果attribute directive被应用在component element上时（<my-component my-directive1 my-directive2></my-component>）这些指令与组件共用同一个注入器。因此我们可以用attribute directive的providers array来"扩展"compoent的providers array。这篇文章将attribute directive与component之间的协作写得很清楚了。

还有很多细节没有搞清楚，比如：

@Host究竟能查找到哪一个注入器（其表现与官方文档说明的不太一样，经过实验发现它能找到parent element上注册的providers、parent component上的viewProviders，却找不到parent component上的providers，存在transclusion的时候又复杂一些）
为什么在同一个element上的component、directive能共用同一个注入器
注入PlatformRef,ApplicationRef,NgModuleRef,Injector得到的对象中都有与injector相关的属性，这些injector有什么联系。
如果有一个directive挂载在一个普通element上，并且这个directive有providers数组，那么是否会在这个element上创建一个新的injector。
对于一个component来说，它的host element和host component分别是什么。
这些问题目前还没有在网上找到答案，可能需要研究源码才能解答了。

参考资料

Angular 依赖注入难点整理