HTML页面生命周期钩子在各浏览器内核中的执行顺序差异-html教程-PHP中文网

document.readystate标准取值为“loading”“interactive”“complete”，现代浏览器严格一致；其中“interactive”时dom就绪但资源未加载完，“complete”时所有资源加载完毕，domcontentloaded应在“interactive”后立即触发，推荐用于多数初始化操作。

html页面生命周期钩子在各浏览器内核中的执行顺序差异

document.readyState 的取值在所有现代浏览器中完全一致

“loading”、“interactive”、“complete”这三个值是 W3C 标准定义的，Chrome、Firefox、Safari、Edge（Chromium 内核）全部严格遵循，不存在执行顺序差异。旧 IE 的 "uninitialized" 和 "loaded" 已彻底弃用，新项目无需兼容。

常见错误现象：document.body 在 document.readyState === "loading" 时为 null，直接调用 querySelector 报错；getComputedStyle 在 "interactive" 阶段可能返回未生效的样式值——这不是浏览器差异，而是 DOM 尚未完成样式计算的固有行为。

“interactive” 不等于“CSS 已就绪”，offsetHeight 或 getBoundingClientRect() 可能不准
“complete” 才代表 <img> 的 naturalWidth 可靠，但此时页面已明显延迟
不要用 document.readyState 做跨浏览器“对齐点”，它只反映解析阶段，不保证渲染或样式状态

DOMContentLoaded 事件触发时机基本无差异，但依赖脚本加载方式

DOMContentLoaded 在 DOM 树构建完毕后立即触发，现代浏览器引擎（V8、SpiderMonkey、JavaScriptCore）均在 parser 完成时同步派发该事件，顺序一致。真正影响触发时间的是 HTML 中的 <script></script> 标签写法：

普通内联脚本或无 async/defer 的外部脚本：会阻塞 parser，DOMContentLoaded 推迟到脚本执行完
defer 脚本：按文档顺序执行，且一定在 DOMContentLoaded 前完成
async 脚本：谁先加载完谁先执行，可能早于或晚于 DOMContentLoaded，不可预测

典型陷阱：把初始化逻辑写在 async 脚本里，又依赖 DOMContentLoaded 事件，结果在 Safari 中逻辑提前执行、DOM 还没 ready。

window.load 的等待范围明确，但资源加载失败会导致行为分裂

window.addEventListener("load", handler) 等待的是所有带 URL 的资源：图片、CSS、<iframe></iframe>、<object></object>。这个语义所有浏览器一致，但实际表现差异来自资源加载结果：

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

某张图片 404：Chrome 会等超时（通常 30s）后才触发 load；Firefox 可能更快放弃；Safari 表现接近 Chrome
CSS 文件长时间阻塞：所有浏览器都会卡住 load，但首屏渲染不受影响（因 CSS 是渲染阻塞资源，不是 load 的等待项）
第三方 iframe 加载失败：部分浏览器（如旧 Edge）可能静默跳过，而 Chromium 内核会坚持等待其 load 事件

因此，load 的“延迟高”不是浏览器差异问题，而是资源网络状况 + 各自超时策略不同导致的表象。别把它当生命周期锚点，它只是资源加载完成信号。

readystatechange 事件监听必须兜底，否则在 Safari/Edge 中易漏状态

document.addEventListener("readystatechange", handler) 理论上会触发多次（"loading" → "interactive" → "complete"），但 Safari 和某些 Edge 版本存在优化：若 DOM 构建极快，"interactive" 状态可能一闪而过，事件监听器来不及注册就已跳到 "complete"。

可靠写法只有两种组合：