link.onload不可靠，因其仅表示网络获取完成，不反映CSS是否解析生效或有无错误；应结合link.sheet与cssRules轮询、事件监听及超时兜底三重策略判断加载完成。
link.onload 为什么不能直接信
link.onload 触发 ≠ CSS 已解析生效，也不代表没出错。它只表示“网络层资源获取完成”，但以下情况照样触发：
• CSS 文件返回 404 或 500，onload 照常执行（onerror 不会触发）
• 跨域 CSS 被 CORS 拦截，控制台报错但 onload 仍触发
• CSS 内容为空、语法错误、或仅含 @import 未解析完成，sheet.cssRules 仍为 0
• IE9 及更早、旧版 Safari/Chrome 根本不支持 onload，事件监听直接失效
真正可用的判断依据是 link.sheet 和 cssRules
浏览器是否把样式表真正“挂载”到 DOM 并可供 JS 访问，取决于 link.sheet 是否存在，以及其 cssRules 是否可读且非空：
• 同源 CSS：检查 link.sheet?.cssRules?.length > 0，这是最可靠的就绪信号
• 跨域 CSS：访问 link.sheet.cssRules 会抛 SecurityError（ex.code === 1000），此时应视为“加载完成但不可读”，可继续后续逻辑
• Firefox ≤ v89：必须访问 cssRules 才能触发检测，仅判 sheet 存在不够
• 注意：首次读取 cssRules 会强制触发样式计算，可能引发 layout thrashing，轮询间隔至少设为 16ms（一帧）
推荐组合策略：事件 + 轮询 + 超时兜底
单押一种方式必然漏 case，生产环境应同时覆盖三类路径：
• 优先监听 link.addEventListener("load", handler, { once: true }) —— Chromium/Firefox/Edge 最快路径
• 立即启动轮询：先判 link.sheet，再 try/catch 读 cssRules，捕获 SecurityError 当作成功
• 设置总超时（如 5000ms），超时后无论状态如何都回调，避免阻塞主流程
• 回调函数签名建议为 (err, link)，err === null 表示“尽力而为后认为可用”，不是绝对成功
• 避免用 setTimeout(..., 1) 高频轮询：页面切后台时会被节流，建议改用 requestIdleCallback 或至少 16ms 间隔
容易被忽略的兼容细节
IE 和老版 WebKit 不支持 addEventListener("load")，得回退到 attachEvent("onload")；但注意：
• attachEvent 在 IE6–9 中对 404 也会触发 onload，必须配超时兜底
• onerror 在所有浏览器中对 CSS 都静默失效，别指望它报错
• 动态插入前最好查重：用 document.querySelector('link[href="xxx"]') 避免重复加载同一 CSS
• 如果 CSS 里有 @import，cssRules.length > 0 只表示主文件解析完，子资源仍可能异步加载——这种场景需额外处理，不在基础判断范围内
立即学习“前端免费学习笔记（深入）”；
