在我看来，最好将它与其他脚本一起保留。
您应该对脚本进行捆绑、缩小和“永久缓存”。如果您这样做了，即使是对于站点的新用���，也只需要下载一个很小的文件。通过将其拆分成多个文件，您只会造成不便。最好让他们一次性下载您网站上所需的所有内容。
如果您有迥然不同的网站部分，且您不希望用户跨越这些部分，则可以考虑单独打包。例如，您的未经验证的部分和“仅限会员”的部分。即便如此，这也没有多大的区别，因此对于整个站点的结构而言，将它们捆绑起来可能更为合适（例如，“仅限会员”部分可能是一个不同的mvc区域）。
但是，仅仅因为并非每个页面都使用某个脚本而提取出局部脚本是徒劳无益的。
编辑：重新阅读后，我认为我更好地理解了。我之前说的话仍然适用，但要强调捆绑。不要仅为需要它的每个页面包含单个脚本引用。最好基本上将您网站所需的所有脚本捆绑在一起，并在每个页面上都包含它们。通过缓存，用户只需下载一次，然后在浏览您的网站时不再发出任何其他脚本请求，而不是每个页面都以需要下载的另一个独特脚本结束。
通过将引用放入局部视图的主体中，即可adhoc地加载JavaScript。这是一种正确的策略。您可以避免在所有其他页面上进行解析和解释的开销。即使您的JavaScript文件已缓存，仍然需要时间（尽管微不足道）来在包含它的每个页面上执行。如果其中有复杂的逻辑或迭代DOM，或者存在许多这样的文件怎么办？
实际上，这是成熟依赖性管理的第一步。如果您知道在哪个页面上使用了哪些功能，则以后的任何重构或维护工作都将更加廉价。
问题在于如何从局部视图中引用JavaScript资源。您不想只是在页面中间转储`
你的问题的答案可以从这个问题的答案中得出：
通常情况下，它是 Web 应用程序的一部分，因为你只会在这个 Web 应用程序中使用它。因此，从这个角度来看，没有必要将视图与其 JavaScript 捆绑在一起，因为 JavaScript 和视图都已经是 Web 应用程序的一部分。
当它们彼此相关且与其整体之外的任何其他内容无关时。我怀疑你为这个视图编写的 JavaScript 不依赖于它之外的任何东西。甚至没有 jQuery？甚至没有任何框架，例如 knockout 或 bob.js 吗？ 如果有，那么为什么不将你的视图与这些框架一起捆绑呢？
是的，答案就是——依赖关系。其中一些是实现，另一些则是依赖项。然而，在一个 Web 应用程序中使用部分视图时，实现和依赖项之间的边界变得模糊。原因是，部分视图是 Web 应用程序的一部分。这只是框架处理事物的一种方式，让您以可重用的方式分离部分视图。但是，部分视图仍然是整个 Web 应用程序的一部分，因此它的实现脚本也是如此。
如果您遵循了所有这些想法，那么您会同意在这种特殊情况下，无论您想要将代码与部分视图捆绑在一起，还是将其与 Web 应用程序的其他脚本捆绑在一起，都没有关系。 这只是同一件事。
因此，决策必须由其他指标来决定，例如脚本加载性能等。这超出了问题的范围，但提供的描述应该足以作为答案。
