Javascript 插入/加载包含自注册组件的服务的正确位置是什么？

我正在开发一个AngularJS应用程序，它有一些自注册组件。具体来说，有些服务本身并不直接提供任何公共接口；它们只是在另一个服务提供的某个目录中注册一些内部对象

您可以想象这样一个服务工厂的主体如下：

var internalThing = {
    // members ...
};
thingRegistryService.registerThing(internalThing);

return {};

因此，我只需要确保在某个点加载服务

我面临的困境如下：由于该服务不提供公共功能，只需要“在那里”，因此没有理由将其注入任何地方。因为它不会被注入，所以它永远不会被实例化。但是，由于它从未被实例化，服务中的组件从未注册它们自己

我可以将服务注入到一些我知道会加载的服务或控制器中的通常位置，但之后，我基本上会在代码中留下一个未使用的参数（如果它是列表中的最后一个参数，甚至会根据项目的JSHint设置将其概括为错误）

或者，我可以在服务中的方法中进行自注册，并在注入服务的任何地方调用该方法。这将使服务注入变得“有用”，但反过来，我必须自己处理多个调用，而不是依赖AngularJS服务的内置单例机制

或者。。。我是否应该走另一条路，通过在某个地方提供类似于

registerThing

的方法，将服务名称作为字符串，并在内部调用

$injector.get

？当然，这再次引发了这样一个问题：打电话的正确地点在哪里

---

一点背景：这是一个大型团队开发的大型项目的一部分。构建和/或部署魔术以某种方式处理任何开发人员提交给我们的VCS的任何JavaScript代码文件将可用于AngularJS的依赖注入。因此，任何需要添加的JavaScript都必须作为某种AngularJS服务、控制器等提供

---

---

加载这种自注册服务的正确方法是什么？

初始化模块的正确位置是

angular.module（'yourModule'）。运行
block

在“自我注册”的情况下，我认为最好有一些隐式方法：

angular.module('yourModule').run(['service'], function (service) {
  service.init();
})

如果构建系统神奇地提供了所有JS代码，那么是否需要导入

构建系统建议的自注册体系结构不需要导入。导入JSHint错误就是这种魔力的代价

我在类似名称空间的设计中使用了类似的行为。它可以用于自注册技术，尽管导入会变得棘手，并且不能很好地与ES6模块配合使用

这接近我的观点：
这听起来是个不错的答案。我只有一个问题：“我认为最好有一些隐式的方法来解决这个问题”——为什么？当然，它会抑制JSHint消息，但除此之外，它似乎是多余的（自注册服务已经“需要”了，因为它被注入），甚至可能有轻微的危害（如果服务是各种模块所需要的，并且应该在第一次加载时注册，无论哪个模块是显式的
init（）
调用要求我添加自定义逻辑以确保初始化只发生一次，这将自动成为……注入延迟实例化的单例服务的情况。）“如果构建系统神奇地提供了所有JS代码，是否需要导入？”-如果“导入”指的是“注入”，那么。。。是的，我想是的。构建系统只是查找并添加所有JavaScripts文件。它不知道这些文件的内容以及这些文件中的服务之间的依赖关系。因此，构建系统无法以正确的顺序实例化服务。您链接的文章总结了“为每个组件描述一个工厂。（……）检查组中的每个项目并注册它。”-这正是声明AngularJS时所做的。。。。。。按照本文第一段代码中显示的方式提供服务。我不清楚“检查组中的每个项目并进行注册”如何解决注册这些项目的顺序很重要的问题。哦，我发现问题在于注册顺序，而不是简单的提示或导入。问题不在于我不能用Angular的依赖注入程序注册我的服务，然后在需要的地方注入它。这可能很好。问题是，我在任何地方都不“需要”具有自注册组件的服务（例如，我从不想直接调用该服务上的任何东西），因此我从不请求其注入，因此它从不被实例化（其中的组件从不注册自己）。强制执行自注册的最明智的一点是，只要要检索自注册组件。。。。。。但同时，这将破坏自注册（解耦！）组件的目的，因为检索服务随后必须知道具有此类自注册组件（=直接耦合！）的所有服务。