document.readyState 有 loading、interactive、complete 三种值：loading 表示 HTML 正在解析；interactive 表示 DOM 构建完成、body 可访问但外部资源仍在加载；complete 表示所有资源加载完毕。
document.readyState 有哪些可能值，分别代表什么阶段
document.readyState 是浏览器同步暴露的文档加载状态标识，共三种取值：loading、interactive、complete。它们不是时间戳，而是 DOM 构建过程中的关键里程碑：
-
loading：HTML 文档正在解析中，<script>同步执行时常见于此阶段；此时document.body可能还不存在 -
interactive：DOM 构建完成（即DOMContentLoaded已触发），但外部资源（如图片、样式表、异步脚本）仍在加载；document.body和大部分节点已可安全访问 -
complete：所有资源（包括图片、iframe 等）全部加载完毕；等价于window.onload触发时机，通常较晚
白屏优化的关键，是尽早获取可操作的 DOM 节点并启动渲染逻辑，而不是等整个页面“彻底加载完”——所以 interactive 是最值得盯住的状态。
为什么不能只靠 DOMContentLoaded 或 window.onload
这两个事件看似覆盖了加载流程，但存在实际偏差：
-
DOMContentLoaded不保证document.body已挂载（尤其在内联脚本位于<head>且 DOM 尚未解析到<body>时，document.body为null） -
window.onload会等待所有资源（含第三方 tracker 图片、字体文件等），极易被阻塞，白屏时间不可控 - 某些构建工具（如 Vite）或 SSR 框架（如 Nuxt）会在首屏注入 hydration 脚本，若依赖
document.body却没做存在性检查，直接报Cannot read property 'appendChild' of null
而 document.readyState === 'interactive' 是一个更早、更稳定、且与 DOM 可用性强相关的信号——它意味着 HTML 解析结束、document.body 必然存在，且 JS 执行不会打断渲染主线程。
如何安全地在 interactive 阶段执行初始化逻辑
不能简单轮询或只判断一次，需结合状态监听与降级兜底：
- 立即检查当前状态：若已是
interactive或complete，直接执行初始化函数 - 否则监听
readystatechange事件，只响应一次interactive状态到达（避免重复触发） - 加 5s 超时兜底：防止极端情况（如解析卡死、事件未触发），超时后强制执行（至少保障功能可用）
- 务必包裹
if (document.body)判断，即使状态是interactive，极少数 iframe 场景或特殊 polyfill 下仍可能短暂为空
示例精简写法：
function runWhenInteractive() {
if (document.readyState === 'interactive' || document.readyState === 'complete') {
initApp();
return;
}
let triggered = false;
const handler = () => {
if (triggered) return;
if (document.readyState === 'interactive') {
triggered = true;
initApp();
document.removeEventListener('readystatechange', handler);
}
};
document.addEventListener('readystatechange', handler);
setTimeout(() => {
if (!triggered && document.body) {
triggered = true;
initApp();
}
}, 5000);
}
和 defer、async 脚本的配合要点
defer 脚本本身就在 DOM 解析完成后执行，天然接近 interactive 阶段，但仍有细节差异：
-
defer脚本的执行时机 ≈DOMContentLoaded，不等于interactive—— 因为多个defer脚本按顺序执行，若前一个耗时长，后一个仍会延迟 - 把核心初始化逻辑放在
defer脚本里，再用document.readyState判断，比纯靠defer更可控 -
async脚本完全不可预测，可能在loading阶段就执行，此时document.body极大概率不存在，必须避免在此类脚本中直接操作 DOM - 服务端渲染（SSR）场景下，hydration 脚本建议设为
defer，并在内部用document.readyState做双保险，防止客户端首次 render 时因 DOM 未就绪而失败
真正影响白屏的是「首个可交互像素」出现的时间点，而不是脚本何时下载完——interactive 是这个时间点最贴近的可编程锚点，但它不会自动帮你减少 JS 体积或优化 CSS 关键路径，这些仍需单独处理。
