学习笔记十一 —— 首屏性能优化

一、首屏性能核心指标与监控原理

1. 关键指标定义
   • FCP（First Contentful Paint）：首次内容渲染时间（文本/图片出现）
   • LCP（Largest Contentful Paint）：最大内容元素（如图片/标题块）渲染时间，Google 核心指标（需 <2.5s）
   • TTI（Time to Interactive）：页面可交互时间（主线程空闲且事件绑定完成）
     监控方案：

   // 使用 PerformanceObserver API 动态捕获
   const observer = new PerformanceObserver((list) => {
     const entries = list.getEntries();
     entries.forEach(entry => {
       if (entry.name === 'first-contentful-paint') {
         console.log('FCP:', entry.startTime);
       }
     });
   });
   observer.observe({type: 'paint', buffered: true});
   

---

二、资源分割与按需加载深度优化

1. 代码分割原理（Webpack 为例）

• 动态导入（Dynamic Import）：
  通过 import() 语法触发代码分块，生成独立 chunk 文件

  // 路由级分割 (Vue Router)
  const Home = () => import(/* webpackChunkName: "home" */ './Home.vue');
  

• SplitChunks 优化策略：
  提取公共依赖与第三方库，避免重复加载

  optimization: {
    splitChunks: {
      chunks: 'all',
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
          chunks: 'all'
        }
      }
    }
  }
  

2. 资源加载优先级控制

• <link rel="preload">：强制浏览器高优先级加载关键资源（如首屏 CSS/字体）
• <link rel="prefetch">：空闲时预加载非关键资源（如其他路由组件）

---

三、服务端渲染（SSR）原理与工程化实践

1. SSR 核心流程

sequenceDiagram
    participant User
    participant Server
    participant Browser
    User->>Server: 请求页面
    Server->>Server: 执行数据获取与组件渲染
    Server->>Browser: 返回完整 HTML + 初始数据
    Browser->>Browser: 直接显示内容（无需等待 JS）
    Browser->>Browser: 加载 JS 进行 Hydration

2. 关键技术与挑战

• 双端协作：Node.js 使用 vue-server-renderer 或 ReactDOMServer 生成 HTML
• 数据预取：在渲染前通过 asyncData() 或 getInitialProps() 获取数据
• Hydration（注水）：客户端 JS 绑定事件，接管动态交互
  常见问题：
• 内存泄漏：避免全局变量在 SSR 环境残留（使用 isServer 标志隔离）
• 第三方库兼容：检查 window 对象访问，通过 dynamic import 延迟加载

3. 框架选择

• Next.js (React) / Nuxt.js (Vue)：内置 SSR 方案，简化路由、数据获取配置

---

四、预渲染（Prerender）技术细节与局限

1. 实现原理

• 构建阶段：启动无头浏览器（Puppeteer）访问指定路由，保存渲染结果为 HTML
• Webpack 集成：

  const PrerenderSPAPlugin = require('prerender-spa-plugin');
  plugins: [
    new PrerenderSPAPlugin({
      staticDir: path.join(__dirname, 'dist'),
      routes: ['/', '/about'],
      renderer: new PuppeteerRenderer({ headless: true })
    })
  ]
  

2. 适用场景与限制

场景	推荐方案	原因
营销页（SEO 优先）	预渲染	静态内容生成快，部署简单
用户仪表盘	CSR + 按需加载	动态数据多，SSR 收益低
高实时数据（股票）	SSR	预渲染无法处理个性化内容

---

五、综合优化策略与进阶手段

1. 资源压缩与传输优化

   • Brotli 压缩：比 Gzip 提升 15%~20% 压缩率（CDN 自动支持）
   • HTTP/2 多路复用：单 TCP 连接并行传输资源，解决队头阻塞

2. 缓存策略设计

   • 强缓存：Cache-Control: max-age=31536000（静态资源）
   • 协商缓存：Etag + If-None-Match 验证资源更新

3. 关键 CSS 内联
   提取首屏必要样式嵌入 <style> 标签，避免 CSS 文件阻塞渲染

4. 图片与字体优化

   • WebP 格式：比 JPEG/PNG 体积减少 30%+
   • 字体子集化：使用 fonttools 提取页面实际用到的字符

