核心目标是提升浏览器并行下载能力与缓存复用率；需区分Bundle Splitting（服务缓存）和Code Splitting（优化加载时机），通过splitChunks全场景提取、cacheGroups分层打包、contenthash命名、合理minSize/请求限制及preload/prefetch调度实现。
合理拆分 Webpack 代码块，核心目标不是单纯“变小”，而是让浏览器能并行下载多个有意义的资源，同时提升缓存复用率。关键在于区分两种拆分逻辑：一种为缓存服务（Bundle Splitting），一种为加载时机服务（Code Splitting）。前者对常访问用户收益更大，后者直接影响首屏速度。
按缓存稳定性分层打包
浏览器缓存依赖文件内容哈希变化。如果所有代码混在一个 bundle 里，改一行业务逻辑，整个文件 hash 就变，用户得重新下载全部——包括 React、Lodash 这些几乎不变的依赖。
- 用 splitChunks.chunks: 'all' 启用全场景提取，Webpack 会自动识别 node_modules 中被多次引用的模块（如 axios、moment）并打成独立 vendor chunk
- 显式配置 cacheGroups，把第三方库和内部公共工具库分开：
cacheGroups: { vendor: { test: /[\/]node_modules[\/]/, name: 'vendors', chunks: 'all', priority: 10 }, utils: { name: 'utils', test: /[\/]src[\/](utils|helpers)[\/]/, chunks: 'all', priority: 5 } } - 输出文件名必须用 [contenthash]（生产环境），确保内容不变时 hash 不变，浏览器可直接复用缓存
控制 chunk 数量与大小平衡
太多小文件会触发 HTTP 请求瓶颈，尤其在 HTTP/1.1 环境下；太少大文件又牺牲缓存粒度。需设定合理阈值：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- minSize: 20000（20KB）是较稳妥起点：小于该值的模块不单独成 chunk，避免碎片化
- maxInitialRequests: 6 和 maxAsyncRequests: 8 限制首页或异步加载时最大并行请求数，适配主流设备网络能力
- 通过 webpack-bundle-analyzer 定期检查产物，识别意外膨胀的 chunk（比如某个页面误引了整套 UI 组件库）
利用 preload/prefetch 提前调度资源
拆分后资源虽小，但若等用户点击才发起请求，仍会有明显延迟。可用 Webpack 内置指令主动提示浏览器：
立即学习“Java免费学习笔记（深入）”；
- 在路由组件中写
import(/* webpackPreload: true */ './ChartModule')：当前页面渲染完成空闲时，浏览器就提前拉取 ChartModule，用户点进去几乎无等待 - 对确定下一步会进的页面（如登录后大概率进 dashboard），用
/* webpackPrefetch: true */，它优先级更低，不影响当前页面加载 - 注意：preload 仅适用于当前导航上下文内大概率立即用到的资源，滥用会抢占带宽
保留入口分包作为兜底控制
SplitChunks 是智能的，但不是万能的。某些强隔离场景仍需手动干预：
- 多页应用（MPA）中，每个 HTML 页面对应一个入口，如
entry: { home: './src/home/index.js', admin: './src/admin/index.js' }，天然分离执行上下文 - 微前端子应用或独立功能区（如客服弹窗 SDK），可单独配 entry + library 输出，避免与主应用耦合
- 手动分包配合 runtimeChunk: 'single'，把 webpack 运行时逻辑抽成 runtime.js，避免修改业务代码导致 vendor hash 变更
