重申一下我认为OP的问题真正是什么:

如果我主要用Angular 1构建应用程序。在Grunt/Gulp/Broccoli和Bower/NPM时代(隐式地)这样做，并且我可能有一些额外的库依赖，Require是否比我使用Angular不使用Require所获得的价值更清晰、更具体?

或者换句话说:

“如果我有其他处理基本脚本加载的方法，那么普通的Angular是否需要Require来有效地管理基本的Angular组件加载呢?”

我相信最基本的答案是:“除非你有别的事情要做，或者你不能使用更新、更现代的工具。”

让我们从一开始就明确一点:RequireJS是一个很棒的工具，它解决了一些非常重要的问题，并让我们走上了一条更可伸缩、更专业的Javascript应用程序的道路。重要的是，这是许多人第一次接触到模块化的概念以及将事物从全局范围中解脱出来的概念。如果你要构建一个需要伸缩的Javascript应用，Require和AMD模式都是不错的工具。

但是，Angular中有什么特别的地方让Require/AMD特别适合它吗?不。事实上，Angular为你提供了它自己的模块化和封装模式，这在很多方面使AMD的基本模块化特性变得多余。而且，把Angular模块集成到AMD模式中也不是不可能，但是有点……挑剔。您肯定会花时间将这两个模式很好地集成起来。

Angular团队本身的一些观点是这样的，来自Angular Batarang的作者，现在是Angular核心团队的一员Brian Ford:

我不推荐AngularJS使用RequireJS。虽然这当然是可能的，但我还没有看到RequireJS在实践中有任何好处的实例。

所以，关于AngularJS这个非常具体的问题:Angular和Require/AMD是正交的，在某些地方是重叠的。你可以把它们一起使用，但这与Angular本身的性质/模式没有特别的关系。

但是如何对可伸缩Javascript应用程序的内部和外部依赖关系进行基本管理呢?难道Require没有为我做一些非常重要的事情吗?

我建议你看看Bower和NPM，尤其是NPM。我并不是要开始一场关于这些工具的相对好处的圣战。我只是想说:还有其他方法来剥那只猫的皮，这些方法可能比AMD/Require更好。(它们在2015年末肯定会更受欢迎，特别是NPM，结合ES6或CommonJS模块。参见相关SO问题。)

那么惰性加载呢?

Note that lazy-loading and lazy-downloading are different. Angular's lazy-loading doesn't mean you're pulling them direct from the server. In a Yeoman-style application with javascript automation, you're concatenating and minifying the whole shebang together into a single file. They're present, but not executed/instantiated until needed. The speed and bandwidth improvements you get from doing this vastly, vastly outweigh any alleged improvements from lazy-downloading a particular 20-line controller. In fact, the wasted network latency and transmission overhead for that controller is going to be an order of magnitude greater than the size of the controller itself.

但是，假设您确实需要惰性下载，也许是应用程序中不经常使用的部分，比如管理界面。这是一个非常合理的案例。Require确实可以为你做到这一点。但也有许多其他可能更灵活的选择来完成同样的事情。Angular 2.0显然会帮我们解决这个问题，它内置在路由器中。(细节)。

但是在我的本地开发boxen上进行开发时呢?

我如何才能得到我所有的几十/数百个脚本文件加载，而不需要将它们都附加到index.html手动?

Have a look at the sub-generators in Yeoman's generator-angular, or at the automation patterns embodied in generator-gulp-angular, or at the standard Webpack automation for React. These provide you a clean, scalable way to either: automatically attach the files at the time that components are scaffolded, or to simply grab them all automatically if they are present in certain folders/match certain glob-patterns. You never again need to think about your own script-loading once you've got the latter options.

底线?

Require对于某些事情来说是一个很好的工具。但只要有可能，就顺其自然，尽可能把你的关注点分开。让Angular担心自己的模块化模式，考虑使用ES6模块或CommonJS作为通用的模块化模式。让现代自动化工具来操心脚本加载和依赖关系管理。以细粒度的方式处理异步延迟加载，而不是将其与其他两个问题纠缠在一起。

也就是说，如果你正在开发Angular应用，但由于某些原因不能在你的机器上安装Node来使用Javascript自动化工具，那么Require可能是一个很好的替代解决方案。我也见过一些非常复杂的设置，人们想动态加载Angular组件，每个组件都声明了自己的依赖项之类的。虽然我可能会尝试用另一种方式解决这个问题，但我可以看到这个想法的优点，在这种非常特殊的情况下。

但除此之外……当你从头开始创建一个新的Angular应用程序，并灵活地创建一个现代自动化环境时……你还有很多其他更灵活、更现代的选择。

(不断更新，以跟上不断发展的JS场景。)

正如@ganaraj提到的，AngularJS的核心是依赖注入。在使用和不使用RequireJS构建玩具种子应用程序时，我个人发现RequireJS对于大多数用例来说可能是多余的。

That doesn't mean RequireJS is not useful for it's script loading capabilities and keeping your codebase clean during development. Combining the r.js optimizer (https://github.com/jrburke/r.js) with almond (https://github.com/jrburke/almond) can create a very slim script loading story. However since its dependency management features are not as important with angular at the core of your application, you can also evaluate other client side (HeadJS, LABjs, ...) or even server side (MVC4 Bundler, ...) script loading solutions for your particular application.

简单地说，这是有道理的。最近，ng-conf 2014讨论了这个问题。下面是关于这个话题的演讲:

http://www.youtube.com/watch?v=4yulGISBF8w

是的，在Angular中使用requireJS是有意义的，我花了几天时间来测试几个技术解决方案。

我在服务器端用RequireJS做了一个Angular种子。非常简单。 我使用SHIM符号表示没有AMD模块和没有AMD，因为我认为处理两个不同的依赖注入系统非常困难。

我使用grunt和r.js来连接服务器上的js文件，这取决于SHIM配置(依赖)文件。所以我只在我的应用程序中引用一个js文件。

欲了解更多信息，请访问我的github Angular Seed: https://github.com/matohawk/angular-seed-requirejs

是的，这很有道理。

Angular模块不会尝试解决脚本加载顺序的问题 或者惰性脚本抓取。这些目标是正交的，都是模块 系统可以共存并实现它们的目标。 来源:Angular JS官方网站

布莱恩·福特的回答

AngularJS有自己的模块系统，通常不需要RJS之类的东西。

参考:https://github.com/yeoman/generator-angular/issues/40