---

六、技术选型决策树

graph TD
    A[是否需要 SEO?] -->|是| B{内容是否动态?}
    A -->|否| C[CSR + 按需加载]
    B -->|是| D[SSR]
    B -->|否| E[预渲染]
    D --> F[使用 Next.js/Nuxt.js]
    E --> G[使用 PrerenderSPAPlugin]

---

以下是针对首屏性能核心指标与监控原理的深度解析，涵盖定义、技术原理、业务场景及监控实现方案，结合前端工程实践与业务价值分析：

一、首屏性能核心指标定义与技术原理

1. FP (First Paint，首次绘制)

• 定义：浏览器首次将任何像素渲染到屏幕的时间点（如背景色或默认UI），标志渲染流程启动。
• 原理：浏览器完成解析HTML并构建CSSOM后，开始合成渲染树（Render Tree）时触发。
• 业务场景：
  • 用户感知“页面开始加载”的起点，若FP延迟（>1s），用户可能误判为网络故障。
  • 电商首页：FP过长会导致用户流失率上升（如首屏背景色延迟渲染）。

2. FCP (First Contentful Paint，首次内容绘制)

• 定义：浏览器首次渲染文本、图片、非空白Canvas或SVG等“有意义内容”的时间点。
• 原理：DOM与CSSOM首次合成后，渲染引擎绘制首个内容元素。
• 业务场景：
  • 新闻类网站：首段文字或头条图片的FCP决定用户留存率（FCP<1.5s时跳出率下降40%）。
  • 登录页：表单输入框的FCP影响用户操作意愿。

3. LCP (Largest Contentful Paint，最大内容绘制)

• 定义：可视区域内最大内容元素（如图片、标题块）完全渲染的时间点，Google核心用户体验指标（要求<2.5s）。
• 原理：动态追踪渲染面积最大的元素（面积=元素可见区域面积，图片取渲染尺寸与真实尺寸较小值）。
• 业务场景：
  • 电商Banner图：LCP延迟1秒可导致转化率下降7%。
  • 视频详情页：主视频封面图的LCP是用户停留关键因素。

4. TTI (Time to Interactive，可交互时间)

• 定义：页面完全可交互的时间点（主线程空闲50ms以上，事件绑定完成）。
• 原理：检测长任务（>50ms）结束后连续5秒无长任务，且已发生FCP。
• 业务场景：
  • 后台管理系统：TTI过长（>3s）导致用户重复点击，引发操作错误。
  • 表单提交页：按钮可交互时间影响订单完成率。

5. CLS (Cumulative Layout Shift，累积布局偏移)

• 定义：页面元素意外偏移导致的视觉稳定性指标（要求<0.1）。
• 原理：计算偏移分数 = 影响比例（视口占比） × 移动比例（位移距离/视口高度）。
• 业务场景：
  • 广告页：动态插入广告导致内容下移，CLS>0.3时用户误点率上升50%。
  • 图文混排页：图片延迟加载引发的文字跳动。

---

二、监控原理与工程实现

1. Performance API 核心方法

• performance.getEntriesByType()
  获取特定类型性能条目（如navigation、paint）：

  const fcpEntry = performance.getEntriesByName('first-contentful-paint')[0];
  console.log('FCP:', fcpEntry.startTime);
  

• PerformanceObserver 动态监听
  实时捕获LCP、CLS等新型指标（避免轮询开销）：

  // 监听LCP
  const lcpObserver = new PerformanceObserver(entryList => {
    const entries = entryList.getEntries();
    const lastEntry = entries[entries.length - 1];
    console.log('LCP:', lastEntry.renderTime || lastEntry.loadTime);
  });
  lcpObserver.observe({ type: 'largest-contentful-paint', buffered: true });
  

2. 关键指标计算逻辑

指标	计算方式	精度对比
白屏时间	performance.timing.responseStart - navigationStart	传统API误差±100ms
FCP	performance.getEntriesByType('paint')	精确到毫秒级
TTI	tti-polyfill库检测长任务结束	比domContentLoadedEventEnd更准确

3. 业务场景监控实践

