如何设计一个基于 IntersectionObserver 的模块化首屏静态资源自动预取方案

基于IntersectionObserver的模块化首屏预取系统分为观察器、资源识别、预取执行、策略控制四模块，按需感知视口变化，分级加载资源，职责解耦、可插拔、易配置。

设计一个基于 IntersectionObserver 的模块化首屏静态资源自动预取系统，核心在于“按需感知 + 分级加载 + 模块解耦”。它不是盲目预取所有链接或图片，而是围绕用户真实滚动行为与视口可见性，智能触发关键资源的提前获取，同时保持各功能职责清晰、可插拔、易配置。

模块划分：四层职责分明

系统应拆分为四个基础模块，彼此通过标准接口通信，不强耦合：

• 观察器模块（Observer Module）：封装 IntersectionObserver 实例创建、阈值/根容器/容差（rootMargin）配置、批量监听与销毁逻辑；对外暴露 observe(el, options) 和 unobserve(el) 方法。
• 资源识别模块（Resource Matcher）：定义哪些元素属于“可预取资源”，例如：
  – 带 data-prefetch="true" 的 <a> 标签（用于页面跳转）
  – 含 data-src 或 data-bg 的 <img>/<div>（用于媒体资源）
  – 具有 data-module="xxx" 的容器（用于懒加载 JS 模块）
• 预取执行模块（Fetcher Module）：根据资源类型调用对应策略：
  – 对 HTML 页面：使用 fetch(url, { method: 'HEAD' }) 预热连接，或用 <link rel="prefetch"> 交由浏览器调度
  – 对图片/CSS/JS：发起轻量 fetch() 并缓存至 cacheStorage 或内存 Map
  – 对模块脚本：动态 import() 后暂存为 Promise，供后续按需 await
• 策略控制模块（Policy Orchestrator）：统一管理开关与规则，例如：
  – 是否启用悬停增强（mouseenter 触发额外预取）
  – 是否限制并发请求数（如最多 2 个预取任务并行）
  – 是否在节流网络（navigator.connection.effectiveType === '2g'）下禁用图片预取

IntersectionObserver 的关键配置要点

预取效果高度依赖 Observer 的参数设置，不能直接套用默认值：

• rootMargin 推荐设为 "100px 0px"：让资源在进入视口前 100px 就开始预取，兼顾及时性与不过度激进；移动端可加大至 "200px" 以适应慢速滚动。
• threshold 使用 [0.05, 0.25, 0.5]：不只等元素完全可见（1.0），而是在 5%、25%、50% 可见时分阶段响应——比如 5% 时发起 DNS 预解析，25% 时建立 TCP 连接，50% 时真正 fetch 资源。
• 避免监听整个 document.body：应限定作用域，例如只监听 main 区域或带 data-prefetch-scope 属性的容器，防止误触导航栏、页脚等非首屏内容。

模块间协作流程（以图片懒加载为例）

当用户滚动使一张占位图进入视口时，系统执行以下链路：

• 观察器模块捕获 entry.isIntersecting === true，触发回调，并传入该 <img > 元素。
• 资源识别模块解析该元素，确认其为图片资源，提取 data-src 值，并打上唯一 key（如 hash('hero.jpg')）。
• 策略控制模块检查当前网络状态与并发数，允许本次预取后，通知预取执行模块发起 fetch('hero.jpg') 并存入内存缓存。
• 待真实渲染时机（如组件挂载或 load 事件），从缓存读取二进制数据或 URL，赋值给 img.src，实现毫秒级呈现。

扩展性与降级保障

模块化系统必须考虑现实兼容性与异常场景：

• 若浏览器不支持 IntersectionObserver，观察器模块自动 fallback 到 scroll + requestIdleCallback 组合：滚动时节流触发，再用 requestIdleCallback 延迟执行可见性粗略判断。
• 每个模块导出独立的 install() 和 teardown() 方法，便于在 SPA 中随路由切换启停特定范围的预取（如仅对 article 页面启用图片预取）。
• 提供全局钩子事件，如 prefetch:start、prefetch:success、prefetch:error，方便业务层埋点或 UI 反馈（如显示预取进度条）。