async 和 defer 不能混用，因语义冲突导致 defer 被忽略；async 立即执行，defer 等 dom 解析完按序执行；混用引发 dom 访问错误、执行顺序混乱等问题。
为什么 async 和 defer 不能混用
浏览器只认一个脚本加载策略：同时写 async 和 defer，async 会生效，defer 被忽略。这不是 bug，是规范行为——async 表示“下载完立刻执行”，defer 表示“等 DOM 解析完再按顺序执行”，二者语义冲突。
常见错误现象：
– 页面 JS 执行时机不稳定，尤其依赖 DOM 的代码报 document.getElementById(...) is null
– 多个 defer 脚本执行顺序和 HTML 中声明顺序不一致（实际是顺序的，但有人误以为乱序）
- 第三方统计、埋点类脚本优先用
async：不阻塞、不依赖 DOM、彼此无顺序要求 - 业务主逻辑（如初始化 Vue/React 应用）必须用
defer：确保 DOM 已就绪，且多个入口脚本能按需串行执行 - 避免在
async脚本里调用document.write()：会清空整个页面，现代浏览器已禁用该行为并抛错
动态 import() 不只是“懒加载”，更是作用域隔离手段
import() 返回 Promise，它真正价值不在“延迟加载”，而在于：每次调用都创建独立模块作用域，避免变量污染和执行时机耦合。比如表单校验规则模块，只在用户点击提交后加载，既省首屏体积，又防止规则函数提前执行或被其他模块意外覆盖。
使用场景：
– 条件性加载（如仅在 Safari 下加载 WebKit 特定 API 封装）
– 路由级代码分割（React Router 的 lazy() 底层就是它）
– 避免初始模块因未满足依赖而报 ReferenceError
立即学习“Java免费学习笔记（深入）”；
- 不要在循环中无节制调用
import()：每个调用触发一次 HTTP 请求，可能触发浏览器并发连接限制（通常 6 个） - 错误捕获必须显式写：
import('./module.js').catch(err => console.error('模块加载失败', err)) - Webpack/Vite 会自动将
import()调用转为 chunk，但若路径含变量（如import(`./${name}.js`)），会打包出所有匹配文件，体积暴增
内联关键 JS 时，type="module" 会悄悄改变执行时机
把少量初始化代码写进 <script></script> 标签里看似快，但如果加了 type="module"，它就变成异步行为——即使没写 async，也会延迟到 HTML 解析完成、且所有 module 脚本下载完毕后才执行。这和开发者直觉相反。
典型问题：
– 内联 type="module" 初始化代码，试图操作 document.body，结果报错（body 还没解析出来）
– 混用 type="module" 和普通脚本，导致执行顺序混乱（模块脚本总在普通脚本之后）
- 纯内联、无依赖、需 DOM 就绪的代码，用普通
<script></script>+defer - 要用模块语法（如
import）又必须内联？改用<script type="module"></script>，但把操作 DOM 的逻辑包进DOMContentLoaded或requestIdleCallback - Vite/Next.js 等工具默认给所有
type="module"加crossorigin，若资源在非 CORS 环境（如本地 file:// 协议）下会静默失败
第三方 SDK 的加载链路比想象中更重
很多 SDK（如 Sentry、Plausible、Hotjar）提供一行嵌入代码，但那一行背后常触发多阶段加载：先载入 loader 脚本 → 检测环境 → 动态插入主 SDK → 主 SDK 再加载配置、遥测数据、甚至字体图标。整个链路可能产生 3~5 次网络请求，且无法用 preload 提前干预。
优化要点：
– 不要直接复制官网给的 <script></script>，查其 loader 是否支持 data-api-key 等属性方式初始化，减少二次请求
– 对非首屏必需的 SDK（如客服浮窗），用 IntersectionObserver 监听进入视口后再加载
– 所有第三方脚本强制加 fetchpriority="low" 和 referrerpolicy="no-referrer-when-downgrade"，降低优先级并减少 header 开销
- Sentry 的
tracingOrigins默认包含所有域名，会导致大量 XHR 被自动 instrument，关掉不用的 origin 可降 20%+ CPU 占用 - Google Analytics 4 的
gtag()调用若放在head，会阻塞渲染；应移至body底部或配合setTimeout(..., 0)延迟 - 某些广告 SDK 会覆盖
console方法，导致你自己的错误监控失效——加载前先备份原生方法
<script></script> 标签本身。 