• 电商大促场景
  • 问题：北美用户LCP P90 > 3s（因CDN节点延迟）
  • 方案：分地域部署监控（北美/欧洲独立数据空间），Brotli压缩HTML（体积降40%）
• 高交互后台系统
  • 问题：TTI受第三方脚本阻塞（如数据分析SDK）
  • 方案：async加载非关键JS，Web Worker隔离长任务

---

三、业务价值与优化方向

1. 指标与用户体验的量化关系

• LCP ≤ 2.5s → 用户转化率提升18%（电商案例）
• CLS ≤ 0.1 → 广告误点击减少30%
• TTI ≤ 3s → 用户操作错误率下降25%

2. 技术选型决策矩阵

业务类型	核心指标	优化优先级
电商/营销页	LCP, CLS	预渲染 + 图片懒加载
后台管理系统	TTI, FID	代码分割 + Worker隔离
内容型网站（如新闻）	FCP, LCP	SSR + 字体子集化

3. 监控体系闭环设计

graph LR
A[指标采集] --> B(Performance API)
B --> C[数据上报SDK]
C --> D{监控平台}
D --> E[报警策略：P90 LCP>2.5s]
D --> F[优化建议：HTML压缩/CDN调优]
F --> A

---

四、面试回答要点

1. 原理深度：

   • 解释LCP的“渲染面积”算法（图片尺寸取min(渲染尺寸, 真实尺寸)）
   • 对比TTI的domContentLoaded与长任务检测差异

2. 业务结合：

   • 举例说明CLS>0.1如何导致电商页面购买按钮误点击
   • 分析跨境电商分地域监控的必要性（时延敏感度差异）

3. 工程落地：

   • 使用PerformanceObserver替代addEventListener避免漏检
   • 采用P90/P99分位数（非平均值）定义性能达标线

---

对于动态内容丰富的单页应用（SPA），准确计算可交互时间（TTI）是性能优化的核心挑战。TTI 的复杂性在于其不仅依赖资源加载，更与主线程任务调度、动态内容渲染及框架执行逻辑紧密相关。以下是系统性解析：

一、SPA 中 TTI 计算的复杂性及核心挑战

1. 动态内容对 TTI 计算的干扰

• 路由异步加载：SPA 的路由切换依赖异步组件加载，传统 TTI 计算（基于初始 FCP 后的静默窗口）可能忽略后续路由的阻塞任务。
• 数据驱动渲染：如 Vue/React 的响应式更新，可能因状态变更触发多次渲染，导致主线程长任务分散，难以定位“静默窗口”。
• 框架 Hydration 延迟：SSR 应用的注水过程（将静态 HTML 转为可交互）占用主线程，但此阶段常被误判为“可交互”。

2. 传统 TTI 计算方法的局限

TTI 标准定义为：从 FCP 开始，找到连续 5 秒无长任务（>50ms）且未完成网络请求 ≤2 个的时间窗口，并回溯最后一个长任务的结束时间。但在 SPA 中此方法失效：

• 静默窗口误判：SPA 的 Ajax 请求与 WebSocket 持续占用网络信道，导致“未完成请求数”持续超标。
• 长任务分布离散：交互事件监听器、虚拟 DOM Diff 等任务可能分散在多个事件循环中，无法形成连续静默期。

---

二、准确计算 TTI 的方法与工具链

1. 分阶段监控策略

阶段	监控目标	工具与 API
初始加载	FCP、资源加载完成	performance.getEntriesByType('paint')
框架初始化	主线程长任务分布	PerformanceObserver 监听 longtask
路由切换	新路由的 FCP 与 TTI	结合 router.beforeEach 与 router.afterEach 钩子重置监控
用户交互响应	首次输入延迟（FID/INP）	PerformanceObserver 监听 first-input 或使用 web-vitals 库

2. 工具链推荐

• web-vitals 库：
  提供 onTTI 的 Polyfill 实现，结合 FCP 与长任务自动修正 SPA 场景：

  import { onTTI } from 'web-vitals';
  onTTI((metric) => console.log('TTI:', metric.value));
  

• 自定义性能标记：
  在框架生命周期关键节点打标（如 vue:mounted / react:componentDidMount），结合 performance.mark() 记录时间点。
