boxmoe_header_banner_img

Hello! 欢迎来到悠悠畅享网！

POST
文章导读
前端教学

怎样在HTML中插入JavaScript代码？ JS代码嵌入方法详解

avatar
站长 2025年8月7日 8
0 评论

在html中插入javascript的核心方法是使用<script>标签，主要分为内部脚本、外部脚本和行内脚本三种方式；2. 内部脚本将js代码直接写在html文件中，适用于代码量小且仅限当前页面使用的场景；3. 外部脚本通过src属性引用独立的.js文件，有利于代码分离、缓存复用、维护和构建Java免费学习笔记（深入）”；

怎样在HTML中插入JavaScript代码？ JS代码嵌入方法详解

  <head>     内部JS示例  <body>     
Hello World
     <script>         // 你的JavaScript代码写在这里         console.log("这段代码是在HTML内部执行的。");         document.querySelector('h1').style.color = 'blue';      </body>

这种方式直观，但如果JS代码很多，就会让HTML文件显得臃肿，难以维护。

另一种更推荐的方式是外部脚本，把JavaScript代码单独写在一个.js文件里，然后在HTML中通过

<script>

标签的

src

属性引用它。 比如，你有一个

script.js

文件：

怎样在HTML中插入JavaScript代码？ JS代码嵌入方法详解

// script.js console.log("这段代码是从外部文件加载的。"); document.querySelector('h1').style.color = 'red';

然后在HTML中这样引用：

<!DOCTYPE html> <html> <head>     <title>外部JS示例</title> </head> <body>     <h1>Hello External JS</h1>     <script src="script.js"></script> </body> </html>

这样做的好处显而易见：代码分离，结构清晰，而且浏览器可以缓存外部JS文件，提高加载速度。

还有一种不太常用的，或者说不推荐用于复杂逻辑的方式是行内脚本，直接把JS代码作为HTML元素的属性值。

<button onclick="alert('你点击了我！')">点击我</button>

这种方式虽然能快速实现一些简单的交互，但它严重违反了结构、样式、行为分离的原则，代码复用性差，维护起来简直是噩梦。我个人在实际项目中几乎不会用它来处理任何有意义的逻辑，除非是极简的、一次性的事件绑定。

为什么要把JavaScript代码放在HTML的不同位置？

这确实是个老生常谈但又至关重要的问题。我们常常看到

<script>

标签出现在

<head>

里，也常看到它出现在

<body>

的末尾，甚至有时会觉得有点随意。但实际上，这背后是有很深的性能和逻辑考量的。

把JavaScript放在

<head>

里，意味着浏览器在解析HTML文档时，会优先下载并执行这些脚本。这听起来好像挺好，毕竟越早执行越好嘛。但问题在于，JS的执行是会阻塞HTML解析的。也就是说，如果你的脚本文件很大，或者执行时间很长，那么用户在屏幕上看到的内容就会被延迟，页面可能会出现长时间的白屏。这对于用户体验来说，无疑是灾难性的。想想看，一个电商网站，如果用户要等半天才能看到商品图片，转化率肯定会大打折扣。所以，通常只有那些对页面渲染有直接影响，或者需要全局配置的脚本（比如一些统计代码、第三方库的初始化代码，或者polyfill，确保旧浏览器兼容性），我才会考虑放在

<head>

里。而且，我还会尽量确保它们是异步加载的，避免阻塞。

而将JavaScript放在

<body>

标签的末尾，也就是

</body>

闭合标签之前，这是目前最推荐的做法。这样做的好处是，当脚本开始执行时，HTML文档的大部分内容（包括DOM结构）都已经解析完毕并呈现在浏览器中了。这意味着你的JavaScript代码可以立即访问和操作页面上的元素，而不会出现“找不到元素”的错误。同时，它也不会阻塞页面的初始渲染，用户可以更快地看到页面内容，即使脚本还在后台加载。我个人在开发中，几乎所有的业务逻辑脚本都会放在这里，这能有效提升用户感知的页面加载速度，避免用户不耐烦地关闭页面。

当然，也有一些例外情况，比如某些脚本确实需要非常早地介入DOM构建过程，但那往往是高级优化或特定框架的需求了。对于大部分日常开发，把JS放在

<body>

末尾，是个简单又高效的选择。

外部JavaScript文件有什么优势？

我前面提到了外部JS文件，它不仅仅是让代码看起来更整洁那么简单，背后的优势是多方面的，而且在实际项目开发中，这些优势会变得异常突出。

