第三方PPT预览不稳定怎么办？一次在线教学平台从Vue2升级Vue3的真实改造记录

最近我们处理了一个已经上线运行的在线教学平台问题。

这个项目本身并不是新开发的。

它已经正常运行了一段时间，主要用于在线课件学习。后台可以上传PPT等课件，
用户购买以后可以直接在平台里在线学习，不提供原始文件下载。

系统里还包括学习时长管理、下级账号、学员录入、分销等一系列功能。

项目真正出现问题的地方，是PPT在线预览。

一、最初的PPT预览方案其实很简单

因为以前做过类似的在线教学项目，所以这个系统最初沿用了比较成熟的技术路线。

前端采用Vue2，PPT预览没有自己解析，而是接入了一家第三方在线文档预览服务。

第三方服务按年付费，提供API。

我们把课件文件交给第三方解析以后，
在自己的系统里通过Iframe嵌入预览页面，
再配合前端访问限制以及云存储鉴权，
让普通用户主要通过平台内部进行课件学习。

这种方案最大的优点就是：
开发快，而且前期稳定。

平台自己不需要处理复杂的PPT解析，
动画、字体、排版这些工作都交给第三方。

所以项目第一阶段采用这个方案，我认为并没有问题。

二、真正的问题是在系统运行以后出现的

后来客户开始反馈：

有时候PPT打开比较慢。

有时候因为网络波动，会出现明显卡顿。

严重的时候甚至会出现课件打不开的情况。

特别是在使用人数增加以后，
第三方接口本身一旦不稳定，就会直接影响整个教学平台的体验。

这时候问题就比较明确了：

第三方服务不是不能用。

但是一旦它变成平台核心链路的一部分，
它的网络、服务器、接口发生问题，
最终承担用户投诉的仍然是我们自己的系统。

三、我们开始考虑：能不能不再依赖服务器和第三方解析

最直接的思路，就是把PPT解析从第三方服务器转移到用户自己的浏览器。

也就是说：

以前是：

课件文件 → 第三方服务器解析 → 返回预览页面 → 用户查看

现在准备改成：

课件文件 → 用户浏览器加载 → 浏览器本地解析 → 用户查看

这样做有一个非常明显的好处：

把原来集中在第三方服务上的解析压力，分散到了每一个用户自己的客户端。

但新的问题马上又来了。

原来的项目使用的是Vue2。

在Vue2生态里，可以选择的PPTX前端解析方案比较少，
实际效果也很难完全满足这个项目的需求。

所以最后做了一个比较大的决定：

先把整个项目从Vue2升级到Vue3。

四、Vue2升级到Vue3，只是第一个坑

老项目升级框架并不是改一个版本号那么简单。

原来的组件、写法、依赖、生命周期以及部分业务逻辑，
都可能受到影响。

这部分折腾了不少时间。

等整个项目能够重新正常运行以后，
我们才开始接入新的PPTX前端预览组件。

一开始测试效果其实还不错。

PPT基本排版能够解析，部分动画也能正常工作，
批注等内容整体表现也可以接受。

我当时以为最麻烦的问题已经过去了。

结果真正打开客户的实际课件以后，又出现了一个非常奇怪的问题。

五、PPT里的音频全部乱了

这个客户的培训课件里，不只是文字和图片。

有些PPT页面里还有音频。

正常情况下，在PowerPoint里打开课件以后，
音频是用户点击小喇叭以后才播放。

但是通过新的网页解析组件打开以后，
情况完全变了。

只要翻到这一页，页面里的音频就直接开始播放。

如果一页PPT里面有两段音频，
两段甚至可能同时播放。

页面一切换，声音就乱成一团。

这种效果显然不能交付给客户。

六、这次AI真正帮上忙的地方，是“读别人留下来的代码”

这类问题比较麻烦的一点是，
它并不是我们自己的业务代码出错。

问题出在第三方开源组件内部。

安装依赖以后，真正需要分析的代码数量非常大，
而且大量代码没有我们熟悉的业务注释。

靠人工一点一点从头读，效率非常低。

于是我们把组件对应的开源代码以及相关依赖整理出来，
让AI先帮助分析：

哪些文件负责PPT页面渲染？

哪些代码负责媒体对象？

音频和视频播放分别从哪里触发？

然后再结合浏览器断点、调用堆栈和实际运行状态继续排查。

这里我觉得AI真正发挥价值的地方，并不是替我们“一键写完功能”。

而是：

最终通过调试，我们找到了媒体播放相关逻辑。

进一步发现，这个组件对于音频和视频采用了比较统一的自动播放处理。

也就是说，当页面被展示出来以后，
媒体元素就可能直接进入播放状态。

七、先解决第一个问题：音频禁止自动播放

找到问题以后，我们没有大面积修改整个PPT解析库。

而是只处理最关键的一层逻辑：

音频默认不自动播放，视频继续保持原来的处理方式。

这样至少先解决了一个PPT页面里存在多个音频时，
声音同时播放的问题。

