网页里要展示一个几十上百MB的PDF，直接整包传给前端不仅能卡半天，还容易让浏览器内存直接爆掉。我自己上半年就接过一个PDF.js相关的按需分片加载需求，用PDFDataRangeTransport配合后端Range响应，把"300MB政策汇编在网页里秒开"这件事做成了。这篇文章会完整拆解前后端源码、开发流程和我在实测过程中踩过的坑，目标是让你拿到就能照着复现。
这篇内容不是简单给你贴一个getDocument的调用，而是带你理解PDF.js的传输层机制——为什么它能"看一页取一页"，背后依靠的HTTP协议能力、PDF文件结构，以及你自己实现传输层时需要格外小心的地方。如果你也遇到大PDF加载慢、白屏久、内存爆炸这类问题，或者你压根就是想搞懂PDF.js内部的分片逻辑，这篇都值得认真看完。
1. 大PDF在网页里"打不开"的真相：从一次真实故障说起
1.1 一个300MB的PDF，把浏览器整卡死了
当时接到的需求原话是："把公司这份政策汇编做成网页版，用户可以翻页浏览，不要下载整本。"我一开始也没多想，直接用PDF.js默认方式加载PDF，结果测试环境一跑，问题全来了。文件大概280MB，包含几千页扫描件加文字层，第一次打开白屏了将近一分钟，期间浏览器标签页一直转圈，CPU占用率飙到100%。等最终渲染出来，滚动到中间页时页面开始掉帧，切几页之后整个标签页直接无响应。
这个场景我估计不少人都遇过。很多人第一反应是"PDF.js不行"，其实冤枉它了。PDF.js默认的加载策略是流式读取，会把整个文件从头到尾通过Range请求一块块拉到本地，拉完解析完才会渲染页面。换句话说，它虽然不要求你把文件全下到内存里一次性渲染，但会把所有数据通过网络传输并缓存到本地，直到文件全部获取完毕才开始真正渲染。
对大文件来说，这种默认策略有两个致命问题。一是网络等待时间不可控，文件越大，首屏可交互时间越长；二是内存占用会随着文件大小线性上涨，宿主机的内存一旦不够，浏览器就开始崩溃。
1.2 为什么"先转图片"的方案也不好用
我一度考虑过后端转图片、前端只展示PNG的方案。把PDF每一页转成图片丢给前端，看着是"解决"了渲染压力，实际上引入了一堆新麻烦：文字层直接没了，用户没法搜索和复制；转图质量受DPI限制，放大就糊；高清图上页渲染会非常吃GPU和带宽；而且每页图片得单独生成和缓存，后端存储和任务调度的复杂度直接拉满。
所以我最终还是回到PDF.js，但需要搞清楚一个问题：能不能让PDF.js不下载完整文件，只加载当前用户正在看的页面？答案是可以，这就牵扯到PDF.js的按需分片加载机制，以及HTTP协议里的Range能力。
2. 按需分片的核心：Range请求与PDF.js的"懒加载"机制
2.1 PDF文件格式天然支持"按地址读取"
先说一个很多人不知道的点：PDF这种文件格式，天生就是为随机读取设计的。
PDF的内部结构大概分成几层：文件头、若干对象（页面对象、字体对象、图像对象等）、交叉引用表（xref，相当于整本PDF的目录索引），以及文件尾部的trailer。PDF.js在解析一份PDF时，并不是从头到尾把每个字节都读完，而是读取trailer拿到交叉引用表的起始偏移量，再从交叉引用表里查到每个对象在文件中的具体偏移位置，最后按需读取目标对象。
这个结构跟我们读纸质字典的思路很像。你要查一个字，先翻到目录页（xref），查到之后直接翻到对应的页码（文件偏移），而不是把整本字典从头翻到尾。理解了这一点，你就明白为什么PDF能做到"按需加载"——因为PDF.js知道目标页面对应的对象在文件里大概哪一段，只需要通过Range请求把那一段数据拿回来就行。
2.2 PDF.js如何用Range请求做到"看哪页取哪页"
PDF.js底层封装了一个NetworkManager，它会在加载PDF时先发出一个探测请求，检查服务器是否支持Range请求。如果响应头里有Accept-Ranges: bytes，并且返回了Content-Range，PDF.js就会切换到Range模式，后续按需发起Range: bytes=xxx-yyy的请求。如果服务器不支持Range，它只能退化成整包下载。
在这个过程中，有一个特别重要的类叫PDFDataRangeTransport。默认情况下你直接给getDocument传URL，它内部会自动帮你走这个流程。但如果你想完全掌控请求过程——比如加上身份认证、加上统计埋点、从自己的接口拿数据、或者加载的不是静态文件而是动态生成的PDF——就需要自己实现这个Transport，把"请求range数据"这件事接管过来。
我这一版方案里，正是自己实现了Transport，一方面是要在后端加权限校验，另一方面是为了方便后续接入阅读位置记录，所以没有走默认的URL自动探测，而是自己控制每一步。
2.3 disableAutoFetch和rangeChunkSize的正确理解
如果你只是想让PDF.js别一次性把数据全拉回来，最省事的方式是配置两个参数。
const loadingTask = pdfjsLib.getDocument({ url: '/files/big.pdf', disableAutoFetch: true, rangeChunkSize: 262144 });disableAutoFetch: true的意思是告诉PDF.js：非必要不要去预取数据，只有渲染当前页面需要的对象数据才去请求。这个参数在很多优化文章里都被说成"按需加载的关键"，它确实有用，但要注意它不等同于"完全不预取"。为了完成渲染，PDF.js还是可能拉取一些公共资源，比如字体、AcroForm、目录元数据等。所以别指望打开第一页时只发一个请求，实际会有几个小请求。
rangeChunkSize是每次Range请求的字节数。默认值在不同版本里略有不同，大体在64KB到2MB之间。这个值不是越大越好也不是越小越好。设置太小，比如32KB，会导致滚动翻页时请求频率爆炸，TCP连接都来不及建立；设置太大，比如10MB，又等于整包下载，失去了分片的意义。我实测下来，局域网内2MB很流畅，公网环境下1MB比较稳妥，弱网/移动网络场景建议256KB~512KB。
如果你决定自己实现Transport，这两个参数同样有效，因为getDocument加载流程是同一个，只是数据来源换成你自定义的传输层。
3. 前端核心改造：从getDocument到PDFDataRangeTransport
3.1 常规加载写法，以及它的边界
先把最基础的写法贴出来，大家对比一下后面的方案。
import * as pdfjsLib from 'pdfjs-dist'; import 'pdfjs-dist/web/pdf_viewer.css'; pdfjsLib.GlobalWorkerOptions.workerSrc = '/worker/pdf.worker.min.js'; async function loadPdfWithUrl(url) { const loadingTask = pdfjsLib.getDocument({ url: url, disableAutoFetch: true, rangeChunkSize: 1024 * 1024 }); const pdf = await loadingTask.promise; return pdf; }这种写法在多数中小文件上没有问题，PDF.js自动探测Range、自动分片。可一旦需求复杂起来，比如我需要知道当前加载了多少比例、需要带上鉴权token、需要在后端做访问审计，这种封装就兜不住。因为PDF.js内部发出的请求，你不好插一脚，它也不会带上你自定义的请求头。
3.2 自定义PDFDataRangeTransport的具体实现
所以我的做法是，绕开URL加载，直接传一个自定义Transport给getDocument。
import * as pdfjsLib from 'pdfjs-dist'; pdfjsLib.GlobalWorkerOptions.workerSrc = '/worker/pdf.worker.min.js'; export class RangeTransport extends pdfjsLib.PDFDataRangeTransport { constructor(totalLength, initialData, apiBase) { super(totalLength, initialData); this.apiBase = apiBase; this.loadedBytes = 0; this.totalBytes = totalLength; } requestDataRange(begin, end) { const controller = new AbortController(); const timeoutId = setTimeout(() => controller.abort(), 30000); fetch(`${this.apiBase}/api/pdf/range?fileId=xxx&begin=${begin}&end=${end}`, { credentials: 'include', signal: controller.signal }) .then(response => { if (!response.ok) throw new Error('Range request failed'); return response.arrayBuffer(); }) .then(buffer => { clearTimeout(timeoutId); this.loadedBytes += buffer.byteLength; // 关键：必须调用这两个回调，PDF.js渲染流程依赖它们 this.onDataProgress(begin, new Uint8Array(buffer)); }) .catch(err => { clearTimeout(timeoutId); if (this.onDataError) { this.onDataError(begin, err); } }); } } async function loadPdfWithTransport(apiBase) { // 第一步：先向后端元数据接口拿文件总大小 const metaRes = await fetch(`${apiBase}/api/pdf/meta?fileId=xxx`, { credentials: 'include' }); const meta = await metaRes.json(); const transport = new RangeTransport(meta.size, null, apiBase); const loadingTask = pdfjsLib.getDocument({ data: transport, disableAutoFetch: true, rangeChunkSize: 1024 * 1024 }); return loadingTask.promise; }这里有几个关键点需要注意。
requestDataRange(begin, end)是传输层的核心接口，PDF.js在内部需要某段数据时会回调这个方法，参数就是文件中的绝对字节偏移。你在这个方法里要做的就一件事：从服务端拿到对应字节段，然后调this.onDataProgress(begin, new Uint8Array(buffer))把数据交给PDF.js。一定要以Uint8Array传给回调，这个类型如果传错，后面解析会直接报奇怪的类型错误。
this.onDataError(begin, err)是错误回调，强烈建议实现。PDF.js渲染遇到数据请求失败时，会走这个回调，你可以在这里做错误上报，也可以触发UI上的重试按钮。如果不传，PDF.js可能卡在一个"真空等待"的状态，页面表现就是白屏卡住，非常难排查。
我用AbortController给请求加了30秒超时，这是从生产环境学到的一个硬经验。弱网环境下，大量的Range请求很容易有一个卡住不返回，如果不超时，整个PDF.js的加载流程会被这个"吊死"的请求阻塞，页面就一直白屏。加上超时后，至少能触发错误回调，给用户一个"重新加载"的反馈路径。
3.3 监控加载进度和渲染状态的技巧
自定义Transport之后，你还可以拿到一个非常有用的信息：已加载字节数。
上面代码里我维护了this.loadedBytes，每次收到数据就累加。你可以把它做成一个进度提示：
transport.onProgress = (loaded, total) => { // 这里是PDF.js的回调，注意和自己维护的loadedBytes区分 updateProgressBar(loaded, total); };PDFDataRangeTransport自带一个onProgress回调，PDF.js内部会周期性调用，参数是已加载字节数和总字节数。不过我实测发现它更新的频率不太稳定，而且必须等底层有数据流转才会触发。所以我在自定义Transport里自己记录loadedBytes，配合一个定时器，实现更流畅的进度动画。
前端渲染环节用pdfjsLib的PDFViewer和EventBus来承载页面展示，这样能省去自己维护canvas渲染的琐碎逻辑。
const appContainer = document.getElementById('viewer'); const eventBus = new pdfjsLib.EventBus(); const viewer = new pdfjsLib.PDFViewer({ container: appContainer, eventBus, removePageBorders: true }); eventBus.on('pagesinit', () => { viewer.currentPageNumber = 1; }); eventBus.on('pagechanging', (e) => { const currentPage = e.pageNumber; console.log('现在看到第', currentPage, '页'); // 这里可以触发阅读位置保存，后面单独说 });这样搭建出来的前端，用户翻页时PDF.js会自动调用Transport请求尚未加载的数据段。也就实现了真正意义上的"看哪页取哪页"。
4. 后端支撑：给PDF文件接口加上Range响应能力
4.1 用Node.js/Express实现Range请求接口
自定义Transport之后，后端接口就需要自己写了。核心是正确处理HTTP的Range头。
我用的是Node.js + Express，实现一个支持Range的PDF接口。这里有一点要说明：Express默认的res.sendFile和express.static其实已经内置了Range支持，如果你只是想把一个磁盘上的静态PDF文件给前端，直接用这两个就够了，不需要手工解析Range。我之所以还自己解析Range，是因为生产环境里PDF路径来自数据库配置，而且还要在这个接口里做权限校验、访问审计和某些动态处理，直接托管静态文件的方式不够灵活。
const express = require('express'); const fs = require('fs'); const path = require('path'); const router = express.Router(); // 元数据接口：让前端知道文件大小 router.get('/api/pdf/meta', async (req, res) => { const filePath = path.resolve(__dirname, '../files/big.pdf'); const stat = await fs.promises.stat(filePath); res.json({ size: stat.size, fileName: 'big.pdf', contentType: 'application/pdf' }); }); // 核心的Range接口 router.get('/api/pdf/range', async (req, res) => { const filePath = path.resolve(__dirname, '../files/big.pdf'); const begin = parseInt(req.query.begin, 10); const end = parseInt(req.query.end, 10); if (isNaN(begin) || isNaN(end) || begin < 0 || end < begin) { return res.status(400).json({ error: 'invalid range' }); } const stat = await fs.promises.stat(filePath); if (begin >= stat.size) { return res.status(416).json({ error: 'range not satisfiable' }); } // 关键：接收到的end可能超过文件大小，做一下收敛 const safeEnd = Math.min(end, stat.size - 1); const chunkSize = safeEnd - begin + 1; res.writeHead(206, { 'Content-Type': 'application/pdf', 'Content-Length': chunkSize, 'Content-Range': `bytes ${begin}-${safeEnd}/${stat.size}`, 'Accept-Ranges': 'bytes' }); const stream = fs.createReadStream(filePath, { start: begin, end: safeEnd }); stream.pipe(res); }); module.exports = router;有几个细节特别重要。Content-Range头必须写对格式：bytes 起始-结束/总长度，这是HTTP协议规定的，PDF.js和浏览器都靠这个头判断返回的数据是不是预期的。Accept-Ranges: bytes是给PDF.js探测用的，这个头缺失的话，PDF.js会认为服务器不支持Range，退化成整包下载。状态码必须是206 Partial Content，如果你返回200，PDF.js也可能根据Content-Range头去拼接数据，但浏览器层面的行为就容易出问题，实测中最好严格保持206。
4.2 解决跨域和预检请求
实际部署时前端和服务端大概率不在同一个域名下，跨域问题必须处理好。
router.use((req, res, next) => { res.setHeader('Access-Control-Allow-Origin', 'https://your-frontend-domain.com'); res.setHeader('Access-Control-Allow-Methods', 'GET, HEAD, OPTIONS'); res.setHeader('Access-Control-Allow-Headers', 'Range, Content-Type, Authorization'); res.setHeader('Access-Control-Expose-Headers', 'Content-Range, Accept-Ranges, Content-Length'); res.setHeader('Access-Control-Allow-Credentials', 'true'); if (req.method === 'OPTIONS') { return res.sendStatus(200); } next(); });这里最容易被忽略的是Access-Control-Expose-Headers。如果你只设置了Access-Control-Allow-Origin，前端JavaScript是读不到Content-Range和Accept-Ranges这些响应头的，因为浏览器默认只暴露一小部分安全响应头，其他自定义头必须通过Expose-Headers显式暴露。PDF.js内部要检查Content-Range来判断服务器是否支持Range，如果这个头被浏览器屏蔽了，PDF.js一样会认为服务端不支持Range，然后走整包下载路径。这个坑我一开始也踩过，排查了半天，后来用curl模拟请求发现响应头都在，但网页里就是整包下载，最后才定位到是跨域暴露头的锅。
4.3 不是所有服务器都支持Range，如何检测与降级
如果你的PDF文件部署在第三方对象存储或者某些CDN后面，事情就没那么可控了。不是所有存储服务都支持Range请求，尤其是那些做了额外转发层、或者对Range头处理不规范的网关。
检测方法很简单，用curl手动发一个Range请求看看响应：
curl -I -H "Range: bytes=0-1023" https://your-cdn.example.com/big.pdf如果响应头里有Accept-Ranges: bytes和Content-Range: bytes 0-1023/xxxxxxxx，说明这条路是通的。如果返回200且没有Content-Range，基本可以判定不支持Range。
遇到不支持的存储后端，我的做法是套一层自己的Node服务做代理。Node服务从底层存储读文件流，自己拼HTTP头的Range逻辑，也就是上一节写的那套代码。这样PDF.js面对的还是自家后端接口，可以实现Range，底层存储是什么就不重要了。代价是中国服务器带宽和存储读IO，但这个取舍在很多场景下是值得的。
另外，如果你的PDF文件体积实在太大，比如超过2GB，还要考虑到文件系统单文件大小限制、Node.js对大文件读取时流式处理的稳定性等，这时建议直接用Nginx的X-Accel-Redirect或者云厂商的对象存储Range能力，不要把读取压力都压在Node进程里。
5. 实测验证与排查：这样确认分片真的生效了
5.1 DevTools里看206还要看什么
写完了前后端，不是能打开页面就完事了，你得验证分片加载是不是真的在按需工作。
打开Chrome DevTools的Network面板，过滤请求类型为Fetch/XHR。加载一个几百MB的大PDF，如果方案生效，你会看到一串请求，状态码大多是206，每条请求的Headers里都带Range: bytes=xxx-yyy，Response Headers里带Content-Range: bytes 0-65535/300000000这种类似的响应。
更进一步的验证方法是：观察滚动页面时请求的变化。打开PDF之后先停在第一页，记录下Network里已有的请求数量，然后直接跳转到第200页。如果此时新增了一批Range请求，并且这些请求的偏移量范围跟第200页的内容区域大致对应，说明按需分片确实在起作用。如果跳转页面时请求数没有任何变化，那说明页面数据早就被预取完了，你得回头检查是不是disableAutoFetch没生效，或者文件太小没触发分片逻辑。
5.2 识别"分片了但没分片"的假象
有一种情况特别迷惑人。打开Network面板看到满屏的Range请求，你觉得分片策略工作正常，但实际上PDF.js还在暗地里把整个文件都拉回来了。
具体表现是：虽然请求是分段的，但请求数量非常多，而且请求区间从头到尾全覆盖，一个不落。这种情况通常出在rangeChunkSize设置太小，或者disableAutoFetch没有设为true。PDF.js内部在disableAutoFetch为false时，会让NetworkManager持续向后请求，直到把文件剩余部分全部拉完。你看到的Range请求虽然也是分片的，但本质上是流式全量下载，只是把下载动作拆碎了。要验证是否全量下载，可以直接看浏览器底部状态栏——在自定义Transport方案下，如果你自己维护了loadedBytes，可以把它和总文件大小对比。我最初测试时就是用的这个方法，发现一加载完第一页，loadedBytes就以非常快的速度逼近总大小，这才意识到disableAutoFetch没有配置上。
5.3 常见坑：CDN缓存、代理服务器和移动网络
分片加载在局域网内测得很顺畅，不代表上线到生产环境后就一定没问题。我实际部署中遇到过几个坑。
一个是CDN缓存。有些CDN节点对带Range头的请求处理不标准，如果CDN缓存了某个Range响应，用户后续请求同一范围的字节时，可能返回的是一个固定缓存块，而不是根据当前文件状态计算的正确范围。表现就是前端渲染缺页、缺图片、或者页面数据错乱。解决办法是在CDN控制台关闭对该PDF路径的缓存，或者配置CDN透传Range头。
另一个是公司内网的Web代理。某些代理服务器会把Range头剥掉，或者把206响应缓存成200，导致PDF.js走不了分片。这个问题排查起来很痛苦，因为你本地直连正常，但走代理就废。我当时是通过对比"代理模式"和"直连模式"下的Network请求头差异才定位的。
移动网络下还有一个典型的弱网问题：TCP连接频繁断开，Range请求一直超时重试。这时需要结合前面说的AbortController超时机制，并且在前端给用户体验一个"加载稍慢"的过渡提示。如果文件实在太大且用户网络太差，建议退化成纯下载按钮，别死磕在线预览。
6. 加分项：把"阅读到第几页"记录下来
说到网络热词里那句"pdf.js如何把阅读到哪一页记录到数据库里"，这个需求几乎每个阅读类项目都会有。在我们这套分片加载框架下，实现起来很简单，只需要利用PDFViewer的pagechanging事件。
6.1 前端采集阅读位置
const SAVE_DELAY = 1500; let saveTimer = null; eventBus.on('pagechanging', (e) => { const currentPage = e.pageNumber; // 防抖，避免用户快速翻页时疯狂打接口 clearTimeout(saveTimer); saveTimer = setTimeout(() => { saveReadingPosition(currentPage); }, SAVE_DELAY); }); function saveReadingPosition(page) { fetch('/api/position', { method: 'POST', headers: { 'Content-Type': 'application/json' }, credentials: 'include', body: JSON.stringify({ fileId: 'xxx', page: page, timestamp: Date.now() }) }); }防抖这里我用了1.5秒的延迟。用户翻页是一个高频操作，如果每换一页都立即写库，QPS会很难看，也没有必要。1.5秒足够平滑掉连续翻页的情况，用户停留超过1.5秒才记录一次。
还有一个细节是：pagechanging事件在滚动页面时会频繁触发，但它本质上只是"当前可见页编号"的变化，不代表用户一定阅读了那一页。如果要做更精准的阅读记录，可以结合页面可见时间，比如连续停留超过5秒才落库。但对大多数场景，pagechanging已经够用了。
6.2 后端存储与恢复接口
后端我用一个简单的positions表来存阅读位置，这里假设是MongoDB，但换成MySQL也一样。
router.post('/api/position', async (req, res) => { const { fileId, page } = req.body; const userId = req.user?.id || 'anonymous'; await db.collection('positions').updateOne( { fileId, userId }, { $set: { page, updatedAt: new Date() } }, { upsert: true } ); res.json({ ok: true }); }); router.get('/api/position/:fileId', async (req, res) => { const userId = req.user?.id || 'anonymous'; const record = await db.collection('positions').findOne({ fileId: req.params.fileId, userId }); res.json(record ? { page: record.page } : { page: 1 }); });前端恢复位置时要注意一个点：PDF文档刚加载完成时就直接设currentPageNumber，不一定能直接渲染出那一页，因为可能正处于分片加载的早期阶段，那一页的数据还没取回来。我的处理方法是，在pagesinit事件后再跳转。
eventBus.on('pagesinit', async () => { const res = await fetch(`/api/position/xxx`, { credentials: 'include' }); const data = await res.json(); const savedPage = data.page || 1; viewer.currentPageNumber = savedPage; });如果跳转后目标页的数据还没有加载完，PDFViewer会先显示一个空白占位，等Transport层把数据拉回来再渲染。这个过程用户基本无感知，因为Range请求很快，但如果网络不好，最好配合一个loading遮罩，避免用户以为页面卡死了。
6.3 分片加载模式下的独特注意点
保存并把恢复搞得比较优雅之后，有一个分片加载特有的坑值得单独拎出来说：跳页时目标页数据还没拉取，而此时正处于Transport的加载队列里，如果你又快速跳回第一页，可能会打乱PDF.js内部的请求调度。
我遇到过的情况是：用户上次读到第180页，打开PDF后自动跳转到180页，然后用户马上点"回到首页"，结果首页渲染了好几分钟。排查后定位原因：跳转到180页时，Transport开始了一系列大范围Range请求，回首页时，PDF.js还在等待之前的请求返回，新页面的渲染被排队队列卡住了。
解决办法是，在自定义Transport里做一个小小的高级处理——记录当前正在进行的请求，并为其维护一个优先级标记。当用户切换到某页时，立刻发起该页面对应偏移范围的请求，并把它插入到待处理列表的前面。不过，PDFDataRangeTransport的底层回调机制没有暴露"优先级"这层概念，实际工程里更难控制的是onDataProgress的调用顺序。简单粗暴的做法是：用户在跳转后，如果遇到了长时间空白，触发一次viewer.currentPageNumber的重新赋值，用重渲染「顶」一下队列。虽然不完美，但实测能缓解大部分场景。
7. 项目源码结构和扩展思路
7.1 前后端源码目录一览
整套项目的源码结构如下，你可以根据自己的需要做减法。
pdf-sharding-demo/ ├── frontend/ │ ├── index.html │ ├── main.js │ ├── range-transport.js │ ├── viewer.js │ └── worker/ │ └── pdf.worker.min.js ├── server/ │ ├── app.js │ ├── routes/ │ │ ├── pdf.js │ │ └── position.js │ └── files/ │ └── big.pdf └── README.mdfrontend/range-transport.js是前端最核心的文件，里面实现了RangeTransport类。frontend/main.js负责任务装配，包括初始化PDFViewer、绑定事件、加载Transport、监听进度。server/app.js负责启动Express服务、开启跨域配置、挂载路由。server/routes/pdf.js实现了上面说的元数据接口和Range接口。
这个结构特别适合拿来做二次开发。你主项目如果是Vue或React，可以直接把RangeTransport抽成一个工具类，放在公共模块里，然后在业务组件里调用。PDFViewer这个UI组件如果要深度集成，建议看看PDF.js官方自带的web/viewer.html，它是个完整可上手的阅读器外壳，把它的viewer.html拷贝到你的工程里，替换其中的加载逻辑，就能得到一个功能完整的网页PDF阅读器。
7.2 可以继续扩展的方向
这个项目跑通之后，我后续还做了一些扩展，觉得挺有价值的，列出来供你参考。
第一个是给Range请求加鉴权token。由于是我们自己实现的Transport，在requestDataRange里可以轻松给每个fetch请求的headers里塞上Authorization字段。静态文件托管的普通方案做不了这个，因为它没法对"文件内部某一段数据"做权限控制。
第二个是把Range请求的响应缓存到Redis里。同一段字节如果被多个用户请求，直接从Redis读可以节省大量的磁盘IO。不过要注意缓存过期策略，因为PDF文件一旦被覆盖，所有Range缓存都必须失效。我当时的做法是给PDF加一个内容哈希，文件名携带哈希值，文件更新后URL变化，CDN和Redis缓存自然失效。
第三个是把阅读位置解析成"阅读深度"。前端除了记录页码，还可以配合Transport的进度数据，判断当前页面数据的加载百分比。用户打开到第300页，但这一页只有30%的数据被加载了，说明用户可能只浏览了局部。这种数据可以为运营团队提供非常有价值的报告。
第四个是给超大PDF做"按章加载"。如果文件是几千页的报告，可以先让后端解析目录结构，前端只加载目录信息和当前章节对应的对象范围，用户点击某一章，再按需加载该章页面。这种方案比纯按页分片加载的体验好很多，特别适合电子书场景。实现思路也不复杂，后端在PDF解析时提取出书签大纲，把章节目录和页区间映射起来，前端跳页时按章节范围设置Transport的请求范围即可。
我自己的体会是，按需分片加载这套方案并不是什么黑魔法，核心就是对HTTP Range的合理利用，加上对自己数据通道的控制。只要把PDF的结构理解清楚，把Transport的回调关系理顺，后续的扩展就是水到渠成的事。希望这篇能帮你少走几步弯路。