置于body结束标签前的脚本与Document.onload的应用差异是什么？

先明确两者的实际执行触发逻辑 #

• 将同步脚本放在</body>标签之前的末尾位置：
  浏览器从上到下逐行解析HTML、构建DOM树，当解析到body末尾的脚本时，意味着前面所有的HTML标签（从页面头部到body内所有元素节点）已经全部完成DOM树构建。此时脚本可以直接访问所有DOM元素，不会出现“元素未定义”的报错。
  但这个时机不等同于页面全量资源加载完成——此时页面里的图片、字体、嵌入iframe、外部样式表可能还在后台下载解析，元素的真实渲染尺寸、视觉状态还没完全稳定。
• 在<head>内引入脚本、通过document.onload包裹业务执行逻辑：
  默认情况下，浏览器解析到head内的同步脚本时，会立刻暂停DOM解析，开始下载、解析脚本文件。只是因为所有业务逻辑都被包在onload回调里，脚本本身不会立刻操作页面，需要等到整个页面的所有依赖资源（图片、样式、子框架、字体等）全部下载、解析完成，完成全页面渲染之后，回调才会被触发执行。

针对核心疑问的澄清 #

之所以会觉得“把脚本放在body标签末尾就已经能确保页面内容加载完成、可供脚本操作”，核心是没理清页面加载过程里三个依次推进的关键节点：

1. DOM树构建完成：所有HTML标签结构解析成可被JS访问的节点树，这个节点就是body末尾脚本的执行时机，对应DOMContentLoaded事件的触发点。此时DOM结构可访问，但静态资源未必加载完成，元素的渲染状态未必稳定。
2. 页面样式与布局计算完成：浏览器根据样式表规则，计算每个DOM元素的位置、尺寸，完成排版。
3. 全量资源加载完成：所有图片、字体、嵌入资源加载完毕，页面渲染状态完全稳定，这个节点就是document.onload的触发点，也就是load事件的执行时机。
   也就是说，body末尾的脚本执行时，只完成了第一个阶段，离onload对应的第三阶段，还差了样式计算、资源下载的完整流程。

两者的实际效果差异 #

• 对首屏性能的影响不同
  • body末尾的脚本：不会阻塞HTML的解析过程，用户可以先看到完整的页面结构，脚本在所有DOM解析完成后才开始下载执行，几乎不会造成首屏白屏。
  • head内通过onload包裹的同步脚本：因为脚本的下载、解析发生在head阶段，会阻塞后续的DOM解析，如果脚本体积较大，很容易拉长白屏时间。哪怕业务逻辑放在onload回调里，也没法抵消脚本下载本身对解析流程的阻塞。
• 可获取的页面状态不同
  • body末尾的脚本：只能操作已经构建完成的DOM结构，如果业务逻辑需要拿到图片的真实宽高、等待自定义字体加载完成后再做布局适配，没法靠脚本的放置位置保证，需要自己额外加资源加载的监听逻辑。
  • onload回调内的脚本：天然能拿到所有资源加载完成后的最终页面状态，不管DOM在页面哪个位置，只要回调触发，所有依赖的资源都已经就绪，适合需要做全页面渲染后适配、统计整体加载性能的逻辑。

内容的提问来源于stack exchange，提问作者FRANCISCO BERNAD