🧐 为什么要做这么一套预加载方案呢？它存在的必要性在哪里？🧐
常规组件按需加载方案缺点
[ol]
组件渲染时加载组件资源
[/ol]
react.lazy(()=>import('xxxx/component'))
优点：拆分组件代码，按需加载, 减少首屏的资源加载，提升页面首屏速度。
[ol]
执行代码 import() 时加载组件资源
[/ol]
useEffect(() => {
import('xxxx/component').then((loadScript) => {
})
}, [])
优点：拆分组件代码,开发者可以更细粒度地控制组件按需加载的时机。
二者共有缺点：
代码拆分后，组件资源异步加载存在耗时，视觉上会渲染出 React.Suspense 的 fallback 以处理加载资源时的页面展示问题，当组件资源特别大或网络不稳定时都有可能会出现 loading 时间过长以致于影响用户体验。
如图：
由于资源加载存在近4s的耗时，组件渲染被延迟，这种情况下，便导致了我们虽然通过减少了首屏资源提升了首屏加载体验，但却让用户在后续使用过程中出现了体验断层，甚至是页面白屏的情况，这是用户不能接受的。
懒加载&预加载方案&流程介绍
预加载的目的让被懒加载的组件资源提前进行对应的资源请求，而不是渲染时请求, 本文为大家介绍的是基于 route-resource-preload 实现的一套加载时机高度自定义的资源预加载方案。
该方案基于 @route-resource-preload/webpack-plugin 及 @route-resource-preload/react, 分别对应构建时与运行时:
构建时流程图:
构建时 通过 dynamic API 及 webpack plugin 对模块进行拆包的同时，还会将preloadKey(开发者自定义的预加载标识)、import-module-url(import 模块路径)、module(output 产物)三者之间的关系以json形式进行保存，并允许应用端访问。
生成的 JSON 文件：
JSON：
开发者基于 JSON,可以判断出你想进行预加载的资源应该分类到哪个preloadKey下及preloadKey与module间的映射关系。
运行时流程图:
运行时 则是基于构建出的json,开发者通过设置Preloader/PreloadLink的preloadKey，对应的相关资源将被预加载，并基于 dynamic API 渲染组件。
项目效果演示
1. 真实用户场景打开 Modal （ Modal 基于 webpack module federation 引入）体验模拟
2. 离线场景体验模拟
为了对比效果（有/无预加载）更加直观，以下将采用离线网络的场景下进行展示。
预加载机制存在的必要性
通过以上的预加载机制，基于拆包不影响用户体验的前提下，便能够通过应用内 Any code can be split （一切代码都可以被拆包），让开发者没有了因为单页面资源过大影响应用性能的烦恼，SPA(单页面应用) 也可以拥有极致的首屏幕加载体验和交互体验，🐟与🐻掌兼得。
在线体验 DEMO 地址
效果数据对比
