script标签放head还是body？一个关于时机与风险的决策
关于script标签该放在还是，其实没有唯一的“标准答案”。这更像是一个权衡：你的脚本是否需要访问DOM？它是否依赖页面结构？以及，你愿意为它的加载时机承担多大的渲染阻塞风险？说到底，这不是“哪个更好”，而是“哪个更合适”的问题。
脚本执行时报 document.getElementById(...) is null 怎么办？
这几乎是新手开发者最常遇到的“经典错误”之一。它的本质是什么？脚本跑得太快了，在DOM元素还没来得及“出生”时就伸手去抓，结果自然扑了个空。
- 想想看，如果一个
。这个属性会让脚本异步下载，但它的执行会被严格推迟到整个DOM解析完成之后，完美解决了访问时机的问题。 - 这里有个关键提醒：千万别用
async属性来替代defer解决这个问题。async脚本下载完就会立刻执行，时机完全不可控，很可能DOM还没构建完成它就“抢跑”了，问题依旧存在。
defer 和 async 的实际行为差异：一字之差，天壤之别
这两个属性都号称能“异步加载”，不阻塞HTML解析，但它们的执行时机和行为逻辑截然不同。选错了，轻则依赖关系错乱，重则DOM访问失败。
defer（延迟执行）：脚本的下载可以和HTML解析并行进行，但它的执行会被推迟。推迟到什么时候？整个文档解析完毕，并且在DOMContentLoaded事件触发之前。更重要的是，多个带defer的脚本会严格按照它们在HTML中间出现的顺序执行，保证了依赖关系。async（异步执行）：脚本下载完成后会立即执行，它既不等待其他脚本，也不等待DOM解析。这种特性让它非常适合那些完全独立、不操作DOM也不依赖其他JS的工具类脚本，比如统计埋点或广告SDK。- 一个容易踩的坑：对于没有
src属性的内联脚本（例如），defer和async属性是无效的。它们的执行时机，只能通过放置位置来控制。 - 在现代前端工程化项目中，打包工具（如Webpack、Vite）生成的入口脚本，通常都建议统一使用
defer。这既能保证脚本间的执行顺序，又能最大程度避免阻塞页面渲染，算是个两全其美的方案。
第三方脚本（如Google Analytics、微信JS-SDK）该放哪？
处理第三方脚本是个技术活，也是个“看文档”的活。这类脚本通常不操作当前页面的DOM，但对加载速度和执行时机往往有特殊要求。
立即学习“Ja va免费学习笔记（深入）”；
- 通用策略：优先使用
async并放在。这样可以避免阻塞页面渲染，又能让脚本尽早开始下载。对于分析类脚本来说，越早执行，数据埋点就越准确。 - 但切记：先看官方文档！ 不同脚本的要求可能完全不同。例如，微信JS-SDK就明确要求必须在
开始标签后立即加载，否则config初始化会失败；而像Srror这样的错误监控工具，则推荐使用async放在。 - 还有一种极少见但需要警惕的情况：如果某个第三方脚本内部使用了古老的
document.write方法，那么它必须放在或HTML解析过程中。如果放到页面底部，document.write会清空整个已经渲染好的页面。遇到这种脚本，别硬套规则，先查清楚它的要求。 - 使用
async时还要注意一个隐患：它不保证多个脚本的执行顺序。如果两个第三方脚本存在依赖关系（比如A脚本需要先初始化，B脚本才能调用其API），那么直接给它们都加async就可能出问题。这时可能需要考虑合并脚本，或者手动编写加载逻辑来控制时序。
最后，再补充一个容易被忽略的细节：内联脚本和模块脚本（type="module"）的行为差异。带有type="module"的脚本，其默认行为就等同于defer，即使你把它写在里，它也不会阻塞渲染。而传统的脚本则没有这个“福利”。当你在项目中混合使用传统脚本和模块脚本时，尤其要留心它们的执行时序，别以为加了module就万事大吉了。
