在导入Ditsmod模块的过程中，在这些模块中，可能存在两个（或更多）模块，这些模块可以导出具有相同令牌的非相同提供者。例如，具有令牌服务的提供商可以同时从两个模块导出到当前模块，在这种情况下，开发人员可能不知道将使用哪个版本的提供商。为了避免这种歧义，Ditsmod抛出了错误。

在导入第三方模块时，此功能特别有用，并且您没有控制进口顺序的能力。现在，让我们仔细看看何时发生碰撞时。

想象您有Module3在其中导入Module2和Module1。您之所以进行此导入，是因为您分别需要这些模块的Service2和Service1。您正在查看这些服务的工作原理，但是由于某种原因，Service1无法正常工作。您开始调试，事实证明Service1导出了两个模块：Module2和Module1。您希望Service1仅从Module1导出，但是从Module2导出的版本实际上可以工作。

为了防止这种情况发生，如果您导入了两个或多个以相同令牌导出的模块，ditsmod将丢下以下错误：

错误：将提供程序导入Module3失败：来自Module2和Module1的导出导致Service1碰撞。如果在您的应用程序中声明了Module3（它不是从Node_modules导入的），则应在此模块中将Service1添加到ResolvedCollisissper*。例如：ResolvedCollisisionSperreq：[[Service1，Module1]]。

在这种情况下特别是：

1. Module2替换，然后用令牌Service1;
出口提供商
2. 和Module1替换，然后用令牌Service1;
出口提供商
3. 具有令牌Service1的提供商在Module2和Module1中并不相同，例如，Module2的ie可以导出，例如object { token: Service1, useValue: {} }，并且可以从Module1Service1导出为类。
。

并且由于这两个模块都将其导入到Module3中，因此导致“提供商的碰撞”，因为开发人员可能不知道这些替代方案中的哪一个将在Module3中使用。

碰撞解决方案

如果在您的应用程序中声明了Module3（不是从node_modules导入），则通过添加到resolvedCollisionsPer*的两个元素来解决碰撞，首先是提供商的令牌，并且提供商需要从中获得的模块。被第二名：

```ts {6}
导入{module1，service1}来自'./module1';
导入{module2}来自'./module2';

@featuremodule（{
导入：[Module2，Module1]，
ResolvedCollisisionSperreq：[[Service1，Module1]]
}）
导出类模块3 {}

If you have installed `Module3` using packages manager (npm, yarn, etc.), there is no point in modifying this module locally to resolve the collision.

This situation can only occur if `Module2` and `Module1` are exported from the root module, so you need to remove one of these modules from there. And, of course, after that you will have to explicitly import another module into those modules where it is needed.