DOMContentLoaded在DOM树构建完毕时触发，不等待图片、CSS等资源；load则需所有资源加载完成才触发，二者时序严格遵循规范。
HTML 页面生命周期钩子在不同浏览器内核中的执行时序基本一致，但微任务介入、资源加载失败、脚本加载方式等实际因素会导致可观测行为差异——这不是浏览器“不一致”，而是你代码里没处理好边界。
DOMContentLoaded 和 load 的触发时机差异在哪
这两个事件的触发逻辑由浏览器规范强制定义，所有主流内核（Blink、WebKit、Gecko）都严格遵循：DOM 解析完成 → DOMContentLoaded；所有阻塞渲染资源加载完成 → load。但实际感知到的“顺序错乱”往往来自以下原因：
-
DOMContentLoaded会等待所有同步脚本（<script>）执行完毕，但不会等async或defer脚本 —— 如果你在async脚本里提前读取document.body，可能拿到null，误以为DOMContentLoaded没触发 -
load等的是所有<img>、<link rel="stylesheet">、<iframe>的onload，但某个图片 404 或 CDN 延迟，就会卡住整个load，而DOMContentLoaded早已过去几秒 - 如果你用
window.addEventListener('load', ...)但页面里有个<img src="broken.jpg">，Chrome 和 Safari 都会等它超时（通常 30s），Firefox 则可能更快放弃 —— 这不是时序不一致，是错误处理策略不同
beforeunload 和 unload 在现代浏览器中为何常失效
这两个钩子不是“不执行”，而是被浏览器主动限制了行为能力：
-
beforeunload只有在用户有“有效交互”后才允许弹出确认框（比如点击、输入、focus()），纯 JS 调用location.href或定时器触发导航不会激活它 - Chrome 95+、Edge 95+、Safari 15.4+ 已移除自定义提示文案支持，只显示统一提示：“离开此页面？已做的更改可能不会保存。” —— 所以你写
e.returnValue = '确定要离开？'是无效的 -
unload在大多数现代浏览器中已被降级为“尽力而为”：页面切换瞬间可能被直接终止，回调函数大概率来不及执行；fetch()在unload中发起也不会发送出去（除非用navigator.sendBeacon()）
Web Components 的 connectedCallback 为什么有时不触发
它只在元素真正挂载到主文档（document）时调用，不是写进 HTML 就算，也不是每次 appendChild() 都触发 —— 容易踩坑点：
立即学习“前端免费学习笔记（深入）”；
- 如果组件被创建后先
appendChild()到一个临时DocumentFragment，再移到document.body，connectedCallback只在第二次操作时触发一次 - 使用
innerHTML插入含自定义元素的字符串，某些浏览器（如旧版 Safari）会延迟解析，导致connectedCallback比预期晚几毫秒触发 - Shadow DOM 内部的子组件，其
connectedCallback触发时机取决于父组件是否已挂载 —— 不要假设父子组件的钩子会按 HTML 书写顺序同步执行
跨浏览器测试时最该盯住的三个信号
别盯着“钩子是否调用”，要看“调用时机是否符合预期逻辑”：
- 用
performance.now()打点记录DOMContentLoaded和load时间差，对比 Chrome/Firefox/Safari —— 如果某浏览器差值异常大（比如多出 2s），大概率是某个资源加载阻塞或重定向链过长 - 检查
document.readyState在各阶段的值："loading"→"interactive"→"complete"，若某浏览器卡在"interactive"不动，说明有同步脚本死锁或解析异常 - 监听
document的readystatechange事件，配合console.timeLog()，能暴露 WebKit 内核对defer脚本执行时机的细微偏差（尤其在 iOS Safari 上）
真正影响一致性的从来不是浏览器内核本身，而是你有没有把异步资源加载、脚本执行顺序、用户交互状态这些变量纳入控制范围。钩子只是通知机制，不是执行保证。
