据我了解，CoreModule 的原因是拥有初始化应用程序所需的所有东西，并且还拥有要在应用程序中的所有模块之间共享的服务（HttpInterceptors、AuthenticationService 等）。现在我们有了provideIn: 'root'，还有理由再拥有CoreModule 吗？这种模式现在被弃用了吗？是否存在我们仍然希望拥有一个包含所有或部分共享服务的CoreModule 的用例？
【问题讨论】：
providedIn 功能没有必要。
您可以查看 Angular 风格指南：https://angular.io/guide/styleguide#core-feature-module。
一个原因是概念的分离，coreModule 必须只有模块、提供程序、组件，其他应该只在 appModule 中，而不是在应用程序的任何其他模块中。这也可以帮助您使您的应用模块更清洁。
这里可以设置HttpClientModule、HTTP_INTERCEPTORS、BrowserAnimationsModule等。
您还可以查看我的项目，其中我实施了 Angular 样式指南建议，例如核心模块：here
【讨论】：
根据this answer，没有。 Here is a PR with some more discussion:
@jenniferfell @brandonroberts 仅供参考。 @jenniferfell 我们删除了CoreModule 作为推荐技术，因为现在提供服务的首选方式是使用providedIn，但是@bisonfoutu 有一个很好的观点。我认为这个问题的焦点可能最适合作为功能模块或 SharedModule 部分的样式指南点，但我很想听听团队和社区的意见。
在同一期中，John Papa 解释了why you might still want to use it：
这都是很好的反馈。现在可以使用
providedIn在根目录中提供服务，这样可以更轻松地将服务放在需要的地方。然而，CoreModule 从来没有打算成为一个放置只应在子 ngmodule 中定义和使用的服务的地方。以下是我对此的看法，还有一些问题需要考虑。
我的领域是考虑应用范围内的服务。不是仅在子 ngmodule 中使用的。需要在子模块中定义的应用程序范围内的服务呢？让我们暂时搁置。
首先 - 根目录中的应用程序范围的东西...
- 当您有十几个服务供整个应用使用时，您真的想在整个应用程序中声明它们还是在一个地方声明它们？
- 如果#1 的答案是“是”，那么那个地方会是
AppModule吗？如果是这样，您是否愿意在其中定义十几个？可能。- 这些应用范围的服务在其他应用中是否有用？如果是这样，核心模块可以更容易地测试和找到这些。 CoreModule 在这里提供帮助
- 这些应用程序范围的服务是否可以通过 npm 库成为其他应用程序的良好候选者？如果是这样，我可能会建议一个 npm 模块而不是一个特定模块（通过 Angular CLI）
我确实认为 CoreModule 对于组织目的有一些价值。 （见上文）
但是......子模块需要的服务以及其他一些可能需要的服务呢？你能在子模块中定义它吗？好吧，你可以......让我们来看看。假设我们有一个 Customer ngmodule，我们定义了一个
CustomerService来获取和放置客户数据，它使用providedIn到根。现在另一个模块需要客户数据。您仍然可以在其他 ngmodule 中使用它，假设它处理订单。因此，ngOrders 模块现在使用根中提供的服务，但存在于客户模块中。这行得通。但是清楚吗？可读吗？基于这个新场景的新问题...... OrdersModule 的延迟加载现在如何工作，因为它依赖于 CustomersModule 中的服务（在根目录中提供）？是否令人困惑？如果您在另一个应用程序中重复使用 OrdersModule 会发生什么？它有一个你现在需要追踪的依赖项？
IMO - 任何应用范围内的“东西”都应该很容易找到。因此，CoreModule 的概念（虽然不是名称）仍然有效，我仍然使用它。
希望这会有所帮助:)
我认为，关键的一点是，是否使用核心模块取决于您自己，但您确实希望确保不会将服务包含在多次重新导入的共享模块中，因为这将重新实例化它们。
【讨论】：