• Chrome DevTools 的 Performance Panel：
  通过录制交互过程，手动定位长任务簇的结束位置（主线程空白区）。

---

三、常见误区与解决方案

1. 误区 1：将 DOMContentLoaded 视为 TTI

• 问题：SPA 的 DOMContentLoaded 仅表示初始 HTML 解析完成，但框架 JS 可能仍在执行。
• 解决：监控 longtask 而非 DOM 事件，使用 tti-polyfill 替代标准检测。

2. 误区 2：忽略路由级联阻塞

• 问题：首页 TTI 达标，但子路由因懒加载组件触发新长任务，用户切换路由时仍卡顿。
• 解决：
  • 预加载关键路由资源：<link rel="prefetch" href="route-component.js">
  • 拆分长任务：将组件初始化逻辑拆解为 requestIdleCallback 分片执行。

3. 误区 3：第三方脚本阻塞未被纳入计算

• 问题：数据分析 SDK（如 Google Analytics）注入的同步脚本延迟主线程，但传统 TTI 计算可能遗漏。
• 解决：
  • 异步加载第三方脚本：<script async src="analytics.js">
  • 使用 Web Worker 隔离：将非 UI 相关逻辑（如日志上报）移入 Worker。

---

四、SPA 专属优化策略

1. 渐进式 Hydration
   • 将 SSR 返回的静态页面分区块注水，优先注水首屏区域，其余部分延迟执行（如 React 的 useDeferredValue）。
2. 预缓存动态路由
   • 使用 Service Worker 预缓存懒加载路由，减少切换时的网络请求与解析开销。
3. 计算密集型任务卸载
   • 案例：某 CAD 类 SPA 将几何计算（如 jsts 库）移至 WebAssembly，TTI 从 11.2s 降至 5.8s。

---

五、TTI 的演进与替代指标

随着 Web 应用复杂度提升，TTI 因静默窗口定义的机械性和对持续交互场景的盲区，已被 Lighthouse 弃用，转而推荐：

1. INP（Interaction to Next Paint）
   测量从用户交互到屏幕下一次更新的全链路延迟，更贴近动态 SPA 的体验。
2. TBT（Total Blocking Time）
   量化 FCP 到 TTI 之间所有长任务阻塞总时长，反映累积卡顿（如：两个 50ms 任务比一个 100ms 任务更优）。

---

结论：SPA 的 TTI 优化需以“用户感知”为核心

• 监控层面：采用分段式指标（路由级 TTI）+ 真实用户监控（RUM）替代实验室数据。
• 优化层面：聚焦长任务分片、第三方脚本治理、框架生命周期精准控制。
• 技术演进：拥抱 INP 等新指标，结合 web-vitals 实现自动化监控闭环。

---

以下系统解析资源分割与按需加载的设计原理、技术实现和工程实践，助你展现架构级思考能力：

一、按需加载的核心目标与技术分类

1. 设计目标

• 首屏时间优化：通过延迟非关键资源加载，将初始JS体积减少60%-80%
• 带宽效率提升：避免加载未使用代码，降低用户流量消耗（尤其移动端）
• 缓存利用率最大化：细粒度代码块使缓存命中率提升40%+

2. 技术分类与适用场景

策略类型	技术实现	适用场景	优化收益
路由级分割	React.lazy / Vue异步组件	多路由SPA	首屏JS体积↓70%
组件级按需加载	动态import() + 交互触发	复杂仪表盘中的折叠面板/弹窗	交互响应速度↑50%
第三方库动态加载	异步script标签加载CDN资源	非核心库（如数据分析SDK）	主线程阻塞时间↓200ms
数据分片加载	GraphQL @defer / REST分页	长列表/报表系统	内存占用峰值↓45%

---

二、动态导入的底层原理与浏览器协作

1. ECMAScript动态导入机制

// 底层转化为Promise链
const module = await import('./module.js');
// 等效于
__loadModule('./module.js').then(module => {
  window.__MODULE_CACHE.set('./module.js', module);
});

• 模块加载阶段：浏览器创建<script type="module">发起请求，不阻塞主线程
• 执行阶段：模块下载完成后向微任务队列插入执行任务

2. 浏览器引擎优化策略

