原文链接：http://docs.autofac.org/en/latest/lifetime/index.html
Lifetime 是指服务的实例在程序中存活多久 – 从最初的实例化到清理（disposal）。例如，一个实现 IDisposable 的对象，它的生命周期就是从实例化时开始，持续到调用它的 Dispose 时结束。(未主动调用 Disopose 则持续到被GC收集时)。
Scope 是指程序中的一块区域，在此区域内，服务可以被使用它的组件共享。例如，程序中全局的静态的单例对象，它的范围是整个程序。而在for循环里创建的本地变量，它的范围就要小的多。
Autofac 中的生命周期范围（lifetime scope）组合了这两个概念。实际上，可以把生命周期范围与应用程序中的工作单元等同起来。在工作单元的开始时创建生命周期范围，工作单元需要的服务从这个生命周期范围解析获得。解析服务时，Autofac 会跟踪实现 IDisposable 接口的组件。在工作单元结束时，清理（Dispose）生命周期范围，实现 IDisposable 接口的组件会同时被清理。
生命周期范围控制共享和清理：
- 生命周期范围是可嵌套的，这控制组件如何被共享。例如，单例服务可以从根生命周期范围解析，而其他服务，则由各个工作单元请求自己的实例，在注册组件时，可以通过设置实例范围指定组件如何被共享。
- 生命周期范围跟踪实现 IDisposable 接口的对象，这些对象随生命周期范围一起被清理。服务的使用者不需要了解底层实现。
编写程序时，了解这些概念有助于有效使用资源。
应始终从生命周期范围解析服务，而不是从根容器解析，这一点非常重要。由于生命周期范围对 IDisposable 处理方式，如果从容器(根生命周期范围)解析 IDisposable 对象,则可能不小心导致内存泄露。在根容器被清理前，它将一直持有对 IDisposable 对象的引用。
以下是一个具体的 web 示例，假设有以下场景：
- 程序中有一个全局的单例日志服务。
- 两个请求同时到达。
- 每个请求是一个逻辑上的“工作单元”，需要各自独立的订单处理服务。
- 每个订单处理服务都需要使用日志服务来打日志。
在这个场景中，根生命周期范围（容器）包含单例日志服务，每个请求对应一个子生命周期范围, 包含各自的订单处理服务：
+---------------------------------------------------+ | Autofac Container | | Root Lifetime Scope | | | | Logging Service | | (shared across all requests) | | | | +----------------------+ +----------------------+ | | | First Request Scope | | Second Request Scope | | | | | | | | | | Order Processor | | Order Processor | | | +----------------------+ +----------------------+ | +---------------------------------------------------+
请求结束时，订单处理服务将随生命周期范围一同被清理。而日志服务是单例服务，将继续存活，供后续的请求使用。