link.onerror不可靠，应改用fetch预检+动态插入fallback；需确保唯一性、避免FOUC、控制路径与响应头。
动态创建 link 元素后，onerror 不触发怎么办
动态插入的 <link rel="stylesheet"> 在加载失败时，onerror 事件**不一定可靠触发**——尤其在 Chrome 100+ 和 Safari 16+ 中，CSS 加载失败常静默忽略，不抛事件。这不是 bug，而是规范行为：link 的 onerror 只对「解析阶段失败」（如语法错误）有效，对「网络失败」或「404/500」响应基本不触发。
真正可用的 fallback 路径是：用 fetch() 预检资源可访问性，再决定是否插入 link；或改用 document.styleSheets + load 事件监听（需配合 rel="preload" 提前声明）。
- 不要依赖
link.onerror做降级主逻辑，它不可靠 - 若坚持用
onerror，必须在appendChild()前绑定，且立即清空 handler：link.onerror = () => { link.onerror = null; loadFallbackCSS(); }; - 更稳妥的做法是：先
fetch(url, { method: 'HEAD' }).then(r => r.ok).catch(() => false)，成功后再appendChild
fetch() 检测 CSS 加载失败后，如何避免重复插入或样式抖动
用 fetch() 做预检能提前发现 404、CORS 或 CDN 失效，但直接插入新 link 可能导致样式覆盖、FOUC（Flash of Unstyled Content），甚至因多次重试造成 DOM 泄漏。
关键控制点在于「唯一性」和「时机」：确保同一 URL 最多只尝试一次，且 fallback 插入前移除原 link（如果已存在），同时避免在 DOM 尚未 ready 时操作。
立即学习“前端免费学习笔记（深入）”；
- 用
Map缓存已检测过的 URL 状态：const cssLoadStatus = new Map();，插入前查缓存 - 插入 fallback 前，先
document.head.querySelector(`link[href="${fallbackUrl}"]`)判断是否已存在 - 避免在
DOMContentLoaded前插入样式表；如需尽早生效，用document.write(<style>...</style>)内联基础样式（仅限关键降级） - 插入后调用
document.styleSheets[document.styleSheets.length - 1].disabled = false显式启用（某些旧 WebView 需要）
CDN CSS 加载失败时，本地 fallback 如何避免路径错乱
从 https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css 切换到本地 /css/bootstrap.fallback.css，看似简单，但实际容易因路径解析规则出错：相对路径在不同 HTML 位置下解析结果不同，file:// 协议下跨域请求被拦截，或构建后 public 目录层级变化导致 404。
根本解法不是“换地址”，而是让 fallback 资源与主资源**语义一致、路径可控、体积最小化**。
- fallback 文件应放在与主资源同域名、同路径层级下（例如都走
/static/css/），避免协议/路径跳变 - fallback CSS 内容应极简：只包含关键重置（
body { margin: 0; font-family: sans-serif; }）和核心布局（.container { width: 100%; }），不引入额外依赖 - 禁用本地 fallback 的缓存（
Cache-Control: no-cache），防止 fallback 本身过期失效 - 若用 Webpack/Vite，可通过
import.meta.env.PROD && import('./fallback.css')方式静态导入，由构建工具处理路径
Service Worker 中拦截 CSS 请求做降级，为什么有时 fallback 不生效
在 service-worker.js 中用 caches.match(event.request) + fetch().catch() 返回备用 CSS，逻辑清晰，但实际部署后常出现 fallback 样式未应用的情况。问题往往不在代码，而在缓存策略与浏览器解析顺序。
CSS 是阻塞渲染的关键资源，SW 返回的 fallback 必须满足两个硬性条件：响应头 Content-Type: text/css，且内容为合法 CSS 语法（哪怕只有 /* fallback */）。否则浏览器会静默丢弃，继续白屏。
- 返回 fallback 前必须显式设置
headers: { 'Content-Type': 'text/css' }，否则 Chrome/Firefox 拒绝解析 - fallback CSS 内容不能为空或仅注释；至少写一条有效声明，如
body { opacity: 1; }，否则部分 WebView 认为“无效样式表”而跳过 - 确保 SW 已激活并控制当前页面（检查
navigator.serviceWorker.controller），未激活时 fetch 事件根本不会触发 - 不要在 fallback 中引用其他外部资源（如
@import url(...)或url(./font.woff)），这些子请求不受当前 SW 控制
真正的难点不在“怎么写 fallback”，而在于降级必须在用户无感知的前提下完成。CSS 加载失败的窗口期极短（通常 < 500ms），任何异步延迟、DOM 重排、或二次网络请求都会放大 FOUC 或布局偏移。最稳的方案永远是：精简 fallback 内容 + 同步注入 + 路径绝对可控。
