这些只是一般性建议。

我应该如何设计我的应用程序和小部件-我应该有一个单独的AngularJS模块还是每个小部件都应该是主模块的指令？

您正在谈论数以百计的小部件，将它们分成几个模块似乎很自然。某些小部件可能比其他小部件具有更多共同点。有些可能很笼统并适合其他项目，有些则更具体。

如果我将小部件设计为指令，是否可以在指令中定义依赖关系。也就是说，我的指令在其实现中使用ng-calender？

依赖于其他模块的模块级完成的，但如果模块没有问题A取决于模块B和两个A并B取决于模块C。指令是在Angular中创建窗口小部件的自然选择。如果一个指令依赖于另一个指令，则可以在同一模块中定义它们，或者在模块级别上创建依赖关系。

如果我将每个小部件设计为一个单独的模块，是否可以动态添加小部件模块作为对主模块的依赖关系？

我不确定您为什么要这样做，也不确定如何执行。在Angular中使用指令和服务之前，不会对其进行初始化。如果您有一个庞大的指令库（小工具），并且知道您可能会使用其中的一些（但不是全部），但是您不知道初始化应用程序时将使用哪些指令，您实际上可以“懒惰”加载模块后，加载”指令。我在这里创建了一个例子

这样做的好处是，即使有很多代码，也可以使应用程序快速加载，因为在需要脚本之前不必加载脚本。缺点是第一次加载新指令时可能会有相当大的延迟。

我应该如何设计控制器-每个小部件一个控制器？

小部件可能需要其自己的控制器。控制器通常应该较小，如果它们变大，则可以考虑是否有任何功能更适合服务。

如果视图中有多个相同类型的小部件，应该如何区分状态（范围）？

毫无疑问，需要范围变量的小部件应该具有自己独立的范围（scope:{ ... }在指令配置中）。

有使用AngularJS设计可重用小部件的最佳实践吗？

隔离范围，将依赖项保持在必要的最低限度。观看Misko的有关Angular最佳做法的视频

布赖恩·福特（Brian
Ford）也写了一篇文章，内容涉及在Angular中编写大型应用