HTML中引入JavaScript的三种方式及执行顺序

作者：竹影

时间：2026-10-30

系统介绍HTML中引入JavaScript的行内、内部与外部三种方式，深入解析浏览器解析HTML时的同步阻塞机制，以及使用async、defer和type=module控制脚本执行顺序的底层原理与选型建议。

文章目录

在网页开发中，HTML 负责构建文档的骨架结构，而 JavaScript 则赋予网页交互与动态处理能力。在 HTML 中引入 JavaScript 主要有三种方式：行内脚本（Inline）、内部脚本（Internal）与外部脚本（External）。浏览器解析 HTML 文档时，脚本的放置位置以及所附带的属性（如 async、defer 或 type="module"）直接决定了代码的下载时机、执行先后顺序及对 DOM 节点的访问能力。本文将完整拆解这三种引入方式的具体语法、适用边界，并深度剖析浏览器底层的脚本加载与执行调度机制。

一、HTML引入JavaScript的三种基本方式

向 HTML 文档中植入 JavaScript 代码有三种标准途径，它们在代码组织、解耦程度以及资源复用效率上各有侧重。

1. 行内引入（Inline Script）

行内引入是将 JavaScript 代码作为属性值直接写入 HTML 元素的特定事件属性中（例如 onclick、onmouseover 等），或者通过超链接的 javascript: 伪协议触发。

<!-- 通过事件属性直接执行代码 -->
<button onclick="alert('按钮被点击！');">点击提示</button>

<!-- 通过 a 标签伪协议触发函数 -->
<a href="javascript:console.log('超链接触发');">控制台打印</a>

特点与局限：行内代码直接侵入 HTML 标记，将结构与行为杂糅在一起，违反了前端工程“结构、表现、行为分离”的核心原则。此类代码无法被浏览器独立缓存，不可复用，且在配置严格的内容安全策略（Content Security Policy, CSP）时会被默认拦截。因此在实际工程中，除了快速验证原型的偶发场景外，应避免使用行内引入。

2. 内部引入（Internal Script）

内部引入使用成对的 <script> 标签将 JavaScript 逻辑直接包裹在 HTML 文件内部。该标签可以放置在 <head> 区域或 <body> 内部的任何位置。

<!DOCTYPE html>
<html lang="zh-CN">
<head>
  <meta charset="UTF-8">
  <title>内部脚本示例</title>
</head>
<body>
  <h1 id="page-title">欢迎访问</h1>

  <script>
    // 内部脚本：直接编写 JavaScript 逻辑
    const titleElement = document.getElementById('page-title');
    titleElement.style.color = '#345E82';
    console.log('页面标题颜色已更新');
  </script>
</body>
</html>

特点与适用场景：内部脚本不需要发起额外的 HTTP 请求下载文件，适合用于单页面特有的初始化配置、服务端渲染（SSR）向客户端注水（Hydration）的基础配置数据，或者代码量极少的小型工具页面。但由于其代码与 HTML 耦合在同一文件，无法被多页面共享，也无法独立享受浏览器静态资源长效缓存。

3. 外部引入（External Script）

外部引入是将 JavaScript 代码编写在独立的 .js 文件中，随后在 HTML 中通过 <script> 标签的 src 属性指向文件路径进行加载。

<!-- 引入外部独立脚本文件 -->
<script src="./scripts/main.js"></script>

<!-- 注意：带有 src 属性的 script 标签内部不要书写任何代码，浏览器会直接忽略标签体内容 -->
<script src="./scripts/analytics.js"></script>

特点与核心优势：这是现代 Web 开发中最为规范和推荐的方式。它实现了行为与结构的彻底解耦，便于模块化开发、版本控制与工程化构建；更重要的是，独立的 .js 文件能够被浏览器高效缓存在本地磁盘或内存中，当用户访问站内其他页面时无需重复下载，大幅提升二次访问速度。

图1：HTML引入JavaScript的三种方式特性与选型结构图

二、默认解析机制与脚本放置位置的影响

要透彻理解 JavaScript 的执行顺序，必须先明确浏览器主线程解析 HTML 文档的基本规律。

1. 同步阻塞机制（Render-Blocking）

浏览器在获取 HTML 文本后，会自上而下进行词法分析并构建 DOM 树。在未添加任何额外属性的前提下，一旦 HTML 解析器扫描到 <script> 标签：

