资源分片加载是动态获取、按需渲染的逻辑分片，依赖http range请求与前后端协同：pdf靠pdf.js+range按页加载；前端代码通过webpack splitchunks拆chunk；小程序/h5按功能物理分包；大数据可视化依视图或维度裁剪懒加载。
资源分片加载不是简单地把大文件“切开存成多个小文件”，而是让浏览器按需请求并组装数据，核心在于“动态获取、按需渲染”，不依赖物理拆分。真正起作用的是前后端协同支持 HTTP Range 请求，配合前端加载策略，实现逻辑上的分片——用户看到的是完整文档或应用，系统背后只传输当前需要的那一段。
一、PDF 类文档：靠 Range 请求 + PDF.js 实现按页/按范围加载
这是最典型的分片加载场景。前端不下载整个 PDF，而是向服务端发起带 Range: bytes=xxx-yyy 头的请求，服务端返回对应字节区间的数据，PDF.js 用它解码并渲染指定页面。
- 后端必须支持 HTTP 范围请求（如 Nginx 默认开启；Node.js 需手动处理
Range头并返回206 Partial Content） - 前端初始化 PDF.js 时，需传入
rangeChunkSize和启用disableStream等参数，确保启用分片能力 - 实际效果是：打开第1页几乎秒出，翻到第100页时才拉取那一页所在的数据块，内存占用稳定在几 MB 级别
二、前端代码包：用 Webpack splitChunks 拆出逻辑独立的 chunk
这不是切割源文件，而是构建时分析模块依赖，把重复或非首屏代码抽成单独 JS 文件，运行时按需加载。
- 配置
optimization.splitChunks，重点调优chunks: 'all'、minSize（如 10KB）、cacheGroups（比如把node_modules中的lodash单独拎成vendor.js） - 对路由级模块使用
import()动态导入，Webpack 自动为每个import('./page/Report')生成一个异步 chunk - 打包后会产出
main.js（主逻辑）、vendor.js（第三方库）、report.abc123.js（报表页）等多个小文件，由浏览器并行下载
三、小程序或 H5 应用：按功能域划分物理分包
这类分片是真正的“目录级拆分”，开发者手动把代码组织成多个子包，平台负责加载调度。
- 小程序中，在
app.json里声明subPackages，例如{"root": "packageA", "pages": ["pages/list/index"]} - 主包只含首页、登录页等核心内容（≤2MB），其他功能包（如“订单中心”“客服系统”）独立存放、独立上传
- 用户点击跳转时，框架自动下载对应分包并注入，首次进入该分包页面才触发加载，不预占带宽和内存
四、大数据可视化：按空间或维度做逻辑分片
面对几十万条地理坐标或时间序列数据，不能全量传给前端。分片在这里体现为“数据裁剪+懒加载”。
- 地图类应用：根据当前视图范围（经纬度+缩放级别），后端只返回该区域内的点位数据，移动/缩放时再请求新范围
- 表格类场景：采用虚拟滚动 + 分页接口，前端只维护可视区 20 行 DOM，滚动时通过
offset/limit或游标（cursor）拉取下一批 - 图表聚合类：原始数据保留在服务端，前端只请求预计算好的聚合结果（如“近7天日活折线图”），避免传输百万级明细
