defer仅对外部脚本（含非空src）生效，内联脚本加defer会被浏览器忽略；必须同时满足src存在且defer为无值布尔属性，否则退化为同步加载。
defer只对外部脚本生效，内联脚本加它没用
浏览器会直接忽略 <script defer>console.log(1)</script> 里的 defer，照常立即执行。因为 defer 的设计目标是“让外部资源不阻塞 HTML 解析”，而内联脚本已经嵌在文档流里，不存在“下载阻塞”问题。
真正起作用的写法只有这一种：<script src="app.js" defer></script>。必须同时满足两个硬条件：存在 src 属性 + defer 是无值布尔属性（不能写成 defer="true" 或 defer="defer"）。
- 写了
defer="false"？浏览器当没看见，退化为同步加载 - 用了
document.write()？defer被静默禁用，脚本仍会阻塞 - 构建工具把
src脚本转成内联（如 Vite 的inlineDynamicImports: true）？defer彻底失效，得检查最终生成的 HTML
多个defer脚本按HTML顺序执行，不是按下载快慢
这是 defer 和 async 最关键的区别。比如：
<script src="lodash.js" defer></script><script src="utils.js" defer></script><script src="main.js" defer></script>
即使 main.js 先下载完，也必须等前两个执行完才轮到它。这对有依赖关系的代码（比如库 → 工具函数 → 业务逻辑）非常关键。
-
async脚本混在里面会打破顺序：<script src="a.js" async></script><script src="b.js" defer></script>中，a.js可能早于b.js执行，哪怕b.js在前 -
type="module"脚本默认自带defer行为，再加defer属于冗余，部分旧浏览器还可能出兼容问题 - IE11 不支持
type="module"，要保兼容就得用传统<script src="x.js" defer></script>
defer能保证DOM就绪，但不保证脚本内部逻辑安全
defer 确保脚本执行时 document.getElementById("app") 不会返回 null，因为它被强制安排在 HTML 解析完成、DOMContentLoaded 触发前运行。但这只是“时机保障”，不是“行为兜底”。
- 脚本里写了死循环或长时间同步操作？会卡住
DOMContentLoaded事件，页面交互延迟 - 脚本内部动态
import()加载模块？这些后续模块不受defer约束，执行时机由代码自己控制 - CDN 返回 404 或网络超时？
defer脚本照样失败，不会自动 fallback，得靠try/catch或加载状态管理 - 脚本依赖某个第三方服务（如地图 SDK）？
defer只管加载时机，不管服务是否可用
async和defer不能共存，浏览器只认async
写成 <script src="a.js" async defer></script> 是无效的。规范明确：两者同时出现时，async 优先级更高，defer 被静默忽略。结果就是脚本下载完立刻执行，顺序不保证。
这种写法常见于复制粘贴或构建配置错误，线上很难排查——控制台不报错，网络面板看不出区别，只有执行乱序或 DOM 访问失败时才暴露问题。
- 想尽早执行且无依赖？只用
async - 要操作 DOM 或保持顺序？只用
defer - 放在
里的同步脚本？性能雷区，除非是极小 polyfill，否则必须改
defer 是否还存在。构建工具、模板引擎、CDN 缓存都可能悄悄把它删掉或改写，而你根本看不到。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
