是，DOMContentLoaded在现代浏览器中逻辑一致：HTML解析完成、DOM树构建完毕、document.readyState === 'interactive'时触发，但因解析器策略、JS引擎差异等存在毫秒级时间偏差。
DOMContentLoaded 在 Chrome/Firefox/Safari/Edge 中是否总是一致？
是，只要不混用异步脚本、不依赖未就绪资源，DOMContentLoaded 的触发时机在所有现代浏览器中逻辑一致：HTML 解析完成、DOM 树构建完毕、document.readyState === 'interactive' 时立即触发。
但实际观测到的「时间点」可能有毫秒级偏差，原因不是钩子本身顺序变了，而是：
- HTML 解析器对
<script>标签的预加载策略不同（比如 Chromium 的 speculative parser 更激进） - 内联脚本执行耗时受 JS 引擎优化影响（V8 vs SpiderMonkey vs JavaScriptCore 对相同代码的编译速度差异）
- 某些浏览器（如旧版 Safari）在遇到
<link rel="preload">时会提前触发部分资源加载，间接影响 DOM 构建节奏
这不是 bug，也不影响你写逻辑——只要不把 DOMContentLoaded 回调里的时间戳当绝对基准就行。
document.readyState === 'interactive' 能否被 reliably 捕获？
不能靠监听事件“稳抓”，必须兜底判断。
立即学习“前端免费学习笔记（深入）”；
document.addEventListener('readystatechange', () => { ... }) 可能漏掉 'interactive' 状态，尤其当脚本紧贴 </body> 插入时，状态切换太快，事件监听器还没注册完，状态已跳到 'complete'。
正确做法是：
- 先检查
document.readyState当前值，如果是'interactive'或'complete'，立刻执行对应逻辑 - 再加监听，覆盖后续变化
- 别在
'interactive'回调里读取getComputedStyle(element).backgroundImage—— CSSOM 可能还没解析完，返回空字符串
load 事件在跨浏览器场景下为什么更不可靠？
window.addEventListener('load', handler) 等的是所有资源：图片、字体、iframe、<object>，但不同浏览器对“资源加载完成”的判定边界不完全一致。
典型差异：
- Firefox 会等所有
<img srcset>候选项中最高 DPR 图片加载完；Chrome 只等当前视口匹配的那张 - Safari 对
<link rel="stylesheet" media="print">不计入load阻塞，而其他浏览器可能计入 - 某些 Edge 版本会因 iframe 内容未触发
load而卡住主页面load，即使 iframe 是 sandboxed
所以，如果你的埋点或初始化逻辑依赖 load，在弱网或含大量第三方 iframe 的页面上，很容易在 Safari 里比 Chrome 晚几百毫秒甚至超时失败。
beforeunload 在 iOS Safari 和 PWA 中为何常失效？
它根本不是“执行顺序差异”，而是平台策略直接阉割了行为。
iOS Safari 对 beforeunload 有硬性限制：
- 仅在非 iframe 主文档中有效
- PWA 安装后以 standalone 模式运行时，该事件被静默忽略（无报错，也不弹窗）
- 用户未产生任何“有效交互”（如 focus input、click button、scroll 页面）前，事件处理器不会被调用
这意味着：你在桌面 Chrome 里测试正常的离开确认逻辑，在 iPhone 上大概率完全不触发。别归因为“执行顺序”，这是能力缺失。
真正需要用户确认的场景（如表单未保存），必须改用 pagehide + 本地标记 + 服务端兜底，而不是死磕 beforeunload。