但新的问题紧接着又出现了。

声音是不自动播放了，
可是用户怎么点它？

在电脑PowerPoint里，我们可以看到一个小喇叭。

而这个组件进入放映模式以后，
音频播放控件被隐藏掉了。

八、第二个问题，反而用一个更简单的方法解决了

这时候继续修改底层依赖当然也可以。

但是修改第三方依赖有一个很现实的问题：

不好维护。

以后换电脑、重新安装依赖、部署新服务器或者重新拉取Git代码，
都可能需要再次修改。

所以我们换了一个思路。

直接通过浏览器审查元素，看放映状态下音频对象到底还在不在DOM里面。

结果比较幸运。

虽然界面上看不到播放按钮，
但是Audio元素实际上仍然存在，只是被隐藏了。

既然元素还在，事情就简单了。

最后没有继续修改整个底层库，
而是在项目自己的样式层处理：

把对应隐藏区域重新显示出来，
再给它加上一个小喇叭样式的背景图，
恢复一个用户可以理解的音频点击入口。

这样既解决了实际使用问题，
又尽量减少了对第三方依赖源码的侵入式修改。

九、PPT可以解析以后，又碰到了大文件问题

把解析放到浏览器以后，还有另外一个性能问题。

PPT文件比较大的时候，
如果用户每次打开课件，都重新从云存储下载完整文件，
再转换成ArrayBuffer交给组件解析，
体验和流量成本都会受到影响。

所以后面又增加了一层浏览器端缓存。

基本逻辑是：

第一次访问：

下载课件 → 转换ArrayBuffer → 解析 → 浏览器端缓存。

再次访问：

先根据课件ID检查缓存 → 如果缓存有效，直接读取 → 不再重新下载完整课件。

这样做以后，
对于用户反复学习同一个课件的场景，
加载速度和云存储流量都会得到改善。

当然，缓存还需要考虑版本更新。

如果后台重新上传了新版本课件，
就需要通过文件版本、更新时间或者其他标识让旧缓存失效，
否则用户可能继续看到历史版本。

十、最后整个PPT预览链路发生了什么变化

原来的方案是：

云存储 → 第三方PPT解析服务 → Iframe → 用户浏览器

现在变成：

云存储 → 用户浏览器 → ArrayBuffer → PPTX前端解析组件 → 浏览器缓存

最大的变化不是换了一个插件。

而是：

把一个自己无法控制的核心第三方依赖，从主要业务链路中拿掉了。

第三方接口的网络波动不再直接决定用户能不能看课件，
课件解析压力也分散到了用户自己的浏览器。

这套方案当然也不是没有代价。

客户端解析意味着用户设备需要承担更多CPU和内存压力，
所以对于特别大的PPT、配置较低的电脑以及复杂动画课件，
仍然需要继续做性能测试和兼容处理。

十一、这里还有一个“防下载”的现实边界

在线教学平台经常会有一个需求：

课件只能看，不能下载。

从产品层面，我们当然可以隐藏下载入口、限制原始链接访问、
增加鉴权、控制有效期，并且避免把真实文件地址直接暴露给普通用户。

但是如果PPT文件最终需要下发到浏览器才能解析，
从技术原理上讲，
就很难对一个有足够技术能力的用户做到100%绝对禁止获取原始数据。

所以真正版权要求特别高的项目，
还应该结合动态鉴权、水印、转码、切片甚至服务端渲染等方式综合考虑。

这也是做项目时必须和客户提前讲清楚的技术边界。

十二、这个项目给我的几个判断

做完这次改造以后，我反而觉得有几个问题比“用了什么插件”更值得记录。

第一，第三方服务能解决问题，但核心业务不能完全没有替代方案。

第三方API前期可以大幅降低开发成本，
但一旦成为核心链路，就必须考虑稳定性和可替代性。

第二，老系统升级，不应该只是为了追新技术。

这次从Vue2升级Vue3，不是因为Vue3更新，
而是原来的技术栈已经限制了解决业务问题的选择。

第三，AI最有价值的一个开发场景，是帮助理解陌生系统和陌生源码。

遇到复杂依赖时，它可以先帮我们建立代码地图，
再由开发人员结合断点、堆栈和真实运行情况确定最终问题。

第四，能少改底层依赖，就尽量少改。

因为项目不是今天运行就结束了。

还要考虑以后更新、部署、Git管理和其他开发人员接手。

很多企业系统运行几年以后都会遇到类似的问题。

原来的框架旧了，某个第三方接口不稳定了，
原来的开发人员不在了，某个依赖不再维护了。

这种时候，重新开发一套往往不是最好的答案。

更重要的是先把现有系统重新看懂，
找到真正制约业务的那一层，
然后尽可能小范围、可维护地把它替换掉。

系统改造真正考验的，很多时候不是“能不能重新做一个”，
而是“能不能在不影响已有业务的情况下，把旧系统继续救活并往前走”。

技术实施：康天宇 整理：李东旭