HTML异步能解决脚本阻塞吗_HTML异步优化脚本阻塞做法【手册】

处理HTML异步能解决脚本阻塞吗_HTML异步优化脚本阻塞做法【手册】这类问题时，先确认目标场景，再按步骤核对配置或玩法细节。

async不能跳过渲染阻塞，仅下载阶段并行；下载完立即执行并阻塞HTML解析。defer在DOM构建完毕后按序执行，不阻塞渲染。import()返回Promise，真正非阻塞且可控制时机。

async 属性真能跳过渲染阻塞吗

能，但只对「纯下载阶段」有效。浏览器遇到带 async 的 <script> 标签时，会立刻发起并行下载，不等 HTML 解析完成；但一旦脚本下载完毕，它会立即暂停 HTML 解析、执行脚本——这个执行过程依然会阻塞渲染。

常见错误现象：async 脚本在 DOM 尚未解析完时就执行，导致 document.getElementById 返回 null；或者多个 async 脚本执行顺序不确定，依赖关系断裂。

1. 适用场景：独立工具类脚本（如统计代码、埋点 SDK），不操作 DOM、不依赖其他 JS
2. 不适用场景：需要操作页面元素、或依赖 jQuery 等前置库的脚本
3. 注意：async 对内联脚本无效（<script>console.log(1)</script>），只对带 src 的外部脚本生效

defer 比 async 更适合大多数页面逻辑

defer 也能异步下载，但关键区别在于：它会把执行时机严格推迟到 HTML 解析完成、DOM 构建完毕之后，且多个 defer 脚本按出现顺序执行。

这意味着你可以放心在 defer 脚本里写 document.querySelector 或绑定事件，不用担心 DOM 不存在。

1. 必须配合 src 使用（和 async 一样，内联脚本忽略 defer）
2. 如果页面有多个 defer 脚本，它们的执行顺序和 <script defer src="a.js"></script> 在 HTML 中的书写顺序一致
3. 兼容性好，IE9+ 全支持；但注意：若脚本中用了 document.write，defer 下会直接报错或静默失败

动态 import() 是现代方案，但得看运行环境

如果你用的是模块化开发（ESM），import() 是真正的「按需、非阻塞、可控制时机」的加载方式，返回 Promise，执行完全不打断主线程。

典型错误：在顶层作用域写 import("./utils.js")，以为能替代 defer——不行，import() 必须出现在函数内或条件分支中，否则语法报错。

1. 使用场景：路由级代码拆分（React.lazy / Vue defineAsyncComponent 底层就是它）、用户触发后才加载的重型功能（如编辑器、图表库）
2. 注意：不能用于替换 <script src="polyfill.js" defer> 这类基础兼容层，因为 import() 本身需要 ES2020+ 环境支持
3. 性能提示：多次调用同一路径的 import() 会被自动去重缓存，不用手动 memo

script 标签位置和 type 属性常被忽略

把 <script> 放在 </body> 前仍是有效兜底手段，尤其当无法修改构建流程或要兼容老旧系统时。但它本质是「延迟到 DOM 构建末尾再加载」，不是异步。

另一个容易踩的坑：type="module" 脚本默认具有 defer 行为，即使没写 defer 属性；而 type="text/javascript"（或无 type）则走传统阻塞逻辑。

1. 混合使用时注意：一个页面里同时存在 type="module" 和普通脚本，模块脚本一定最后执行，不管位置
2. 如果用了 type="module"，又想让某脚本「尽早执行但不阻塞」，只能用 import() 动态加载，不能再靠属性控制
3. 检查控制台是否报 Failed to load module script：通常是 MIME 类型不对（服务器返回 text/plain 而非 application/javascript）

真正决定是否阻塞的，从来不是「有没有发请求」，而是「什么时候执行」。async/defer/import() 各自卡在不同环节，选错就像给刹车装油门——表面动了，实际更卡。