<script>标签的核心作用是控制JavaScript何时下载、何时执行、是否阻塞渲染；默认同步执行会阻塞DOM解析，导致document.getElementById找不到元素，应使用defer、移至</body>前或监听DOMContentLoaded修复。
<script> 标签的核心作用不是“加 JS”，而是**控制 JavaScript 何时下载、何时执行、是否阻塞页面渲染**。它不只是一段代码容器，而是一个执行调度开关。
为什么放在 <head> 里常报 document.getElementById 找不到元素？
因为浏览器自上而下解析 HTML，遇到 <script> 就暂停解析、立即下载并执行（默认行为）。此时 <body> 内容还没开始解析，DOM 树为空，document.getElementById 或 querySelector 必然返回 null。
- 典型错误写法：
<head><script src="app.js"></script></head>，且app.js里直接操作#main - 修复方式：把脚本移到
</body>前；或加defer；或用DOMContentLoaded包裹 DOM 操作逻辑 - 注意：即使脚本在
<head>，只要用了defer，就不会报这个错——因为它等 DOM 解析完才执行
async 和 defer 都不阻塞解析，但执行时机差得远
两者都让脚本“后台下载”，但“执行”这一步完全不在一个时间点上：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
-
async：下载完立刻执行，可能发生在 DOM 解析中途，甚至在<html>标签刚开个头时就执行了；多个async脚本执行顺序不确定 -
defer：只对外部脚本（带src）生效；执行时机严格固定在 HTML 解析完成之后、DOMContentLoaded事件触发之前；多个defer脚本按书写顺序执行 - 常见误用：
<script defer>init();</script>—— 内联脚本加defer会被浏览器完全忽略，既不延迟也不报错
什么时候该用 type="module" 而不是 defer？
ES6 模块天然具有 defer 行为，但比 defer 更严格：
立即学习“前端免费学习笔记（深入）”；
-
type="module"脚本默认异步下载 + DOM 解析完成后执行，无需显式写defer - 模块支持
import/export，有真正的依赖图和执行顺序保证；defer只保证 HTML 顺序，不解决运行时依赖（比如 A 依赖 B，但 B 没加defer或加载失败，A 仍会报ReferenceError） - 兼容性注意：IE 完全不支持
type="module"；若需兼容旧浏览器，defer是更稳妥的降级选择
真正容易被忽略的是：脚本是否“可执行”，不只取决于位置或属性，还取决于它所依赖的资源是否已就绪。比如 defer 脚本里调用了未声明的全局函数，或者 async 脚本里用了尚未解析的 DOM 元素，这些错误不会在加载时报，而是在执行那一瞬间才暴露——而且往往难以复现。
