每个线程的生命周期是一种非常危险的生活方式，一般来说你应该not在您的应用程序中使用它，尤其是 Web 应用程序。
这种生活方式应该被认为是危险的，因为很难预测线程的实际寿命。当您使用以下命令创建并启动线程时new Thread().Start()，您将获得一个新的线程静态内存块，这意味着容器将为您创建一个新的每线程实例。当使用线程池启动线程时ThreadPool.QueueUserWorkItem但是，您可能会从池中获得一个现有线程。在 ASP.NET 中运行时也是如此。 ASP.NET 池化线程以提高性能。
这意味着线程几乎总是比 Web 请求更长寿。另一方面，ASP.NET 可以异步运行请求，这意味着 Web 请求可以在不同的线程中完成。当使用“每线程”生活方式时，这是一个问题。当然，当您开始使用 async/await 时，这种效果会被放大。
这是一个问题，因为您通常会调用Resolve<T>在请求开始时一次。这将加载完整的对象图，包括使用每线程生活方式注册的服务。当 ASP.NET 在不同的线程中完成请求时，这意味着已解析的对象图将移动到此新线程，包括所有按线程注册的实例。
由于这些实例被注册为每个线程，因此它们可能不适合在另一个线程中使用。它们几乎肯定不是线程安全的（否则它们将被注册为单例）。由于最初启动请求的第一个线程已经可以自由地接收新请求，因此您可能会遇到两个线程同时访问这些 Per Thread 实例的情况。这将导致难以诊断和发现的竞争条件和错误。
所以一般来说，使用 Per Thread 是一个坏主意。相反，使用具有明确范围的生活方式（隐式或显式定义的开始和结束）。大多数 DI 框架实现的 Per Web Request 生活方式通常是隐式范围的（您不必自己结束它）。
具体到你的问题
更糟糕的是，您引用的博客文章包含配置错误。这ICatalogService定义为每线程生活方式。然而，这项服务取决于IDALContext服务，定义为短暂的。由于引用了IDALContext实例作为私有字段存储在CatalogService，这意味着DALContext只要ICatalogService做。这是一个问题，因为IDALContext定义为短暂的并且可能不是线程安全的。
生活方式的一般规则
一般规则是让组件仅依赖于具有相同或更长生命周期的服务。因此瞬态可以依赖于单例，但反之则不然。
由于每线程注册的组件通常会存活很长时间，因此它通常只能安全地依赖于其他每线程或单例实例。由于 ASP.NET 可以将单个请求拆分为多个线程，因此在 ASP.NET 应用程序（MVC、Web 窗体，尤其是 Web API）上下文中使用 Per Thread 并不安全。
