合同附件还要下载才能看？附件在线预览三种方案对比

企业系统里总会遇到这个体验吐槽：审批单里挂了十几页的合同 PDF、图纸附件，想看得先下载，再用本地软件打开，手机上更是直接抓瞎。业务方提需求"能不能像网盘一样点开就看"，开发一查才发现：文件预览这件"小事"，水比想象中深。

核心矛盾是：文件格式五花八门（Office、PDF、图片、CAD、压缩包），浏览器原生只认少数几种，把各种格式变成"浏览器能看"，转换发生在哪一端，决定了成本、效果和安全性的平衡点。 业界有三条主流路线：服务端转换预览、前端解析预览、第三方预览服务，接入成本和可控性逐级变化。

方案一：服务端转换预览

原理： 服务器端把文档统一转成浏览器友好的格式：Office 文档用 LibreOffice/OnlyOffice 转 PDF，PDF 再转图片或直接嵌 iframe；CAD 用专业组件转 SVG。前端拿到的永远是"已转好的东西"，实现最简单。

优点：

• 前端极简：不管什么格式，最终都是 PDF 或图片，浏览器原生支持
• 格式覆盖最全：服务端组件能力强，CAD、Visio 这类冷门格式也能转
• 安全性好控制：原文不落地到浏览器，加水印、防下载都在服务端做

缺点：

• 服务端资源消耗大：转换吃 CPU 和内存，大文件并发转换需要队列和缓存
• 首次预览有延迟：转换是实时的，百页文档首次打开要等几秒到几十秒
• 格式还原度有损耗：复杂排版、特殊字体转换后可能走样，LibreOffice 对复杂 Word 的还原度是著名痛点

适用场景： 格式杂、安全要求高、预览频率中等的企业内部系统。文档管理系统、合同系统的主流选择，配合"首次转换后缓存结果"可以把延迟问题基本消化掉。

方案二：前端解析预览

原理： 文件直接在浏览器里解析渲染：PDF 用 PDF.js，Excel 用 SheetJS，Word 用 docx-preview，图片视频浏览器原生支持。服务端只管文件下载，解析全在客户端。

优点：

• 服务端零负担：不转换不算力，只当文件搬运工
• 还原度上限高：针对特定格式用专门库，PDF 的还原度可以做到像素级
• 离线可用：文件下载到浏览器后，解析不依赖网络

缺点：

• 格式覆盖有限：每种格式一个库，老旧格式（.doc、.xls）支持差，CAD 基本没戏
• 大文件性能差：百兆文件整个下载到浏览器再解析，内存和加载时间都扛不住
• 安全难控制：原文必然落地到浏览器，防下载防截屏基本做不到

适用场景： 格式单一明确（比如只有 PDF）、文件不大、对服务端成本敏感的轻量场景。在线教育、文档阅读类 C 端产品常用。

方案三：第三方预览服务

原理： 接入云厂商或专业服务商的在线预览 API（如各家文档预览服务、永中等）：把文件地址传给服务方，拿回一个预览页面地址嵌入系统。转换、渲染、缓存全部由服务方托管。

优点：

• 接入最快：几天就能上线，不用研究转换组件
• 效果专业：格式还原度、终端适配是服务方的核心竞争力
• 弹性伸缩：预览量忽高忽低也不用自己扛并发

缺点：

• 数据要出域：文件要传给第三方，涉密文档、私有化部署场景直接出局
• 长期成本按量计费：预览量大时年费可观，且价格主动权在对方
• 服务可用性依赖外部：对方服务抖动，你的预览就挂

适用场景： 快速上线验证、预览量小、无涉密要求的场景。创业团队和内部小工具的务实选择。

按场景对号入座

实战中常见的组合是分层处理：PDF 和图片走前端直渲（快且还原好），Office 和 CAD 走服务端转换（覆盖全），涉密系统坚决不出域。

落地前必做的三件事

第一件：盘清楚真实文件分布。 系统里存量附件的格式占比、大小分布、月度预览量，拿数据选型。九成附件是 PDF 的系统上全套转换服务，是杀鸡用牛刀。

第二件：定好转换缓存策略。 同一份文件反复转换是最常见的资源浪费：首次转换结果落缓存，文件变更才重新转换。预览接口的响应体验，八成靠缓存策略。

第三件：安全策略先于功能上线。 预览要不要水印、允不允许下载、敏感文件预览要不要二次鉴权，上线前定清楚。预览功能上线后再补安全，往往已经泄露过了。

写在最后

附件预览的核心不是"能不能看"，而是"在哪转、转成什么、给谁看"。格式分布决定技术路线，安全等级决定部署边界，预览量级决定成本结构。先把这三个问题答了，方案选型就是水到渠成的事。