• 预解析器并行下载：Chrome在解析HTML时提前扫描import()请求
• 加载优先级调整：

  graph LR
    A[初始HTML] --> B[主线程解析]
    B --> C{发现import()}
    C --> D[Preload Scanner预加载]
    D --> E[网络线程下载]
    E --> F[不影响FP/FCP]
  

---

三、构建工具深度优化策略

1. Webpack代码分割三阶模型

// webpack.config.js
optimization: {
  splitChunks: {
    chunks: 'all',
    cacheGroups: {
      vendors: {
        test: /[\\/]node_modules[\\/]/,
        priority: -10 // 第三方库优先拆分
      },
      commons: {
        minChunks: 2, // 被2+入口引用的模块
        reuseExistingChunk: true
      }
    }
  },
  runtimeChunk: 'single' // 避免runtime变更导致缓存失效
}

2. Tree Shaking进阶实践

• 副作用精准标注：

  // antd的package.json配置
  "sideEffects": [
    "dist/*.css", 
    "es/**/style/*"
  ]
  

• 函数级摇树：通过/*#__PURE__*/标注无副作用函数

  export /*#__PURE__*/ const utils = {
    // 纯函数可被安全移除
  }
  

---

四、框架级最佳实践与陷阱规避

1. React异步加载模式

// 错误示例：直接使用import()导致闪退
const LazyComp = React.lazy(() => import('./Comp'));

// 正确方案：错误边界+加载态
<ErrorBoundary>
  <Suspense fallback={<Skeleton />}>
    <LazyComp />
  </Suspense>
</ErrorBoundary>

2. Vue组件级优化技巧

// 路由配置中实现预加载
{
  path: '/dashboard',
  component: () => import(/* webpackPrefetch: true */ './Dashboard.vue')
}

• 预加载时机：浏览器空闲时加载<link rel="prefetch">

3. 加载状态管理策略

体验层级	技术方案	用户感知
骨架屏	CSS content-visibility: auto	瞬时呈现布局框架
渐进式加载	图片懒加载 + 组件分阶段渲染	内容有序出现无闪烁
错误降级	错误边界 + 备用组件	避免白屏保持可用性

---

五、性能与体验的平衡艺术

1. 加载性能量化模型

// 计算加载收益的决策公式
const shouldSplit = 
  (moduleSize > 30KB) && 
  (usageProbability < 0.3) && 
  (userNetwork === '4G');

2. 预加载智能决策

graph TD
  A[用户行为分析] --> B{预测高概率路径}
  B -->|首页→详情页| C[预加载详情模块]
  B -->|搜索框聚焦| D[预加载搜索结果模板]
  B -->|低端设备| E[降低预加载粒度]

3. 缓存策略设计

• 版本化长效缓存：

  # Nginx配置
  location /static {
    expires 1y;
    add_header Cache-Control "public, immutable";
  }
  

• 动态更新机制：通过contenthash命名文件

  output: {
    filename: '[name].[contenthash:8].js'
  }
  

---

六、面试深度回答建议

1. 原理溯源：

   • 解析import()如何被转译为__webpack_require__.e
   • 对比HTTP/2多路复用与HTTP/1.1下分割的收益差异

2. 工程化思维：

   • 举例说明如何根据用户设备类型（PC/移动）动态调整分割阈值
   • 设计分割效果监控系统（如统计chunk利用率）

3. 框架深度：

   • 分析Vue的defineAsyncComponent与React的lazy实现差异
   • 讨论Next.js的dynamic import如何与SSR协同工作

4. 演进趋势：

   • 基于ESM的import map如何替代Webpack（Vite实践案例）
   • 边缘计算环境下按需加载的新范式（Cloudflare Workers +模块热加载）

设计决策闭环示例：
在电商详情页优化中，通过将「商品评价组件」拆分为独立chunk并设置webpackPreload，使LCP从2.4s降至1.1s，同时预加载错误率需监控控制在<0.1%（通过navigator.connection动态调整策略）。

---

我们来真正深入动态导入（import()）的底层原理和浏览器协作机制。核心在于理解它是如何在不阻塞主线程的情况下，实现模块的异步加载、解析和执行的，以及与浏览器渲染管线的协作。

一、浏览器如何原生处理动态导入 (import())

