和的onerror必须内联书写且src/href不可省略，仅捕获加载失败（404、cors等），不响应超时或解析错误；css在旧版safari中需兜底检查cssrules长度，fallback后须置空onerror防循环，路径应为相对路径以兼容file://协议。
script 和 link 标签的 onerror 怎么写才真正生效
浏览器对 <script></script> 和 <link rel="stylesheet"> 的 onerror 事件支持是原生且可靠的，但它只在资源加载失败（404、CORS、网络中断）时触发，不响应超时或解析错误。
- 必须把 fallback 逻辑写在标签内：比如
<script src="main.js" onerror="this.src='fallback.js'"></script>，不能只靠外部 JS 绑定——因为标签可能还没解析完，事件监听就来不及了 - CSS 的
onerror在旧版 Safari 中不触发，得加兜底检查：document.styleSheets[0]?.cssRules?.length === 0可判断是否加载为空 - 避免链式 fallback 失败：比如
this.src='fallback.js'后再失败，不会自动触发第二次onerror，需手动补一层检测或降级到内联脚本 - CDN 切本地时注意路径：若主资源是
https://cdn.com/app.js，fallback 路径应为相对路径如./app.fallback.js，否则 file:// 协议下会解析成系统根目录
fetch 加载 HTML 片段时怎么防白屏和结构错乱
微前端、CMS 嵌入等场景常用 fetch() 拉 HTML 片段，但直接 el.innerHTML = html 极易因网络、状态码、HTML 结构异常导致白屏或 DOM 报错。
- 必须用
AbortController主动设超时（建议1500ms），不能只靠.catch()——卡在 pending 状态的 promise 永不 reject -
response.ok和response.status都要检查：404、500不进 catch，但!r.ok为 true - 对返回文本做最小结构校验：比如
html.trim().startsWith('<div> 或检查是否含 <code>，避免把错误页当有效内容插入 - fallback 区域要提前声明，例如
<div id="widget-fallback" style="display:none">加载失败</div>，失败时只改display，不操作主容器 DOM - 更靠谱的做法是定时轮询：
iframe.contentDocument?.body?.children.length是否为 0，或检查iframe.contentWindow?.location.href是否仍为about:blank - 轮询间隔建议 300–500ms，最多试 3–5 次，避免阻塞主线程
- 若 iframe 用于微前端子应用，fallback 应保留核心导航入口（如跳转链接或按钮），而不是纯文字提示
- 注意：
contentDocument访问跨域 iframe 会抛SecurityError，需先 try/catch 并降级处理 -
/offline.html必须在install阶段明确缓存，且caches.open('v1')和后续caches.match('v1')的缓存名必须完全一致 - fetch 事件里不能只判
navigator.onLine——它不可靠；应以fetch(...).catch()为 fallback 触发条件 -
/offline.html自身引用的资源（CSS/JS/图片）也得进缓存，否则离线打开仍是白屏或样式错乱 - SW 只拦截同源下注册路径的子路径：比如注册在
/sw.js，就管不了/admin/sw.js；检查 Application 面板中 SW 的 “Scope” 是否匹配当前页面 URL
iframe 加载失败为什么 onerror 基本没用
<iframe></iframe> 的 onerror 在跨域下几乎失效（安全限制），同域下也常因 DOM 尚未 ready 导致事件丢失；load 事件又无法区分“成功”和“HTTP 200 + 空 body”这类静默失败。
Service Worker 离线 fallback 页面为什么没生效
注册 SW 后离线打不开 /offline.html，常见原因不是代码逻辑错，而是缓存链路断在某个环节。