解析暂停：浏览器会立即停止 HTML 的解析与 DOM 树的构建；
资源下载（若为外部脚本）：主线程发起网络请求下载该脚本文件；
脚本执行：JavaScript 引擎接管主线程，立即编译并执行该脚本；
恢复解析：脚本执行完毕后，HTML 解析器才继续向下解析后续标记。

这种设计是因为 JavaScript 拥有动态修改 DOM 的能力（例如使用 document.write()），如果浏览器在脚本执行前继续解析，后续构建的 DOM 结构可能会被推翻重做。因此，浏览器默认采取严格的“遇脚本即停”策略。

2. 脚本放在 <head> 与 <body> 底部的差异

由于默认存在同步阻塞，脚本放置在 HTML 文档中的具体位置对页面性能和代码执行会产生决定性影响：

置于 <head> 中：此时整个页面的 <body> 尚未被解析，DOM 树空空如也。如果脚本中直接包含对页面元素的查询操作（如 document.querySelector('#main-content')），返回值必定为 null，紧接着调用其属性将引发 TypeError 运行时异常。同时，耗时的网络请求与脚本执行会导致页面长时间呈现白屏，极大损害用户体验。
置于 <body> 最底部：这是经典 Web 开发中的推荐做法。此时页面绝大部分 HTML 标签已经解析成 DOM 节点，脚本不仅能安全、直接地获取到页面中的任何元素，而且首屏视觉内容已经呈现给用户，感知加载速度大幅提升。

图2：HTML解析生命周期与脚本放置位置对DOM访问的影响

三、控制脚本执行顺序的核心属性：async 与 defer

为了解决将脚本置于 <head> 中导致的白屏阻塞问题，同时避免只能将脚本排在 <body> 底部的单一架构限制，HTML5 标准为外部 <script> 标签正式引入了两个布尔属性：async 和 defer。这两个属性只对外部脚本（带有 src 属性）有效，对内部脚本无效。

1. 延迟执行：defer 属性

当一个外部 <script> 标签添加了 defer 属性时：

后台异步下载：浏览器主线程在解析 HTML 的同时，开启网络线程异步下载脚本，下载过程完全不阻塞 HTML 解析；
等待解析完毕：即使脚本早早下载完成，它也不会立刻执行，而是静静等待整篇 HTML 文档解析完成（即 DOM 树构建完毕）；
严格保序执行：多个带有 defer 属性的脚本，浏览器保证按照它们在 HTML 源码中出现的先后顺序依次执行；
触发点明确：所有 defer 脚本执行完毕之后，浏览器才会正式触发 DOMContentLoaded 事件。

<!-- defer 脚本无论放在 head 还是 body，均不会阻塞页面解析 -->
<script src="jquery.min.js" defer></script>
<script src="main-app.js" defer></script>
<!-- 保证：jquery.min.js 必然先于 main-app.js 执行，且执行时 DOM 均已就绪 -->

2. 异步执行：async 属性

当一个外部 <script> 标签添加了 async 属性时：

后台异步下载：与 defer 类似，脚本的下载过程是异步并发的，不会阻塞主线程解析 HTML；
下载完立即执行：一旦该脚本下载完毕，浏览器会立即暂停当前的 HTML 解析（如果此时 HTML 还在解析中），由 JS 引擎立即执行该脚本，执行完毕后再恢复 HTML 解析；
无序执行（先到先跑）：多个 async 脚本之间的执行顺序完全取决于各自的网络传输耗时与文件大小，先下载完成的先执行，与其在 HTML 中的代码顺序毫无关联；
执行时机与 DOMContentLoaded 无关：它可能在 DOMContentLoaded 事件之前执行，也可能在之后执行。

<!-- 独立第三方脚本，适合使用 async -->
<script src="https://cdn.example.com/analytics.js" async></script>
<script src="https://cdn.example.com/ads.js" async></script>
<!-- 提示：ads.js 如果体积小，可能会先于 analytics.js 执行 -->

3. 现代标准：<script type="module">

在现代前端开发中，原生 ES 模块（ECMAScript Modules）已得到所有主流浏览器的原生支持。声明了 type="module" 的脚本具有以下非常关键的执行特性：

