前端资源不同打包方式的取舍
阶段一：
在早期项目中，整个项目就是一个HTML文件+一个CSS文件+一个js文件
缺点：
- 整个项目在同一个资源文件中，文件会比较大，初次加载很慢，同时不利于资源的缓存，每次有点改动文件就改变了
- 一些不使用的功能在初次加载时就加载了，首屏加载慢
- 错误排查困难
阶段二：
业务与基础框架打包进行分离，类似react、antd等包单独打包成一个文件，可以长时间缓存，业务逻辑打包成一个文件
优点：
- 部分不经常改变的资源可以进行长时间缓存
缺点：
- 业务逻辑部分代码体积还是比较大，初次加载时有很大的浪费
- 错误排查时不好定位
阶段三：
react、antd等部分内容打包成一个固定资源，业务逻辑按照路由进行分割，没个业务部分大包成一个资源文件，在页面上使用时才加载对应资源文件
优点：
- 不经常改变的资源可以长时间缓存
- 错误排查时好定位问题
- 初次加载时可以只加载强依赖资源文件(react) 和首页资源文件，首屏加载快
- 大部分情况下，发布时只用发布业务逻辑修改的部分，当遇到类似react版本升级等问题时，还是需要全量发布
缺点：
- 每次打开一个新页面时，才会拉取对应的资源，可能会有一段白屏时间。不过这个问题可以通过预加载来解决
- 资源请求数变多。在某些情况下，由于同源下最多发起6个请求，可能会存在占用资源加载的问题
对于PC应用：
实现固定资源(react等)生成资源文件强缓存，业务逻辑按照路由分割来生成不同的资源文件
- 发布阶段只需要发布修改的资源文件
- 对于PC应用，短暂的资源加载时间可以接受
对于H5应用：
强依赖资源react等打包一个资源文件并设置强缓存，首页必须资源打包为一个文件，其它资源按照路由打包，并进行预加载
对于在app等应用内打开的h5，可以在端平台预加载，达到秒开的目的。不过，这种情况下需要注意资源缓存的问题，避免发布后资源未生效
大部分场景下，项目基础依赖强缓存 + 路由级别代码分割 就是比较好的打包方式
