利用Blob对象和iframe实现PDF跨域打印的JavaScript解决方案

1. 为什么你的PDF打印总报跨域错误？一个前端老兵的实战复盘

不知道你有没有遇到过这种让人头疼的情况：你辛辛苦苦在网页里嵌入了一个PDF文件，用户点击“打印”按钮，满心期待打印机开始工作，结果浏览器控制台却冷冷地抛出一个“跨域错误”（Cross-Origin Error），页面直接卡住，打印功能彻底失效。我敢说，但凡做过Web应用打印功能的前端，十有八九都踩过这个坑。这可不是什么小众问题，而是前端开发在处理外部资源时，尤其是PDF文件打印时，一个非常经典且高频的“拦路虎”。

这个错误的根源，其实在于浏览器的同源策略。简单来说，浏览器为了安全，严格限制了来自不同“源”（协议、域名、端口号任意一个不同）的脚本之间的交互。如果你的网页部署在 https://your-app.com，而你要打印的PDF文件存放在另一个域名下，比如 https://cdn.other-domain.com/your-file.pdf，那么当你试图通过 iframe 的 contentWindow.print() 方法去调用打印时，浏览器就会无情地阻止，因为它认为这是不安全的跨域访问。错误信息通常长这样：Uncaught DOMException: Failed to read a named property 'print' from 'Window': Blocked a frame with origin...。看到这个，很多新手开发者就懵了，难道要为了打印功能去改服务器配置，设置复杂的CORS（跨域资源共享）头吗？对于很多只读第三方资源或者静态文件托管在CDN的场景，这根本行不通。

别急，今天我要分享的，就是一个纯前端的、非常巧妙的解决方案。它不需要后端配合，不依赖服务器设置，完全在浏览器端就能搞定。核心思路就是：把跨域的PDF文件，“变成”我们网页自己“本地”的文件，骗过浏览器的同源检查。听起来是不是有点意思？这个魔法般的转换，就依赖于JavaScript中的两个关键角色：Blob对象和动态创建的iframe。接下来，我就带你一步步拆解这个方案，从原理到代码，从踩坑到优化，保证你听完就能在自己的项目里用起来。

2. 核心武器拆解：Blob对象与本地URL的魔法

在深入代码之前，我们得先搞清楚手里的两件“法宝”到底是什么，以及它们是如何联手打破跨域壁垒的。

2.1 Blob对象：数据的“万能容器”

首先登场的是 Blob。你可以把它想象成一个在浏览器内存里创建的、非常灵活的“文件容器”。Blob 是 Binary Large Object 的缩写，顾名思义，它专门用来处理二进制大对象数据。无论是图片、PDF、视频还是任何其他格式的文件数据，只要你能拿到它的二进制流，就能把它塞进一个Blob对象里。

在我们的打印场景里，关键一步就是通过 fetch 或 axios 去请求那个跨域的PDF文件。这里有个非常重要的细节：fetch 请求本身，只要服务器没有明确通过CORS头禁止，浏览器是允许你获取到响应体的。跨域限制真正发威的地方，是在你试图去“操作”或“访问”这个来自不同源的 iframe 内部窗口时。所以，我们可以安全地使用 fetch，并指定 response.blob() 方法。这个方法不会触发跨域错误，它会将网络请求回来的PDF文件数据，原封不动地包装成一个Blob对象，存放在我们当前网页的内存中。此时，这个Blob对象已经和它最初的来源（那个跨域的URL）脱钩了，它变成了我们当前页面上下文“自产”的一个数据块。

2.2 URL.createObjectURL：给内存文件一个“本地地址”

光有内存里的数据还不够。浏览器里的 iframe 的 src 属性，或者 img 标签的 src，它们认的是URL地址，而不是一个Blob对象本身。这时候，第二个法宝 URL.createObjectURL() 就派上用场了。

这个方法非常神奇，它接收一个Blob对象（或者File对象）作为参数，然后瞬间生成一个以 blob: 开头的本地URL。例如：blob:https://your-app.com/550e8400-e29b-41d4-a716-446655440000。这个URL有什么特别之处呢？它指向的是浏览器内存中那个Blob对象所代表的数据，并且这个URL的“源”，被浏览器识别为当前网页的源。也就是说，通过这个 blob: URL，我们凭空创造