默认具备 defer 行为：外部模块脚本默认就是异步下载并在文档解析完成后按序执行，无需显式书写 defer；
依赖拓扑加载：模块内部通过 import 引入的其他子模块会被浏览器自动递归下载，并在所有依赖下载完成后按照依赖树的顺序执行；
支持叠加 async：如果在 type="module" 基础上同时添加了 async，模块及其依赖项一旦下载解析完毕就会立即执行，转变为乱序异步模式。

图3：默认同步、async、defer 与 ES Module 脚本加载与执行时序对比

四、动态脚本与特殊场景的执行顺序规律

除了直接在 HTML 静态标记中书写 <script> 外，在实际开发与第三方 SDK 接入中，还会涉及动态创建脚本与页面事件交互的场景。

1. 动态创建脚本节点（Dynamic Scripts）

通过 JavaScript 代码动态创建 <script> 元素并插入到 DOM 树中，是许多微前端架构、异步按需加载器及统计 SDK 常用的手段：

const script = document.createElement('script');
script.src = '/static/js/chart-module.js';
document.head.appendChild(script);

关键细节注意：现代浏览器中，通过 document.createElement('script') 动态创建的外部脚本，其 async 属性默认被赋值为 true！这意味着多个连续动态插入的脚本同样属于乱序下载与先到先跑。
若需要严格保证多个动态脚本的依赖与先后执行顺序，必须手动将该属性关闭：script.async = false;。当设置为 false 时，浏览器将严格按照 appendChild 的顺序先后执行。

2. 脚本与生命周期事件（DOMContentLoaded 与 load）

掌握执行顺序还必须清楚两个至关重要的浏览器全局事件：

DOMContentLoaded 事件：当 HTML 文档完全解析完毕且所有 defer 脚本执行完成后在 document 上触发。此时样式表、图片等异步资源可能仍在下载，但 DOM 结构已百分之百就绪。
window.onload 事件：当页面内所有静态资源（包括 HTML、所有类型脚本、CSS 样式表、大体积图片、iframe 框架等）全部下载并渲染完毕后才会触发。

五、全景特性对比与工程最佳实践

综合以上分析，我们将不同的脚本引入方式与执行策略归纳为以下决策对照矩阵：

引入/加载方式	网络下载行为	执行时机与阻塞	多脚本顺序保证	访问 DOM 安全性	典型推荐场景
普通 <script> (head)	主线程同步下载	下载后立即执行，全程阻塞解析	严格按代码顺序	不安全（DOM 尚未构建）	极早期需要立即阻断的 Polyfill
普通 <script> (body底)	主线程同步下载	DOM已就绪后执行，轻微阻塞后续	严格按代码顺序	安全（可直接读写元素）	传统无构建工具的多页面网站
<script defer>	后台异步并行下载	HTML解析完成后执行，不阻塞解析	严格按代码顺序	安全（DOM 构建完毕）	生产工程主业务代码首选方案
<script async>	后台异步并行下载	下载完成立即抢占主线程执行	乱序（先下完先跑）	不确定（取决于下载速度）	独立数据打点、百度/谷歌统计、广告SDK
<script type="module">	后台异步并行下载	默认类似 defer，支持拓扑依赖分析	按模块依赖拓扑保序	安全（DOM 构建完毕）	现代 Vite/Webpack 构建的前端应用

图4：JavaScript引入方式与执行策略综合决策树

在日常开发中，建议遵循以下工程黄金法则：

彻底弃用行内脚本：避免在 HTML 标签中直接书写 JavaScript 逻辑，维护纯粹的代码关注点分离，同时规避 CSP 相关的安全阻断风险。
核心业务脚本优先使用 <script defer> 放在 <head> 中：既能尽早让网络线程并发下载脚本文件，又确保了 DOM 构建完毕后再行执行，不仅消除白屏卡顿，也彻底保证了多个脚本的保序执行。
第三方独立脚本使用 <script async>：统计分析、性能监控与广告代码通常不需要访问业务 DOM，也不存在依赖链，使用 async 能够以最快速度完成挂载且不耽误页面正常呈现。
新项目积极采用标准 ES Module：通过 <script type="module"> 组织工程，充分利用其原生具备的延迟保序加载特性与现代打包工具的静态树摇（Tree Shaking）优化。