脚本加载顺序直接影响白屏时长和交互可用性，错用async或defer会导致DOM操作失败、依赖报错甚至页面卡死；默认script阻塞HTML解析，async下载完立即执行且无序，defer在DOM解析完成后按序执行。
脚本加载顺序直接决定页面白屏时长和交互可用时间，不是“加个 async 就完事”——错用 defer 或 async 可能导致 DOM 操作失败、依赖报错、甚至页面卡死。
script 标签默认是阻塞解析的
浏览器遇到 <script src="a.js"></script> 会立刻暂停 HTML 解析，下载、编译、执行完才继续。这意味着：如果脚本放在 <head> 里，整个 <body> 都得等它；哪怕脚本只有一行 console.log("hi")，也会拖慢首屏渲染。
- 所有未声明
async或defer的外部脚本（带src）都按此规则执行 - 内联脚本（
<script>alert(1)</script>）同样阻塞，且无法异步化 - 现代浏览器虽支持部分资源并行下载（如 CSS、图片），但 JS 默认仍会阻塞后续 HTML 解析和渲染
async 和 defer 的执行时机差异很关键
async 和 defer 都让脚本“不阻塞 HTML 解析”，但执行时机天差地别——选错等于埋雷。
-
async：下载完**立刻执行**，与 HTML 解析并发，但执行顺序**完全不确定**。适合完全独立的脚本，比如analytics.js、ads.js -
defer：下载与解析并发，但执行被推迟到**HTML 解析完成之后、DOMContentLoaded事件触发之前**，且**严格按<script>出现顺序执行**。适合操作 DOM 的初始化脚本，比如form-validation.js、menu-init.js - 两者都只对带
src的外部脚本生效；内联脚本加了也没用 -
async在 IE10 以下不支持；defer在 IE7+ 支持，但旧版 IE 中多个defer脚本可能不保序（实测 IE9 有概率乱序）
动态创建 script 元素能绕过 HTML 解析限制
当需要更精细控制加载时机（比如用户点击后才加载某功能模块），document.createElement('script') 是比属性更灵活的方案。
立即学习“前端免费学习笔记（深入）”；
- 新创建的
<script>默认就是异步的：插入 DOM 后立即开始下载，不阻塞解析 - 执行时机取决于插入位置：插在
<head>里，通常在DOMContentLoaded前执行；插在<body>底部，则接近window.onload - 注意：
onload事件监听必须在src赋值**之后**设置，否则可能错过回调 - 示例：
const s = document.createElement('script');<br>s.src = '/js/chart.js';<br>s.onload = () => initChart();<br>document.head.appendChild(s);
混合使用时容易忽略的边界情况
真实项目中常同时用 defer、async 和动态脚本，但它们之间没有执行优先级约定，极易出问题。
-
defer脚本一定在DOMContentLoaded前执行，但**不保证在所有async脚本之后**——如果某个async脚本很小、下载极快，它可能比defer脚本先执行 - 动态插入的脚本，其
onload回调执行时机与defer脚本无先后保障，不要假设“所有初始化已完成”再调用 - Webpack 等打包工具生成的
runtime/vendor脚本若用了defer，而业务脚本用了async，可能导致require is not defined - 服务端渲染（SSR）场景下，
defer脚本的执行时机可能和客户端 hydration 冲突，需配合data-hydrate等标记做协调
真正难的不是记住 async/defer 的定义，而是判断“这个脚本是否真的能独立执行”“它依赖的 DOM 是否已就绪”“它会不会被另一个更快的 async 脚本抢先改写全局状态”——这些没法靠加属性解决，得结合具体代码逻辑逐个验证。