首先，也是最直接的，是代码的组织和可维护性。把HTML、CSS和JavaScript混在一起，就像把所有食材都倒在一个锅里乱炖，最后虽然能吃，但味道肯定好不到哪去。HTML负责结构，CSS负责样式，JavaScript负责行为。这种职责分离让代码逻辑更清晰，无论是自己后期维护，还是团队协作，都能大大提高效率。想象一下，一个上万行的HTML文件里夹杂着几千行JS，光是找到一个函数定义都得费半天劲，简直是噩梦。

其次，是缓存机制。当浏览器首次访问一个页面并加载了外部JS文件后，它会将这个文件缓存起来。当用户再次访问这个页面，或者访问网站的其他页面（如果它们也引用了相同的JS文件），浏览器就不需要重新下载这个文件了，直接从缓存中读取。这能显著减少网络请求，加快页面加载速度，尤其对于移动端用户，能省下不少流量和时间。我曾经优化过一个项目，仅仅是将内部JS全部抽离成外部文件，页面加载速度就有了明显提升。

再者，是代码的复用性。如果你有多个页面需要用到相同的JavaScript功能，比如一个通用的表单验证脚本，或者一个轮播图组件，你只需要编写一个外部JS文件，然后在所有需要的页面中引用它就可以了。这比在每个页面都复制粘贴一遍代码要高效得多，也避免了因为修改一处而忘记修改其他地方导致的问题。

最后，外部文件也为构建工具和优化提供了可能。现代前端开发离不开Webpack、Vite这类构建工具，它们可以对外部JS文件进行压缩（minification）、混淆（uglification）、打包（bundling），甚至进行Tree Shaking来移除无用代码，从而进一步减小文件体积，提升加载速度。这些优化在内部脚本中是很难实现的。

所以，除非是那种非常非常简单的单页小demo，我几乎总是倾向于使用外部JavaScript文件。它带来的长期收益远大于初期的一点点组织成本。

async

和 

defer

属性具体解决了什么问题？

这两个属性，

async

和 

defer

，对于优化外部JavaScript的加载行为至关重要，它们主要是为了解决脚本加载对页面渲染的阻塞问题。我个人觉得，理解它们的工作原理，是前端性能优化的一个基本功。

我们先来看看没有这两个属性的

<script>

标签（特指外部脚本）是怎么工作的：

<script src="my-script.js"></script>

当浏览器遇到这样的脚本标签时，它会暂停HTML的解析，去下载

my-script.js

文件，下载完成后立即执行它，执行完毕后才继续解析HTML。这就像你在看一本小说，突然看到一个脚注，你必须停下来去翻阅参考资料，看完才能继续读小说。这种阻塞行为，尤其当脚本文件很大或者网络状况不佳时，会导致用户看到长时间的白屏或者不完整的页面，体验很差。

现在，我们引入

async

：

<script src="my-script.js" async></script>

加上

async

属性后，浏览器在下载

my-script.js

文件的同时，会继续解析HTML。也就是说，下载和HTML解析是并行进行的，不会互相阻塞。一旦

my-script.js

下载完成，HTML解析就会暂停，脚本立即执行。执行完毕后，HTML解析继续。 这就像你边看小说边听音乐，音乐下载完了就播放，但如果音乐播放器突然弹出一个广告，你还是得停下来处理一下。

async

的特点是，脚本的执行顺序是不确定的，哪个脚本先下载完哪个就先执行。所以，它适用于那些不依赖于其他脚本或者DOM结构的独立脚本，比如谷歌分析（Google Analytics）的代码，或者一些广告脚本。如果你的脚本之间有依赖关系，或者需要操作完整的DOM，那么

async

可能会导致问题。

再来看看

defer

：

<script src="my-script.js" defer></script>
defer

和

async

一样，都会让脚本的下载与HTML解析并行进行，不阻塞页面渲染。但它们最大的不同在于脚本的执行时机。带有

defer

属性的脚本，会等到整个HTML文档解析完毕后，并且在

DOMContentLoaded

事件触发之前，按照它们在HTML中出现的顺序依次执行。 这就像你边看小说边听音乐，但你告诉音乐播放器，等我把这章小说看完，你再开始播放音乐。而且，如果有多首音乐，你会按照我给你的列表顺序一首一首放。 

defer

非常适合那些需要操作DOM，并且

css dom html html元素 JavaScript JS red webpack 为什么 事件 工具 异步 异步加载 性能优化 浏览器 表单验证 谷歌

评论（已关闭）

评论已关闭