async脚本下载完立即执行，不等待dom就绪，易导致document.getelementbyid等返回null；仅对外部脚本有效，内联脚本忽略async；不保证执行顺序，不可用于有依赖的主逻辑。
async 脚本执行时 DOM 可能还没建好
async 脚本下载完就立刻执行，不管 document.readyState 是 "loading" 还是 "interactive"。这意味着 document.getElementById("app") 很可能返回 null，document.querySelector(".header") 报错，Vue 或 React 初始化失败——不是脚本写错了，而是它跑得太早。
常见错误现象：Uncaught TypeError: Cannot read property 'appendChild' of null，尤其当 async 脚本放在 里，而目标元素在 后半段时。
- 唯一可靠的前提：目标 DOM 元素必须出现在该
<script async src="..."></script>标签之前，且已解析完毕 - 兜底写法只能是条件判断：
if (document.getElementById('main')) { init(); }，别用轮询或setTimeout模拟“等待” - 如果脚本依赖其他 JS（比如先加载 lodash 再用），async 无法保证顺序，直接放弃
async 只对带 src 的外部脚本生效
写成 <script async>console.log('hi');</script> 完全无效。浏览器会忽略 async 属性，内联脚本仍同步执行、立即阻塞 HTML 解析。
这是 HTML 规范硬性限制，不是某家浏览器的 bug。哪怕你加了 type="module" 或 type="text/javascript"，只要没 src，async 就没意义。
- 想让内联逻辑不阻塞？只能改写成异步调用：
setTimeout(() => { /* 业务代码 */ }, 0)或requestIdleCallback() - SSR 注入的初始化数据（如
window.__INITIAL_STATE__）必须放在所有脚本标签之前，且不能包在带async的内联<script></script>里 -
document.write()在任何 async 脚本里都禁止使用，否则浏览器会清空整个文档
多个 async 脚本谁先下完谁先跑
async 不保证执行顺序。假设页面引入了 <script async src="analytics.js"></script> 和 <script async src="ads.js"></script>，网络快的先执行，慢的后执行——哪怕后者在 HTML 中写在前面。
这适合完全独立、无依赖的脚本，比如埋点统计、错误上报、广告 SDK。但绝不能用于主业务逻辑，比如 main.js 或 app.js。
- 体积大 + 执行慢的脚本设为 async，反而会中断 HTML 解析，拖慢首屏渲染
-
async和defer不能共存：<script async defer src="a.js"></script>中defer会被静默忽略，只按async行为执行 - HTTP/2 推送的脚本不会被预扫描线程识别，async 属性在此场景下失效；必须配
<link rel="preload" href="a.js" as="script">才能提前加载
async 与 type="module" 一起用等于白加
ES Module 脚本（<script type="module" src="app.mjs"></script>）默认行为就是类似 defer：异步下载、DOM 解析完成后按序执行。再手动加 async，属性会被忽略，既不改变执行时机，也不触发真正意义上的“下载完立刻执行”。
如果你真需要模块脚本“尽快执行”，得靠构建工具拆分 + import() 动态导入，而不是靠 HTML 属性硬控。
- type="module" 脚本天然支持跨域、自动 defer 语义，无需额外属性
- 预扫描线程只识别静态
src值，像src="bundle.${version}.js"这种模板字符串路径，async 也抓不到 - 模块脚本内部的
import()加载不受async或defer约束，需自行用Promise或try/catch处理加载失败
实际项目里最容易被忽略的，是 async 脚本和 DOM 就绪之间的“时间差”——它不是偶发问题，而是确定性行为。别指望加个 async 就万事大吉，得看脚本到底干啥、依赖什么、放在哪。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