抛开框架和构建工具，看浏览器本身如何处理ESM的动态导入：

1. 它不是函数，而是特殊语法：
   import() 看起来像函数，但它是ECMAScript标准定义的特殊语法关键字。你不能给它赋值（const myImport = import; 会报错）。浏览器引擎（如V8）在解析阶段就能识别它。

2. 触发异步加载流程：

   • 主线程不阻塞： 当JS引擎执行到 import('./module.js') 时，不会停下来等待这个模块加载完成。它立即返回一个 Promise 对象。
   • 网络线程接管： 浏览器内部的网络线程被触发，负责发起对 ./module.js 文件的HTTP(S)请求。此时主线程可以继续执行后续同步代码。

3. 模块的加载、解析与执行：

   • 下载完成： 网络线程下载完 module.js 文件内容。
   • 解析（Parse）： 浏览器（通常是渲染引擎中的模块解析器）开始解析下载的JS文本。这包括：
     • 词法分析/语法分析： 将代码转换成AST（抽象语法树）。
     • 解析import/export： 识别模块的依赖关系（它内部又 import 了哪些模块？）。
     • 构建模块记录（Module Record）： 创建一个包含模块导出/导入信息、代码等内部数据结构。
   • 获取依赖（递归）： 如果 module.js 内部又静态 import 了其他模块（如 import { helper } from './helper.js'），解析器会发现这些依赖，并递归地触发这些依赖模块的加载、解析过程。这构建了一个模块依赖图。
   • 执行（Evaluation）： 关键点！ 只有当 module.js 及其所有依赖模块都成功完成解析（注意，不是下载！）后，它的顶层代码才会被执行。执行顺序遵循依赖图的拓扑排序（依赖先于使用者执行）。执行过程：
     • 初始化模块作用域。
     • 执行模块顶层代码（变量赋值、函数声明、执行副作用代码）。
     • 将 export 的值绑定到模块的命名空间对象上。

4. 兑现 Promise：
   一旦 module.js 模块本身及其所有依赖都成功解析并执行完成，最初由 import() 返回的那个 Promise 就会 resolve。resolve 的值就是该模块的命名空间对象（一个包含所有 export 内容的对象）。此时，你的 .then(module => { ... }) 或 await 后的代码才有权安全地使用这个模块。

5. 缓存：
   浏览器会缓存已成功加载、解析和执行的模块。如果后续其他地方的代码再次 import() 同一个模块（相同的URL），浏览器会直接返回缓存的命名空间对象，不会重复下载、解析和执行。

---

二、构建工具（如Webpack）如何转换和实现动态导入

浏览器原生支持动态导入很好，但为了兼容老浏览器、代码分割优化和开发体验，构建工具介入并进行了转换：

1. 识别import()：
   Webpack 的解析器（如 ParserPlugin）在遍历AST时识别 import() 语法，将其标记为一个代码分割点（Split Point）。

2. 代码分割（Code Splitting）：

   • Webpack 将被 import() 的模块 ./module.js 及其依赖（除非已被主入口或其他分割点包含） 打包进一个独立的代码块（Chunk） 文件中（如 1.bundle.js）。
   • 核心目标： 让这个模块的代码不出现在初始加载的主 bundle.js 中，减小首屏体积。

3. 转换import()语法：
   Webpack 不会保留原生的 import()。它把 import('./module.js') 转换成调用其运行时（Runtime） 的特定函数，主要是 __webpack_require__.e(chunkId)。转换后代码大致如下：

   // 转换前
   import('./module.js').then(module => module.doSomething());
   
   // 转换后（简化示意）
   __webpack_require__.e(/* chunkId: "module_js" */ "module_js")
     .then(() => {
       // __webpack_require__ 是Webpack加载模块的核心函数
       const module = __webpack_require__('./module.js');
       return module;
     })
     .then(module => module.doSomething());
   

