PDF 二维码完全指南：托管、尺寸和避坑要点（2026 年版）
QR Cake Team发布于:
关于 PDF 二维码的实用指南——什么时候用 PDF、什么时候改用 HTML、文件该托管在哪里，以及怎样让扫码后真正秒开。
PDF 二维码只做一件事——让用户扫一下码就能立即打开一份 PDF。用对了场景，它非常适合产品手册、白皮书、引流资料、必须以 PDF 形式存在的餐厅菜单，以及任何想要按需投递详细文档的印刷营销材料。
用错了场景，它会带来网上最糟糕的二维码体验之一——加载缓慢、链接失效、手机处理不了直接强制下载，或者 PDF 在手机上根本读不了。
这篇指南会告诉你：什么时候选 PDF、什么时候改用 HTML，文件该怎么托管才能真正加载得动，哪些设计细节决定体验好坏，以及哪些场景下 PDF 确实比网页更合适。
以下情况适合用 PDF 二维码：
以下情况建议改用网页：
拿不定主意时，就用 HTML。大多数 PDF 二维码的使用场景，其实换成一个移动端优化过的网页效果会更好。
PDF 当初是为了固定版式打印而设计的。它给出了一个硬性承诺：这份文档在每一台设备、每一个浏览器、每一种操作系统上看起来都一模一样。1993 年，每个文字处理软件显示文档都不一样，这一点在当时是革命性的。
但同样是这个特点，让 PDF 在手机上表现得不太理想：
这并不是说不能用 PDF 二维码，而是说只有在 PDF 格式确实合适的时候才用。
下面这些场景，PDF 比 HTML 更合适：
产品手册和安装说明。用户想保留这种文档，会打印出来，几年后还会回头查。PDF 能保住版式（对示意图和零件清单来说往往很关键），下载后还能离线使用。
法律文件和合同。固定版式、签名真实性、正式感——这些预期 PDF 都能满足，网页则不行。
认证和资质证书。结业证书、专业资质、培训记录。持证人往往要打印出来或附在申请材料里。
对印刷设计有要求的餐厅菜单。高端餐厅的纸质菜单常常用了定制字体和精细排版，数字版希望完全一致。HTML 可以做得相似，但很少能做到一模一样。
引流资料和白皮书。当你用一份可下载的文档换用户的邮箱地址时，PDF 格式会强化“这是一份真文档，不只是篇博客”的感知。
税务文件、财务报表、技术规格书。任何在法律或技术层面对固定格式有要求的场合。
多页指南和电子书。任何超过 5–6 页、读者可能想保存下来的内容。
这些场景，PDF 确实是合适的工具。除此之外，HTML 页面几乎都是更好的选择。
决定用 PDF 之后，这是最重要的一个选择。托管地点决定了体验是快还是慢、是稳还是脆弱、是专业还是寒酸。
最佳选择：自己的域名。
把 PDF 放在你自己的服务器或 CDN 上。链接长这样：yourbusiness.com/downloads/manual-2026.pdf。带品牌、速度快、完全由你掌控。没有第三方依赖、不会被企业防火墙拦截、没有广告或插页。
对于真正认真对待 PDF 二维码的企业，这才是正确答案。
可以接受的选择：Amazon S3 或 Cloudflare R2 这样的 CDN。
实际效果和自己域名托管差不多，只是把带宽压力交给 CDN。默认链接可能是没有品牌的 CDN 地址，但几乎都可以映射到一个像 files.yourbusiness.com 这样的子域名。
有风险的选择：Google Drive、Dropbox、OneDrive。
PDF 放在你的云盘账户里，权限设为“任何拥有链接的人都可查看”。链接难看，更糟的是还有这几个问题：
个人使用或一次性文档可以接受。印在包装、名片或长期营销物料上的二维码，不适合。
折中的选择：二维码服务商自带的 PDF 托管功能。
有些二维码生成器会帮你托管 PDF，并从他们的域名提供访问。从历史上看这是个坏主意——一旦服务商托管出问题或你取消了订阅，所有印好的二维码就停止工作。对大多数付费服务商来说，至今仍是如此。
例外的是少数服务商（QR Cake 就是其中之一），既提供可靠的 PDF 托管，又承诺即便你取消订阅二维码也能继续跳转。对于没有自己的域名或 CDN 的非技术用户——比如餐厅老板、地产中介、小诊所——这种工作流就真的可行：上传一次 PDF，一分钟左右拿到一个动态二维码，以后想换 PDF 也不用重新印刷。如果你有自己的域名和工程能力来管理它，自托管仍然是最稳妥的选择。如果没有，找一个对长期可用性友好的服务商托管也是合理的退路——只是在把它印上去之前，请先确认服务商的取消政策。
PDF 二维码只有 PDF 真能加载出来才算有用。在 4G 网络下，500 KB 的 PDF 和 5 MB 的 PDF 之间的差距，就是 2 秒和 20 秒的差距。大多数用户在 5–8 秒之间就会放弃。
解决方法：
不会破坏质量的压缩工具：Adobe Acrobat（另存为“已优化”版本）、ILovePDF、SmallPDF，技术用户也可以用 Ghostscript 这类命令行工具。
压缩之后，请在手机上实地测试一下文件大小。在光纤宽带上算“很小”的 PDF，到了偏远地区用移动数据访问，仍然可能慢得让人抓狂。
默认情况下，浏览器可能把 PDF 内联显示，也可能强制下载。具体行为取决于服务器的 HTTP 头、浏览器和操作系统。
内联显示几乎总是更好的体验——用户扫码后 PDF 直接显示出来，不用离开浏览器就能滚动阅读。强制下载则会增加摩擦：用户得跑到“下载”文件夹里去找文件、打开、再回到原来的操作上。
要控制这件事，把二维码所指 PDF 的服务器 Content-Disposition 头设为 inline。如果用的是 CDN 或自己的服务器，这一项是可以配置的。如果用的是 Google Drive 或 Dropbox，那就改不了——它们会强制使用自己的查看器。
“我的 PDF 二维码在手机上感觉不太对劲”这种常见抱怨的真实解决方法是：把 PDF 放在自己的域名下，并把 Content-Disposition 设为 inline。这一项改动就能解决绝大多数投诉。
静态 PDF 二维码把 PDF 的 URL 直接编码进二维码图案里。URL 永久不变。优点：不依赖任何服务商。缺点：一旦 PDF 移动位置或换了 URL，二维码就废了。
动态 PDF 二维码编码的是一个指向服务商服务器的短跳转链接，再由服务器跳转到实际的 PDF 地址。优点：目标可改、有数据分析、可以替换 PDF 而不动二维码。缺点：依赖服务商基础设施持续运行。
对于会随时间变化的 PDF——年报、更新版手册、有版本号的文档——动态二维码是必选项。你可以年年替换目标 PDF，而印好的二维码完全不用动。
对于永远不会变的 PDF——一次性活动邀请、定格的历史文档——只要你能永久控制目标 URL，静态二维码是可以接受的。
动态二维码下的 PDF 更新流程：
即便托管和大小都处理好了，很多 PDF 在手机上仍然没法读，因为它们当初是按纸张设计的。
手机友好的 PDF 设计原则：
如果你从头掌控 PDF 设计，也可以考虑做两版：一版面向打印优化，一版面向屏幕优化。二维码指向屏幕版，印刷用印刷版。
错误 1：商用场景下把 PDF 放在 Google Drive / Dropbox。不稳、手机上慢，企业防火墙还会拦。请用自己的域名。
错误 2：忘了压缩 PDF。动辄好几 MB 的文件在移动数据网络下加载会非常痛苦。
错误 3：经常更新的文档却用了静态二维码。每次年度更新都意味着所有印刷品要重做。会更新的内容请用动态二维码。
错误 4：照纸张设计的 A4 或 Letter 版 PDF，被人在手机上扫了。不放大不平移就读不了。要么重新按手机设计，要么承认这个限制，干脆改用 HTML。
错误 5：强制下载而不是内联显示。多了一道摩擦。请配置服务器的 Content-Disposition 头。
错误 6：没给打不开 PDF 的用户准备备选方案。少数用户（老款手机、某些辅助工具、某些企业受管设备）打不开 PDF。如果内容很重要，请同时提供一个 HTML 版本。
错误 7：内容每周都变，却用了 PDF 二维码。餐厅菜单、每日促销、当前价格——这些场景都更适合 HTML 页面。“固定版式”的理由在这里不成立。
错误 8：服务商在取消订阅后会停用二维码。如果你的二维码服务商的政策是取消后停止跳转，那就不能放心地把它印在包装、名片这类长寿命物料上。
PDF 二维码和普通二维码有什么区别？技术上没有区别——二维码就是二维码。“PDF 二维码”这个说法只是表示目标 URL 指向一个 PDF 文件。二维码规范本身并不知道、也不关心目的地是什么。
能不能把 PDF 直接附在二维码里（而不是用链接）？不行，至少在实用尺寸下不行。二维码只能编码少量数据（最多几千个字符的文本），而 PDF 通常是它的几千倍大。PDF 必须托管在某处，由二维码指向它。
给二维码用的 PDF 最大能多大？技术上没有上限——二维码只承载 URL，不承载 PDF 本身。实用上，请把 PDF 控制在 2 MB 以内，以保证良好的移动端加载速度。文件再大，在慢速网络下用户就会放弃。
如果我更新了 PDF，二维码会失效吗？取决于 URL 是否变化。如果你保留同一个 URL，把那个位置的文件替换成新版（在自己服务器上是可以的），二维码仍然有效。如果上传新版时 URL 也变了（Google Drive 和 Dropbox 就是这种情况），静态二维码就会失效。动态二维码能解决这个问题——在后台改一下目标 URL，印好的二维码就会指向新文件。
能不能通过二维码追踪谁打开了我的 PDF？用动态二维码可以看到扫码统计（次数、地理位置、设备、时间）。要追踪用户在 PDF 内部的行为，就需要专门的 PDF 分析工具——这些工具是有的，但需要额外配置。
我的 PDF 二维码在 iPhone 和 Android 上都能用吗？两个平台都能扫二维码、都能打开 PDF。体验略有差异——iPhone 通常能更干净地内联显示 PDF，部分 Android 设备则会强制下载到另一个应用。上线前请在两种设备上都测一下。
要不要给 PDF 加密码？敏感 PDF（财务文件、内部材料）建议加。大多数营销类 PDF（白皮书、宣传册）不建议加——密码会增加摩擦，扼杀阅读率。
可以用免费的二维码生成器做 PDF 二维码吗？可以。大多数生成器都支持 URL 类型的二维码，这对 PDF 来说就够了。PDF 自己单独托管。如果二维码要印在长寿命物料上，请挑一个取消订阅后二维码仍然有效的生成器。
如果我的 PDF 特别大、压不下去了怎么办？把它拆成几个小文档，做一个落地页把所有部分链起来。或者干脆转成 HTML。一个 30 MB 的 PDF 藏在二维码后面，在手机端基本就等于坏了。
PDF 二维码能用多久？只要满足：（1）PDF 一直在那个 URL 上，（2）你的二维码服务商持续提供跳转（针对动态码），（3）URL 本身仍然有效。配上自己的托管和一家对长期可用性友好的服务商，可以用上几十年。
PDF 二维码有它真正的用武之地——手册、法律文件、白皮书、引流资料，以及任何对固定版式有要求的场景。当 PDF 体积小、对手机友好、托管在可靠域名、并通过可更新的动态二维码访问时，效果最好。
当 PDF 体积大、只为打印设计、托管在 Google Drive、用静态码编码、从来没在手机上测过——它就会失败。
所有不是真的非用 PDF 不可的内容，请直接用 HTML 页面。它加载更快、在手机上更易读、支持数据分析、更新也不用重新上传。
为你的 PDF 免费生成一个动态二维码
用错了场景，它会带来网上最糟糕的二维码体验之一——加载缓慢、链接失效、手机处理不了直接强制下载，或者 PDF 在手机上根本读不了。
这篇指南会告诉你：什么时候选 PDF、什么时候改用 HTML，文件该怎么托管才能真正加载得动，哪些设计细节决定体验好坏，以及哪些场景下 PDF 确实比网页更合适。
30 秒速读版
以下情况适合用 PDF 二维码：
- 内容版式固定且很重要——正式文件、法律函件、认证证书、签署过的表格。
- 用户需要离线保存这份文档——手册、说明书、要反复查阅的参考资料。
- 内容确实是长篇形式——完整白皮书、多页指南、可下载的电子书。
- 源文件本身就是 PDF，转换会损失保真度。
以下情况建议改用网页：
- 移动端可读性很重要——大多数营销内容都属于这一类。
- 内容会经常更新——菜单、价格、促销信息。
- 你想看用户读了什么——页面滚动、停留时长、点击事件。
- 内容很短——一页就能讲完的内容更适合做成网页。
拿不定主意时，就用 HTML。大多数 PDF 二维码的使用场景，其实换成一个移动端优化过的网页效果会更好。
为什么 PDF 二维码常常不如想象中好用
PDF 当初是为了固定版式打印而设计的。它给出了一个硬性承诺：这份文档在每一台设备、每一个浏览器、每一种操作系统上看起来都一模一样。1993 年，每个文字处理软件显示文档都不一样，这一点在当时是革命性的。
但同样是这个特点，让 PDF 在手机上表现得不太理想：
- 必须双指缩放。一份按 A4 或 US Letter 设计的文档不会自动适配手机屏幕。读者要放大、再向右滑去读完一行、再缩小看下一段。相比之下，网页会自动重排。
- 加载慢。即使是中等大小的 PDF（1–3 MB），在移动网络下加载的时间也明显比同等内容的网页要久。
- 手机浏览器处理 PDF 的方式不一致。有的内联显示，有的强制下载，有的会跳出去用单独的查看器打开。用户体验五花八门。
- 无障碍评分会下降。屏幕阅读器对 HTML 的支持比 PDF 好得多。低视力用户可以放大 HTML 文字，但在 PDF 文本里导航就比较吃力。
这并不是说不能用 PDF 二维码，而是说只有在 PDF 格式确实合适的时候才用。
什么时候 PDF 二维码确实是正确选择
下面这些场景，PDF 比 HTML 更合适：
产品手册和安装说明。用户想保留这种文档，会打印出来，几年后还会回头查。PDF 能保住版式（对示意图和零件清单来说往往很关键），下载后还能离线使用。
法律文件和合同。固定版式、签名真实性、正式感——这些预期 PDF 都能满足，网页则不行。
认证和资质证书。结业证书、专业资质、培训记录。持证人往往要打印出来或附在申请材料里。
对印刷设计有要求的餐厅菜单。高端餐厅的纸质菜单常常用了定制字体和精细排版，数字版希望完全一致。HTML 可以做得相似，但很少能做到一模一样。
引流资料和白皮书。当你用一份可下载的文档换用户的邮箱地址时，PDF 格式会强化“这是一份真文档，不只是篇博客”的感知。
税务文件、财务报表、技术规格书。任何在法律或技术层面对固定格式有要求的场合。
多页指南和电子书。任何超过 5–6 页、读者可能想保存下来的内容。
这些场景，PDF 确实是合适的工具。除此之外，HTML 页面几乎都是更好的选择。
PDF 该托管在哪里
决定用 PDF 之后，这是最重要的一个选择。托管地点决定了体验是快还是慢、是稳还是脆弱、是专业还是寒酸。
最佳选择：自己的域名。
把 PDF 放在你自己的服务器或 CDN 上。链接长这样：yourbusiness.com/downloads/manual-2026.pdf。带品牌、速度快、完全由你掌控。没有第三方依赖、不会被企业防火墙拦截、没有广告或插页。
对于真正认真对待 PDF 二维码的企业，这才是正确答案。
可以接受的选择：Amazon S3 或 Cloudflare R2 这样的 CDN。
实际效果和自己域名托管差不多，只是把带宽压力交给 CDN。默认链接可能是没有品牌的 CDN 地址，但几乎都可以映射到一个像 files.yourbusiness.com 这样的子域名。
有风险的选择：Google Drive、Dropbox、OneDrive。
PDF 放在你的云盘账户里，权限设为“任何拥有链接的人都可查看”。链接难看，更糟的是还有这几个问题：
- 企业防火墙经常会屏蔽这些域名。
- 查看体验不是原生的——用户看到的是 Google 的 PDF 预览器，而不是文档本身。
- 有些服务商会强制下载，而不是内联显示。
- 万一你不小心改了共享权限，所有印好的二维码立刻全部失效。
- 如果文件被重命名，链接可能会失效或变化。
个人使用或一次性文档可以接受。印在包装、名片或长期营销物料上的二维码，不适合。
折中的选择：二维码服务商自带的 PDF 托管功能。
有些二维码生成器会帮你托管 PDF，并从他们的域名提供访问。从历史上看这是个坏主意——一旦服务商托管出问题或你取消了订阅，所有印好的二维码就停止工作。对大多数付费服务商来说，至今仍是如此。
例外的是少数服务商（QR Cake 就是其中之一），既提供可靠的 PDF 托管，又承诺即便你取消订阅二维码也能继续跳转。对于没有自己的域名或 CDN 的非技术用户——比如餐厅老板、地产中介、小诊所——这种工作流就真的可行：上传一次 PDF，一分钟左右拿到一个动态二维码，以后想换 PDF 也不用重新印刷。如果你有自己的域名和工程能力来管理它，自托管仍然是最稳妥的选择。如果没有，找一个对长期可用性友好的服务商托管也是合理的退路——只是在把它印上去之前，请先确认服务商的取消政策。
文件大小和移动端性能
PDF 二维码只有 PDF 真能加载出来才算有用。在 4G 网络下，500 KB 的 PDF 和 5 MB 的 PDF 之间的差距，就是 2 秒和 20 秒的差距。大多数用户在 5–8 秒之间就会放弃。
解决方法：
- 目标控制在 2 MB 以内。多数文档经过合理优化都能做到。
- 压缩图片。一份典型 PDF 文件大小的约 80% 都是图片。照片用 JPG 质量 80–85%；截图和带文字的示意图才用 PNG。
- 字体子集化。只嵌入实际用到的字符，而不是整个字族，能显著减小文件体积。
- 少用花哨效果。PDF 的透明度、渐变、嵌入式多媒体都会增加体积。只有文档真的需要时才用。
不会破坏质量的压缩工具：Adobe Acrobat（另存为“已优化”版本）、ILovePDF、SmallPDF，技术用户也可以用 Ghostscript 这类命令行工具。
压缩之后，请在手机上实地测试一下文件大小。在光纤宽带上算“很小”的 PDF，到了偏远地区用移动数据访问，仍然可能慢得让人抓狂。
强制下载 vs 内联显示
默认情况下，浏览器可能把 PDF 内联显示，也可能强制下载。具体行为取决于服务器的 HTTP 头、浏览器和操作系统。
内联显示几乎总是更好的体验——用户扫码后 PDF 直接显示出来，不用离开浏览器就能滚动阅读。强制下载则会增加摩擦：用户得跑到“下载”文件夹里去找文件、打开、再回到原来的操作上。
要控制这件事，把二维码所指 PDF 的服务器 Content-Disposition 头设为 inline。如果用的是 CDN 或自己的服务器，这一项是可以配置的。如果用的是 Google Drive 或 Dropbox，那就改不了——它们会强制使用自己的查看器。
“我的 PDF 二维码在手机上感觉不太对劲”这种常见抱怨的真实解决方法是：把 PDF 放在自己的域名下，并把 Content-Disposition 设为 inline。这一项改动就能解决绝大多数投诉。
PDF 二维码：静态还是动态
静态 PDF 二维码把 PDF 的 URL 直接编码进二维码图案里。URL 永久不变。优点：不依赖任何服务商。缺点：一旦 PDF 移动位置或换了 URL，二维码就废了。
动态 PDF 二维码编码的是一个指向服务商服务器的短跳转链接，再由服务器跳转到实际的 PDF 地址。优点：目标可改、有数据分析、可以替换 PDF 而不动二维码。缺点：依赖服务商基础设施持续运行。
对于会随时间变化的 PDF——年报、更新版手册、有版本号的文档——动态二维码是必选项。你可以年年替换目标 PDF，而印好的二维码完全不用动。
对于永远不会变的 PDF——一次性活动邀请、定格的历史文档——只要你能永久控制目标 URL，静态二维码是可以接受的。
动态二维码下的 PDF 更新流程：
- 生成一个指向 PDF 第一版的动态二维码。借助 QR Cake 的 PDF 二维码类型这类工具，你可以直接上传文件，二维码就会基于托管好的 URL 生成——不需要单独搭一套托管。
- 每年（或 PDF 更新时），上传新版本并更新二维码的目标地址。
- 印好的二维码持续可用；它所指向的文件被刷新了。
- 旧版印刷品上的二维码仍然会把客户带到最新版的文档。
给手机阅读设计 PDF
即便托管和大小都处理好了，很多 PDF 在手机上仍然没法读，因为它们当初是按纸张设计的。
手机友好的 PDF 设计原则：
- 使用纵向页面方向。横向 PDF 在手机上特别糟糕——要么字小到看不见，要么用户得把手机横过来。
- 字号要比印刷常用的大。11–12 磅正文字在纸上没问题，但 14–16 磅才适合手机。如果 PDF 主要在数字端阅读，就选更大的字号。
- 尽量用单栏。多栏布局在手机上需要左右滚动。
- 高对比度。原则和网页设计一样——白底黑字胜过任何中间色调。
- 有用的标题层级。方便用户在支持大纲的查看器里跳转。
- 跳过封面页。一张精美的封面在手机屏幕上是浪费空间。直接进入内容。
如果你从头掌控 PDF 设计，也可以考虑做两版：一版面向打印优化，一版面向屏幕优化。二维码指向屏幕版，印刷用印刷版。
常见的 PDF 二维码错误
错误 1：商用场景下把 PDF 放在 Google Drive / Dropbox。不稳、手机上慢，企业防火墙还会拦。请用自己的域名。
错误 2：忘了压缩 PDF。动辄好几 MB 的文件在移动数据网络下加载会非常痛苦。
错误 3：经常更新的文档却用了静态二维码。每次年度更新都意味着所有印刷品要重做。会更新的内容请用动态二维码。
错误 4：照纸张设计的 A4 或 Letter 版 PDF，被人在手机上扫了。不放大不平移就读不了。要么重新按手机设计，要么承认这个限制，干脆改用 HTML。
错误 5：强制下载而不是内联显示。多了一道摩擦。请配置服务器的 Content-Disposition 头。
错误 6：没给打不开 PDF 的用户准备备选方案。少数用户（老款手机、某些辅助工具、某些企业受管设备）打不开 PDF。如果内容很重要，请同时提供一个 HTML 版本。
错误 7：内容每周都变，却用了 PDF 二维码。餐厅菜单、每日促销、当前价格——这些场景都更适合 HTML 页面。“固定版式”的理由在这里不成立。
错误 8：服务商在取消订阅后会停用二维码。如果你的二维码服务商的政策是取消后停止跳转，那就不能放心地把它印在包装、名片这类长寿命物料上。
常见问题
PDF 二维码和普通二维码有什么区别？技术上没有区别——二维码就是二维码。“PDF 二维码”这个说法只是表示目标 URL 指向一个 PDF 文件。二维码规范本身并不知道、也不关心目的地是什么。
能不能把 PDF 直接附在二维码里（而不是用链接）？不行，至少在实用尺寸下不行。二维码只能编码少量数据（最多几千个字符的文本），而 PDF 通常是它的几千倍大。PDF 必须托管在某处，由二维码指向它。
给二维码用的 PDF 最大能多大？技术上没有上限——二维码只承载 URL，不承载 PDF 本身。实用上，请把 PDF 控制在 2 MB 以内，以保证良好的移动端加载速度。文件再大，在慢速网络下用户就会放弃。
如果我更新了 PDF，二维码会失效吗？取决于 URL 是否变化。如果你保留同一个 URL，把那个位置的文件替换成新版（在自己服务器上是可以的），二维码仍然有效。如果上传新版时 URL 也变了（Google Drive 和 Dropbox 就是这种情况），静态二维码就会失效。动态二维码能解决这个问题——在后台改一下目标 URL，印好的二维码就会指向新文件。
能不能通过二维码追踪谁打开了我的 PDF？用动态二维码可以看到扫码统计（次数、地理位置、设备、时间）。要追踪用户在 PDF 内部的行为，就需要专门的 PDF 分析工具——这些工具是有的，但需要额外配置。
我的 PDF 二维码在 iPhone 和 Android 上都能用吗？两个平台都能扫二维码、都能打开 PDF。体验略有差异——iPhone 通常能更干净地内联显示 PDF，部分 Android 设备则会强制下载到另一个应用。上线前请在两种设备上都测一下。
要不要给 PDF 加密码？敏感 PDF（财务文件、内部材料）建议加。大多数营销类 PDF（白皮书、宣传册）不建议加——密码会增加摩擦，扼杀阅读率。
可以用免费的二维码生成器做 PDF 二维码吗？可以。大多数生成器都支持 URL 类型的二维码，这对 PDF 来说就够了。PDF 自己单独托管。如果二维码要印在长寿命物料上，请挑一个取消订阅后二维码仍然有效的生成器。
如果我的 PDF 特别大、压不下去了怎么办？把它拆成几个小文档，做一个落地页把所有部分链起来。或者干脆转成 HTML。一个 30 MB 的 PDF 藏在二维码后面，在手机端基本就等于坏了。
PDF 二维码能用多久？只要满足：（1）PDF 一直在那个 URL 上，（2）你的二维码服务商持续提供跳转（针对动态码），（3）URL 本身仍然有效。配上自己的托管和一家对长期可用性友好的服务商，可以用上几十年。
结论
PDF 二维码有它真正的用武之地——手册、法律文件、白皮书、引流资料，以及任何对固定版式有要求的场景。当 PDF 体积小、对手机友好、托管在可靠域名、并通过可更新的动态二维码访问时，效果最好。
当 PDF 体积大、只为打印设计、托管在 Google Drive、用静态码编码、从来没在手机上测过——它就会失败。
所有不是真的非用 PDF 不可的内容，请直接用 HTML 页面。它加载更快、在手机上更易读、支持数据分析、更新也不用重新上传。
为你的 PDF 免费生成一个动态二维码
关于 QR Cake 团队
由 QR Cake 团队撰写 —— 我们打造的 QR Cake 是一个动态二维码平台，用于可编辑的印刷活动、Canva 二维码、扫码数据分析，以及订阅结束后仍然可用的长期二维码跳转。
进一步了解 QR Cake常见问题
- 能不能把 PDF 直接附在二维码里？
- 不行，至少在实用尺寸下不行。二维码只能编码少量数据，通常就是一个 URL。PDF 必须单独托管，由二维码指向它。
- 给二维码用的 PDF 最大能多大？
- 技术上没有上限——二维码只承载 URL。实用上请把 PDF 控制在 2 MB 以内，以保证良好的移动端加载速度。文件再大，慢速网络下用户就会放弃。
- 如果我更新了 PDF，二维码会失效吗？
- 如果你保留同一个 URL、把那个位置的文件替换掉，二维码仍然有效。如果 URL 变了（Google Drive 和 Dropbox 就是这样），静态二维码就会失效。动态二维码可以通过在后台改目标 URL 来解决这个问题。
- 我的 PDF 二维码在 iPhone 和 Android 上都能用吗？
- 两个平台都能扫二维码、都能打开 PDF。iPhone 通常能干净地内联显示 PDF；部分 Android 会强制下载到另一个应用。上线前请在两种设备上都测一下。
- 能不能通过二维码追踪谁打开了我的 PDF？
- 用动态二维码可以看到扫码次数、地理位置、设备、时间等统计。要追踪用户在 PDF 内部的行为，需要专门的 PDF 分析工具，并做额外配置。
- 我的 PDF 该不该放在 Google Drive 上？
- 仅适合个人使用或一次性文档。商用二维码请放在自己的域名下——企业防火墙经常会拦截 Google Drive 链接，查看器也不是原生的，链接还很脆弱。
相关文章
继续阅读实用的二维码指南、案例和优化技巧。