脚本执行报document.queryselector返回null，是因为访问dom时元素尚未解析；async会中断html解析立即执行，defer则确保dom构建完成后再按序执行。
用错 async 或 defer，轻则 document.getElementById is not a function，重则业务逻辑全挂、埋点漏报、白屏时间翻倍——它们不是“加了就快”，而是“加对才稳”。
什么时候脚本执行会报 document.querySelector 返回 null？
这是最典型的误用信号：脚本里访问了 DOM 元素，但元素还没解析到 HTML 中。常见于把本该 defer 的初始化代码写成 async，或干脆没加任何属性。
-
async脚本下载完就中断 HTML 解析立即执行，此时可能只解析了一半，#app根本不存在 -
defer一定等到整个 HTML 解析完成、DOM 树构建完毕才执行，所以document.body和所有元素都可用 - 没加属性的默认脚本更危险：它会阻塞解析，但执行时机仍取决于它在 HTML 中的位置——放在
里，很可能 DOM 还没开始建就执行了
defer 为什么能保证多个脚本按顺序执行？
因为浏览器明确把它“锁死”在两个节点之间：HTML 解析完成之后、DOMContentLoaded 事件触发之前。这个窗口期是确定的，且所有 defer 脚本共享同一个执行队列。
- 顺序只看 HTML 中
<script defer src="a.js"></script>和<script defer src="b.js"></script>的书写顺序，跟文件大小、网络快慢无关 - 适合「库 + 业务」组合，比如先加载
lodash.js，再加载依赖它的utils.js - 注意：
defer对内联脚本无效，<script defer>init();</script>会立刻执行，不是延迟 - 现代构建工具（如 Vite）输出的
type="module"脚本默认自带defer语义，手动加defer不会报错但也没效果
async 真的“谁下完谁先执行”吗？
是的，而且这个“先”可能发生在 DOM 构建中途，甚至在 标签刚打开时就执行——只要脚本下载够快。
- 典型适用场景只有三类：
analytics.js（统计）、error-tracking.js（错误上报）、ads.js（广告），它们不操作 DOM、不依赖其他 JS、也不被其他 JS 依赖 - 多个
async脚本之间绝对不能有调用关系，否则utils.init()很可能在utils.js加载完成前就运行 -
async和defer不能共存，浏览器会忽略defer，只按async行为处理 - SSR 页面中，把首屏渲染依赖的初始化逻辑塞进
async脚本，等于主动放弃服务端预渲染收益
真正容易被忽略的点是：是否“依赖 DOM”和是否“被其他脚本依赖”必须同时判断——一个脚本既操作 document.body，又导出函数供后续脚本调用，那它只能走 defer；而哪怕只是发个请求、记个日志，只要不碰 DOM、不暴露 API，async 就是更干净的选择。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
