我熟悉链接CSS与嵌入式和内联的可维护性和模块性的好处。但是，我已经读到，在web dev的某些移动应用程序中，嵌入甚至内联CSS可能是有益的（更快的性能）。 我会避免任何内联JS，以及较小程度上的CSS，但我注意到许多网站，包括大量的谷歌页面，JS嵌入在页面标题中。
我的一位同事坚持总是链接到外部js文件。我认为如果函数特定于一个页面或每页略有不同，嵌入js更有意义，以节省链接脚本的处理开销。
答案 0 :(得分：5)
其他答案没有触及的一点是开发人员效率。如果更容易将其内联，并且没有立即的性能要求/关注，那么就这样做。 “简单”具有真正的商业价值，它胜过最终或不存在的性能问题。不要过早优化。
答案 1 :(得分：3)
链接脚本会以对服务器的额外请求的形式产生一些小的惩罚。如果您将其保持内联，则不会发出此请求，并且根据具体情况，您可能会获得更快的加载页面。在以下情况下内联代码是有意义的：
在google和facebook的情况下，你最有可能看到内联javascript，因为它是由服务器端代码生成的。
答案 2 :(得分：2)
链接JS文件的优点是它们可以被浏览器缓存并从后续页面上的本地磁盘或内存加载。
内联JS的优势在于每页的网络请求可能更少。
最好的折衷方案通常是少量链接的JS文件（一个或两个），它们由所有JS的最小化组合组成，因此它们尽可能少地合并到尽可能少的文件中。
获得本地缓存的好处远远超过了一些可能不会在某些页面上使用的JS的额外解析。
有意义的嵌入式JS（甚至大多数JS都在链接文件中）是一些JS变量的设置，这些变量包含特定于页面的状态。这通常会嵌入页面的部分，因为它是在服务器上动态生成的，每个页面都不同，通常不可缓存。但是，这些数据通常应该很小并且特定于页面。
答案 3 :(得分：2)
其他答案已经提到了使用外部JS文件进行缓存的优势。对于任何可能由至少两个页面使用的库或框架类型功能，我几乎总是这样。尽可能避免重复。
我以为我会评论“内联”与“嵌入”。
对我而言，“内联”意味着将JS与HTML混合，可能还有几个单独的<script>块，这些块可能会或可能不会相互引用，几乎可以肯定的是，有许多事件处理程序直接使用HTML设置像<div onclick="..."/>这样的元素属性。在大多数情况下，我会劝阻这一点，但我不会因为偶尔的使用而过于担心。有时它只是减少麻烦和假装，否则只会浪费你可以花在更重要问题上的时间。
我将“嵌入”定义为在头部或主体末端具有（最好）单个<script>块，并使用文档就绪或上载功能在该块内分配事件处理程序。对于特定于一个页面的函数，我认为没有任何问题，事实上，如果它只是少量的脚本并且我不关心客户端的缓存，我倾向于优先于外部文件。此外，如果页面是动态生成的，并且需要在服务器上生成JavaScript中的某些内容，那么如果脚本位于同一页面上，通常会更容易实现。
关于外部文件的最后一点注意事项：在开发过程中要注意IE的“过度缓存”倾向。有时在测试时我对一两个外部文件进行了一些小改动，并且拉了我的头发想知道为什么它不起作用才最终意识到IE仍然使用旧的缓存版本。 （一方面当然这是我的错，但另一方面我知道很多人不时成为受害者。）
答案 4 :(得分：0)
以上所有答案都是非常好的答案。但是我想基于15年的Web开发经验来补充自己的知识。
始终将链接资源用于CSS和ECMAScripted资源，而不是内联代码，因为链接内容在大多数情况下是由浏览器缓存的，并且在数小时和数天的交互过程中，具有给定域在线的用户。优点如下：
一旦您在第一个域请求/响应上获取链接资源，用户的体验就会很快，并且服务器端页面传递意味着，尽管站点上有大量页面视图或指向页面的链接，但DOM和HTML布局不会移动或刷新。然后，我们经常根据需要将有限的自定义页面级嵌入式样式和脚本资源添加到页面级别的高速缓存链接库堆栈中，如果需要的定制范围很窄的话。然后，全局变量和自定义CSS可以覆盖链接的值。这使您可以更轻松地维护网站，而不必逐页猜测丢失或已经使用了哪些库。我已经在子部分中添加了自定义链接的JQuery或其他库，以这种方式提高速度，这意味着您也可以使用链接脚本来管理网站部分的自定义子组。
GOOGLE语言
您在Google的网络中看到的通常是Angular非常复杂的ES5和ES6模块化脚本缓存系统的实现，这些系统利用脚本和嵌入式CSS在页面视图中对单个页面应用程序使用完全Javascript DOM操作，现在在Angular中独家管理2+）。他们利用精心设计的模块来加载点播和延迟加载组件，并将具有HTML / CSS模板的模块预先加载到内存中，然后从后台服务器中加载，以加快新闻和他们管理的其他页面的交付。
FLAW的全部要求是浏览器在用户与这些缓存的页面和模块进行交互时，在幕后流式传输兆兆ECMAScript，这些HTML和CSS预先嵌入到这些网页中。问题在于它们具有由相同CSS和脚本组成的巨大堆栈，这些堆栈被注入到多个模块中，然后注入DOM的某些部分，这些部分草率且浪费。他们争辩说，现在他们可以轻松地通过内联样式和脚本内容来管理所有这些工作，这些内嵌样式和脚本内容是通过 XMLHTTPRequest 隐藏WebAPI调用与服务器之间下载的。如果从页面链接的小得多的文件就足够了，为什么还要下载所有内容并在内存中重建并存储内联页面呢？
老实说，这是我在Web开发框架中见过的最简单的缓存样式，内容和CSS的方法，因为它仍然需要大量的脚本来解析带有几行文本的简单新闻页面。 Google的某个人并没有真正通过lol来考虑该框架。如果您问我的话，它浪费了带宽和浏览器中的处理能力，并且过大了。这些these肿的供应商通常会过度设计。
这就是为什么我总是主张链接CSS和脚本的原因。更少的代码和更多的内容是发明这些框架的原因。链接和缓存的代码意味着，使用SIMPLER，OLDER模型可以更好地使用较小的标记页面的快速交付，这些标记页面可以缓存几千字节的链接ECMAScript和CSS库。这意味着使用更少的代码来显示内容。与几年前相比，如今浏览器与服务器的关系如今是如此快速和高效，以至于这些较小的链接文件直接从服务器进行了初始缓存（而不是通过每个页面视图上的Angular中的Web API提取的重复脚本的巨型内联页面） ）表示在典型的网络域访问的首次访问期间，链接资源的交付速度要快得多。
直到最近，“脚本小子”都忘记了所有这些内容，因此开始倒退到使用本地嵌入式和内联样式和脚本的失败方式，而我们20年前就停止使用它是有原因的。这是一个非常糟糕的选择，并且显示出当今许多新开发人员对Web及其标记和内容模型缺乏经验。