4. __webpack_require__.e 的职责（运行时加载器）：
   这个函数是Webpack动态加载的核心引擎，其核心逻辑如下：

   • 检查缓存： 检查请求的 chunk 是否已加载过（Webpack 自己维护的缓存 installedChunks）。
   • 处理未加载： 如果未加载：
     • 创建Promise： 为该 chunk 创建一个新的Promise，并存储起来（以便后续相同请求复用）。
     • 发起加载： 动态创建 <script> 标签！ 将 src 指向打包好的 chunk 文件（如 1.bundle.js）。
     • JSONP机制： 加载的 chunk 文件本质是一个包裹在函数调用里的JS文件（Webpack的JSONP格式）。这个文件一旦执行，会调用Webpack全局对象（如 webpackJsonp）上的方法，将自身包含的模块“注册”到Webpack的模块系统中。
     • 处理成功/失败： 监听 <script> 标签的 onload/onerror 事件，决定是 resolve 还是 reject 之前创建的Promise。
   • 返回Promise： 返回这个（可能是新创建也可能是已存在缓存的）Promise。

5. chunk文件执行与模块注册：
   当 <script> 加载的 1.bundle.js 执行时，它内部调用类似 window["webpackJsonp"].push([[chunkId], {"./module.js": (function(...){ ... module code ... }) }]) 的代码。这做了两件事：

   • 将该 chunk 标记为已安装 (installedChunks[chunkId] = 0)。
   • 将 chunk 中包含的所有模块的定义（工厂函数）注册到 Webpack 的全局模块注册表 __webpack_modules__ 中。

6. __webpack_require__ 最终加载模块：
   一旦 __webpack_require__.e(chunkId) 返回的Promise resolve (意味着 chunk 文件加载完成且模块已注册)，后续的 __webpack_require__('./module.js') 就能像加载普通模块一样，从注册表中找到 ./module.js 对应的工厂函数，执行它（如果之前没执行过），并返回其导出的命名空间对象。此时才相当于原生动态导入中 Promise resolve 拿到模块对象。

---

三、动态导入的线程模型与浏览器协作

• 主线程（UI线程）：
  • 执行初始同步JS代码。
  • 遇到 import()，触发网络请求（通常由独立网络线程处理），创建并返回Promise，继续执行后续同步代码。
  • 执行微任务（Promise回调、MutationObserver等）。
  • 执行事件回调、渲染（Layout, Paint）、执行 requestAnimationFrame 回调等。
  • 当 import() 的模块及其依赖全部解析完成（注意：解析通常在非主线程或主线程空闲时进行，避免卡顿），模块的执行（Evaluation）必须在主线程进行（因为JS执行环境是单线程的）。这可能会引入一个微任务或任务。
  • 执行 import().then(...) 的回调（微任务）。
• 网络线程： 负责实际发送HTTP请求和接收响应数据。与主线程并行。
• 解析线程（可能）： 现代浏览器（如Chrome）尝试将JS解析（特别是词法/语法分析）放到单独的线程中进行（Off-Thread Parsing），避免阻塞主线程。但这最终需要将解析结果（如编译后的字节码）同步回主线程进行执行。
• 预加载扫描器（Preload Scanner）： 浏览器在解析主HTML文档时，有一个独立的扫描器（通常在主线程解析HTML的同时工作）会快速扫描文档，提前发现 <link rel="stylesheet">, <img>, <script> (包括后来动态添加的 import() 生成的 <script> 标签) 等资源，并提前发起请求。这对动态导入生成的 <script> 加载速度有积极影响。

工程师视角总结：

1. 原生import()是异步非阻塞的基石： 它通过立即返回Promise将网络I/O、依赖解析与主线程解耦。模块执行在主线程，但解析可以并行化。
2. 构建工具是“翻译”和“增强”： Webpack等工具将标准语法转换成兼容老浏览器和实现代码分割的底层机制（<script> + JSONP + Runtime）。核心思想仍是“按需加载独立代码块”。
3. 模块生命周期是关键： 深刻理解“加载”(Download) -> “解析”(Parse) -> “执行”(Evaluate) 的分阶段过程，以及依赖图的构建顺序。执行必须在主线程完成是潜在的性能瓶颈点。
4. 浏览器是多线程协作： 主线程、网络线程、（可能的）解析线程、预加载扫描器共同协作完成动态导入。利用好预加载扫描器对性能很重要。
5. 缓存无处不在： 浏览器缓存模块结果，Webpack Runtime缓存加载过的Chunk和模块实例。理解缓存层级避免重复加载。