内联javascript不推荐用于复杂逻辑，因其导致代码难以维护；2. 内部javascript适用于少量页面专用脚本，但不利于复用和可读性；3. 外部javascript是最推荐的方式，支持代码分离、缓存和复用；script标签放在body末尾可避免阻塞渲染，提升用户体验；使用defer属性可延迟执行并保持脚本顺序，适合有依赖的脚本；使用async属性可异步执行，适合独立脚本如统计或广告；外部javascript文件应作为标准实践，以提升维护性、性能和团队协作效率。
JavaScript代码可以通过多种方式嵌入到HTML文档中，最常见也最推荐的方式是使用
<script>
标签。这个标签可以放在HTML的
<head>
部分、
<body>
部分的任何位置，或者引用一个外部的JavaScript文件。具体放在哪里，会直接影响脚本的加载时机和页面的渲染表现。
解决方案
要将JavaScript嵌入HTML，我们有几种策略，每种都有其适用场景和考量：
1. 内联JavaScript (Inline JavaScript)
立即学习“Java免费学习笔记（深入）”；
这通常是将少量的JavaScript代码直接写在HTML元素的事件属性中。比如：
<button onclick="alert('你好，世界！');">点击我</button>
这种方式简单直接，对于一些非常简单的交互，比如一个即时弹窗，确实方便。但说实话，我个人并不太推荐这种做法。它把行为逻辑和结构混在一起，代码变得难以阅读和维护，尤其当交互变得复杂时，那简直是灾难。想象一下，如果你有几十个按钮，每个都写一段JS，修改起来会让你崩溃。
2. 内部JavaScript (Internal JavaScript)
这种方式是将JavaScript代码包裹在
<script>
标签内部，然后将这个
<script>
标签放在HTML文档的
<head>
或
<body>
里。
<head> <script> // 这里写JavaScript代码 console.log('脚本在head中执行。'); <body> 这是一个段落。
<script> // 这里写JavaScript代码 console.log('脚本在body中执行。'); </body>
这种方式适用于页面特有的少量脚本，无需额外文件请求。但如果脚本代码量大，HTML文件会变得很臃肿，不利于代码复用，也影响HTML的可读性。我有时会在一些快速原型开发或者确实只有一两行、且只针对当前页面的初始化脚本时用它，但大规模项目肯定不会这么搞。
3. 外部JavaScript (External JavaScript)
这是目前最主流、也最推荐的做法。你把所有的JavaScript代码写在一个独立的
.js
文件中，然后在HTML中通过
<script>
标签的
src
属性来引用它：
<!-- 引用外部JavaScript文件 --> <script src="path/to/your-script.js"></script>
这种方式把HTML结构和JavaScript行为彻底分离，代码清晰，易于维护和管理。而且，浏览器可以缓存这些外部JS文件，当用户再次访问你的网站时，如果文件没有更新，浏览器会直接从缓存中读取，大大提升加载速度。这一点非常关键，对于用户体验来说，快就是好。
script标签放在head里好还是body里好？
这是一个老生常谈的问题，但其背后涉及到浏览器渲染机制和用户体验的深层次考量。我的经验告诉我，这没有绝对的“好”与“坏”，只有“更适合”的场景。
放在
<head>
里： 当你把
<script>
标签放在
<head>
里时，浏览器在解析HTML文档的过程中，一旦遇到这个
<script>
标签，就会立即暂停对HTML的解析，转而去下载（如果是外部JS文件）并执行这段JavaScript代码。只有当脚本执行完毕后，HTML解析才会继续。
- 优点： 确保了JavaScript在页面内容渲染之前就已经可用。如果你的脚本需要进行一些全局配置、数据预处理，或者需要立即操作DOM（尽管此时DOM可能还没完全构建），这种方式可以保证脚本的先行权。
- 缺点： 也是最致命的缺点——它会阻塞页面的渲染。如果你的JavaScript文件很大，或者执行时间很长，用户可能会长时间看到一个空白页面（俗称“白屏”），直到脚本加载并执行完毕。这在移动网络环境下尤其明显，用户体验会非常糟糕。
我通常只在极少数情况下，例如需要进行页面重定向、或者某些必须在DOM渲染前完成的全局性、非阻塞性操作时，才会考虑将脚本放在
<head>
。但即便如此，我也会尽量让这些脚本非常小，并且考虑使用
defer
或
async
属性来优化。
放在
<body>
的末尾（
</body>
标签之前）： 这是目前业界普遍推荐的做法。当
<script>
标签放在
</body>
闭合标签之前时，浏览器会优先解析和渲染HTML内容。用户可以更快地看到页面的骨架和内容，即使JavaScript还没有加载完成，页面也已经呈现出来了。只有当HTML文档的大部分内容都解析并渲染完毕后，浏览器才会开始加载和执行这些位于
<body>
末尾的JavaScript。
- 优点： 显著提升用户感知性能。用户不会长时间看到白屏，而是能很快看到页面的基本结构，这让他们觉得网站加载很快。而且，当脚本执行时，页面上的DOM元素通常都已经可用了，脚本可以直接操作它们，省去了等待
DOMContentLoaded
事件的麻烦。
- 缺点： 如果你的JavaScript需要对页面进行早期交互或修改，可能会出现短暂的UI闪烁或者功能不可用的情况，直到脚本加载并执行完毕。但这通常可以通过一些CSS加载动画或者骨架屏来缓解。
从用户体验的角度出发，将
<script>
标签放在
<body>
的末尾是大多数场景下的最佳实践。它让页面内容能够尽快呈现给用户，提升了网站的“可用性”感知。
defer和async属性有什么用？
在现代Web开发中，
defer
和
async
这两个属性是优化JavaScript加载策略的利器，它们能够让脚本的加载和执行不再那么“死板”，而是更具灵活性，从而进一步提升页面性能。它们都只对外部JavaScript文件（即带有
src
属性的
<script>
标签）有效。
defer
属性： 当你在
<script>
标签上加上
defer
属性时，浏览器会并行下载这个脚本文件（不会阻塞HTML解析），但它会“推迟”脚本的执行。具体来说，所有带有
defer
属性的脚本会在HTML文档完全解析完成后，并且在
DOMContentLoaded
事件触发之前执行。更重要的是，它们会按照它们在HTML中出现的顺序依次执行。
<script src="script1.js" defer></script> <script src="script2.js" defer></script>
如果
script2.js
依赖于
script1.js
中的某个变量或函数，那么
defer
就能保证
script1.js
会先于
script2.js
执行。这就像是告诉浏览器：“这个脚本很重要，但你先别急着执行，等HTML都搞定再说，而且我会排队，不插队。”
- 适用场景： 当你的脚本依赖于DOM，或者脚本之间存在执行顺序的依赖关系时，
defer
是一个非常好的选择。比如，你有一个jQuery库文件，然后另一个脚本文件需要使用jQuery，这时就可以给它们都加上
defer
。
async
属性： 当你在
<script>
标签上加上
async
属性时，浏览器也会并行下载这个脚本文件（同样不会阻塞HTML解析），但它的执行策略与
defer
截然不同。带有
async
属性的脚本会在下载完成后立即执行，它不会等待HTML解析完成，也不会等待其他
async
脚本的执行顺序。
<script src="analytics.js" async></script> <script src="ads.js" async></script>
这意味着，如果你的HTML中有多个
async
脚本，它们的执行顺序是不可预测的，哪个先下载完哪个就先执行。这就像是告诉浏览器：“我下载完了就跑，不管不顾，谁也别想拦我。”
- 适用场景：
async
非常适合那些独立性强、不依赖DOM、也不依赖其他脚本的脚本。例如，统计代码（Google Analytics）、广告脚本或者一些独立的第三方组件。因为它们不需要等待其他资源，可以尽快加载并执行，对页面渲染的影响最小。
我的看法： 理解
defer
和
async
的关键在于它们对“阻塞”和“顺序”的处理。
async
是完全非阻塞、非有序的，而
defer
是非阻塞但有序的。在实际项目中，我会根据脚本的特性来选择：如果脚本是核心交互逻辑，且需要操作DOM或有依赖关系，我会倾向于将它放在
<body>
末尾（不加
defer
/
async
，让它在DOM可用后执行），或者使用
defer
。如果脚本是辅助性的，比如埋点、广告等，我会毫不犹豫地使用
async
。
什么时候应该使用外部JavaScript文件？
在现代Web开发实践中，几乎所有非简单的页面交互都应该使用外部JavaScript文件。这不是一个建议，而是一个规范。将JavaScript代码放在独立的
.js
文件中，并从HTML中引用，带来了多方面的好处，这些好处远超内联或内部脚本所能提供的便利。
1. 代码复用与维护性： 想象一下，如果你有几十个页面，每个页面都需要一个导航栏的下拉菜单功能，或者一个通用的表单验证逻辑。如果这些代码都写在每个HTML文件里，那么一旦功能需要修改，你就要改几十个文件。这简直是维护的噩梦。而如果这些代码都在一个外部
.js
文件里，你只需要修改一个文件，所有引用它的页面都会同步更新。这大大提升了代码的复用性和可维护性。
2. 浏览器缓存机制： 这是外部JS文件一个巨大的性能优势。当用户第一次访问你的网站时，浏览器会下载这些外部
.js
文件并将其缓存起来。当用户再次访问你的网站（或者访问网站的其他页面，只要引用了同一个JS文件），浏览器会直接从本地缓存中读取这些文件，而无需再次从服务器下载。这大大减少了HTTP请求次数和数据传输量，从而显著加快了页面加载速度，提升了用户体验。
3. 分离关注点 (Separation of Concerns)： 这是Web开发的一个基本原则。HTML负责页面结构，CSS负责页面样式，JavaScript负责页面行为。将它们各自放在独立的文件中，能够让代码结构更清晰，更易于阅读和理解。开发者可以专注于某个层面的开发，降低了代码的耦合度，也使得团队协作更加高效。当你需要调试样式问题时，你不会被大量的JavaScript代码干扰；当你需要修改交互逻辑时，你也不必在HTML标签的海洋中寻找。
4. 团队协作效率： 在大型项目中，通常会有多个开发者协同工作。如果JavaScript代码都内联在HTML中，很容易出现冲突和代码覆盖。而使用外部JS文件，不同的开发者可以同时在不同的JS文件上工作，互不干扰，通过版本控制系统（如Git）进行管理，大大提高了开发效率。
5. 代码量与可读性： 当JavaScript代码量较大时，将其放在外部文件可以避免HTML文件过于臃肿，提高HTML的可读性。一个整洁的HTML文件，更容易让人理解其结构。
总的来说，外部JavaScript文件是构建现代、高性能、易维护Web应用的基石。内联和内部脚本，我通常只会在一些非常特殊、代码量极小且不具备复用价值的场景下才会使用，比如一个简单的事件绑定或者一个临时的调试脚本。但对于任何稍微复杂一点的交互逻辑，或者任何可能在多个页面复用的功能，外部JS文件都是毫无疑问的最佳选择。
评论（已关闭）
评论已关闭