DOMContentLoaded事件在HTML解析完成、DOM树构建完毕时触发，不等待CSS、图片等资源加载；同步脚本会阻塞其触发，正确做法是统一监听该事件并避免依赖未就绪的样式或尺寸计算。
DOMContentLoaded 时机错位直接拉低代码可维护性
把初始化逻辑写在 load 里，或者靠 <script> 放在 </body> 前“赌位置”，是多数人对生命周期理解模糊的直接体现。这类写法会导致 DOM 操作延迟 200–800ms，尤其在含大图、第三方字体或 CDN 不稳时更明显。
常见错误现象：document.getElementById('form').addEventListener('submit', ...) 在 load 中执行，但用户首屏点击已发生；querySelectorAll('[data-component]') 返回空 NodeList，因为脚本执行早于 DOM 解析完成。
- 正确做法：统一用
document.addEventListener('DOMContentLoaded', handler)，且确保 handler 不依赖图片尺寸、getComputedStyle或外部 CSS 计算值 - 阻塞陷阱：未加
defer的同步脚本（尤其第三方 SDK）会推迟DOMContentLoaded，建议用performance.getEntriesByType('navigation')[0].domContentLoadedEventEnd监控实际耗时 - SSR 场景下需注意：服务端渲染的 DOM 已存在，但 JS 初始化仍必须等客户端
DOMContentLoaded，不能假设dataset在<script>内立即可用
beforeunload 的“弹窗幻觉”让业务逻辑不可测
beforeunload 看似是拦截离开的最后防线，但它在真实环境里几乎无法稳定触发——Safari 静默忽略非用户手势后的监听器，Firefox 对含异步操作的回调直接跳过，Chrome 则要求页面至少有一次焦点/输入事件才允许弹窗。
常见错误现象：表单草稿未保存提示在 Safari 打开后完全不出现；fetch() 发送埋点日志失败，因为 beforeunload 回调中禁止异步操作；event.returnValue = '确定离开？' 在 Chrome 120+ 已被忽略，只认 event.preventDefault() 且仅限用户主动导航。
立即学习“前端免费学习笔记（深入）”；
- 实操底线：仅用它做最简状态标记（如
sessionStorage.setItem('unsaved', 'true')），别发请求、别改 DOM、别依赖返回值 - 替代方案：对关键表单用
input/change事件实时标记脏状态，配合pageshow检查event.persisted来恢复上下文 - 兼容性红线：iOS Safari 中 iframe 子页面的
beforeunload不触发；PWA 环境下部分 Android WebView 完全跳过该事件
data-* 属性读取时机不当导致初始化失效
data-* 是静态键值对，没有响应式能力，也无自动生命周期绑定。很多团队把它当“配置注入口”，却在 DOMContentLoaded 前就访问 dataset，拿到 undefined 还以为是 SSR 渲染问题。
常见错误现象：const config = JSON.parse(document.body.dataset.config) 报错 Cannot read property 'config' of undefined；自定义元素中 this.dataset.userId 始终为空，但 HTML 里明明写了 data-user-id="123"。
- 安全读取点：必须在
DOMContentLoaded后，且确保目标元素已解析（document.body最稳妥，document.querySelector需加存在判断） - 大小写陷阱：
data-api-key→dataset.apiKey，但监听或getAttribute必须用完整小写连字符形式 - Custom Element 场景：首次值需在
connectedCallback中用this.getAttribute('data-user-id')读取；变更响应必须显式声明static get observedAttributes() { return ['data-user-id']; }
pageshow/persisted 值误判引发状态污染
以为 pageshow 就是“页面加载完成”，结果在 Chrome 里从 bfcache 恢复时复用了旧定时器、未清理的 IntersectionObserver、甚至残留的 WebSocket 连接——这是把 persisted: true 当透明的典型后果。
常见错误现象：用户后退到列表页，滚动位置重置失败；图表组件重复渲染两次；setTimeout 在缓存恢复后突然批量触发。
- 必检条件：所有
pageshow处理逻辑开头加if (e.persisted) { /* 清理 + 重置 */ } else { /* 全量初始化 */ } - 内核差异：Firefox 默认不启用 bfcache，
persisted常为false；Safari 的persisted几乎总为true，但恢复极快，DOM 可能尚未重绘 - 隐藏风险：bfcache 页面冻结时，
requestIdleCallback和setTimeout会被暂停，恢复后可能集中执行，需在pageshow中手动 cancel 并重建
实际落地时最易被忽略的，是 pageshow 和 beforeunload 的组合使用边界：前者负责状态恢复，后者只做轻量标记，两者之间没有隐式因果关系。任何试图用 beforeunload “保存状态”再靠 pageshow “恢复”的设计，在 Safari 或 Firefox 下大概率断裂。
