企业官网建设流程全解析

摘要

一个已经上线运行的在线教学平台，原来通过第三方API + iframe实现PPT课件在线预览。随着用户量增加，第三方服务逐渐出现卡顿、加载失败等问题。本文记录一次真实改造过程：从Vue2升级Vue3，将PPT解析迁移到用户浏览器端，并继续解决PPTX组件音频自动播放、播放控件隐藏、大文件重复下载和ArrayBuffer缓存等问题，同时分享AI辅助阅读陌生开源源码、结合断点和调用栈定位问题的实际方法。

1. 项目背景

最近处理了一个已经上线运行多年的在线教学平台。

系统主要用于付费课件学习，后台可以上传课程资料，用户购买课程以后在平台内在线学习。

业务上还包括：

• 学习时长统计
• 下级账号
• 学员管理
• 子账号体系
• 分销
• 课程权限
• 课件在线查看

其中一个比较重要的要求是：

课件主要在平台内部查看，不直接提供原始PPT下载入口。

这个项目早期采用的是：

云存储 ↓ 第三方PPT预览API ↓ iframe ↓ 在线教学平台 ↓ 用户浏览器

第三方服务按年付费，通过API生成在线预览页面。

项目早期使用这种方式没有太大问题。

最大的优点就是：

开发成本低。

PPT解析、版式、字体、动画等复杂工作都交给第三方服务完成。

2. 为什么后来决定把第三方API换掉？

随着平台实际使用人数增加，客户开始陆续反馈：

• PPT加载时间变长
• 偶尔出现明显卡顿
• 网络波动时容易加载失败
• 个别时候直接打不开课件

问题并不一定出现在我们的服务器。

但是对于最终用户来说，他不会区分到底是谁的问题。

用户只会认为：

这个在线学习平台打不开课件。

这就暴露出了一个架构上的风险：

平台最核心的学习功能依赖了一个自己无法控制的第三方服务。

所以我们开始考虑：

能不能不再依赖第三方服务器解析PPT？

3. 第一个方案：把PPT解析放到浏览器端

原来的模式：

PPT文件 ↓ 第三方服务器 ↓ 服务器解析 ↓ 预览页面 ↓ 用户

新的思路：

PPT文件 ↓ 用户浏览器 ↓ ArrayBuffer ↓ PPTX解析组件 ↓ 浏览器渲染

最大的变化在于：

把集中在第三方服务器上的解析压力，分散到每一个客户端浏览器。

理论上这样可以解决第三方API稳定性问题。

但是新的问题马上出现了。

原项目使用的是：

Vue2

而Vue2生态下，我们能够找到并真正满足项目需求的PPTX解析组件并不多。

有些能打开PPT，但是格式兼容性比较差。

有些项目已经很久没有维护。

有些组件在复杂课件上的效果也不够理想。

最终我们决定：

先把整个前端从Vue2升级到Vue3。

4. Vue2升级Vue3并不是改一个版本号

这是整个改造里第一个比较耗时间的部分。

老项目升级框架，要处理的不只是：

vue@2

变成：

vue@3

真正麻烦的是项目里已经存在的大量：

• 组件
• 生命周期
• 插件
• API
• 第三方依赖
• 旧写法
• 全局配置
• 业务代码

所以这次升级的原则不是：

为了用Vue3而升级Vue3。

而是：

旧技术栈已经限制了解决业务问题的方案，所以才升级。

等原有业务在Vue3环境下基本恢复以后，才开始真正接入新的PPTX前端解析方案。

5. PPT能够打开以后，真正麻烦的问题才出现

一开始测试的时候，效果其实还不错。

例如：

• PPT基本排版
• 页面切换
• 部分动画
• 批注
• 图文内容

整体基本可用。

但测试真实客户课件以后，很快发现了一个非常奇怪的问题：

PPT里的音频播放逻辑完全不对。

正常PowerPoint里的逻辑是：

进入页面 ↓ 看到小喇叭 ↓ 用户点击 ↓ 播放音频

但是网页端组件的实际表现却变成：

进入页面 ↓ 音频自动播放

更麻烦的是：

如果一个PPT页面里有两个音频文件：

audio 1 audio 2

可能会出现：

audio 1 + audio 2 同时播放

整个页面的声音直接乱掉。

对于在线教学系统来说，这显然无法交付。

6. 问题已经进入第三方组件内部

这个时候再检查我们自己的业务代码，意义已经不大。

因为问题明显来自：

PPTX解析组件内部的媒体播放逻辑。

这也是这次AI真正发挥作用的地方。

安装好的依赖代码往往有几个问题：

文件多 依赖关系复杂 缺少业务注释 调用层级深

如果完全靠人工从头一点点读，效率非常低。

于是我们把与PPTX解析相关的源码整理出来，让AI先帮助梳理：

哪些文件负责页面渲染？ 哪些文件负责媒体对象？ 音频从哪里创建？ video和audio在哪里处理？ 媒体播放事件在哪里触发？

AI主要做的是：

建立代码地图。

真正定位问题，仍然需要结合：

浏览器断点 + 调用栈 + DOM + 运行时变量

继续往下查。

7. 最终定位到媒体自动播放逻辑

经过多轮断点和调用栈分析以后，最后定位到了媒体相关处理。

我们发现这个组件对于媒体元素的处理比较统一。

简单理解就是：

页面展示 ↓ 媒体初始化 ↓ 触发播放行为

音频和视频都走了类似逻辑。

但是我们的业务要求不一样。

视频可以继续保持原有行为。

音频必须：

默认不播放

于是我们重新调整这一部分逻辑。

最终目标变成：

if (mediaType === 'audio') { // 音频默认不自动播放 } else if (mediaType === 'video') { // 保持原有视频逻辑 }

这里是逻辑示意，不是项目中的完整源码。

修改以后，第一个大问题解决：

一个页面存在多个音频时，不再同时播放。

8. 但是又出现了第二个问题：用户没地方点了

音频不自动播放以后，又发现一个新的问题。

在PowerPoint里正常可以看到：

🔊

也就是音频的小喇叭图标。

但是这个PPTX组件在放映模式下，并没有把音频播放控件显示出来。

结果变成：

音频不会自动播放 + 页面没有播放按钮 = 音频彻底不能使用

刚开始考虑过继续修改组件底层源码。

但后来没有这么做。

原因很简单：

魔改node_modules维护成本太高。

例如重新执行：

npm install

或者：

pnpm install

以后，本地修改可能就没了。

换电脑、重新部署、其他开发人员拉Git代码，都容易再次出现问题。

9. 最后反而通过DOM解决了这个问题

于是换了一个思路。

直接打开浏览器开发者工具检查DOM。

本来只是想碰碰运气。

结果发现：

虽然放映模式下看不到播放器，

但是DOM里面：

<audio></audio>

实际上还存在。

只是相关容器被隐藏了。

这就简单很多了。

既然元素还存在，就没有必要继续改底层解析库。

我们直接在自己的业务层进行处理：

找到隐藏容器 ↓ 强制显示 ↓ 调整尺寸 ↓ 增加小喇叭背景图 ↓ 恢复点击入口

比如类似：

.audio-wrapper { display: block !important; }

再给相应区域增加一个音频图标。

项目里使用了Base64形式的小喇叭背景图，避免再额外增加资源请求。

这样做最大的好处是：

减少对第三方源码的侵入。

这个项目也再次证明一个问题：

如果能在自己的业务层解决，尽量不要直接魔改依赖包。

因为系统真正的成本不只是开发，而是后面的维护。

10. 浏览器端解析以后，又遇到一个性能问题

PPT前端解析以后，每次加载流程大致是：

下载PPT ↓ Blob/File ↓ ArrayBuffer ↓ PPTX组件解析 ↓ 渲染

小文件没有明显问题。

但是部分教学课件非常大。

如果用户每一次打开课程，都重新：

下载 + 转换ArrayBuffer + 解析

会产生两个问题：

第一是加载时间。

第二是云存储流量。

而在线教育还有一个很明显的场景：

同一个学员会反复进入同一节课。

所以没有必要每次重新走一遍完整流程。

11. 增加浏览器端课件缓存

后面又增加了一层客户端缓存机制。

第一次访问：

课件ID ↓ 云存储下载 ↓ ArrayBuffer ↓ 写入本地缓存 ↓ PPT解析

再次访问：

课件ID ↓ 查询缓存 ↓ 命中 ↓ 直接读取ArrayBuffer ↓ PPT解析

伪代码类似：

async function loadCourseware(courseId, url) { const cache = await getCourseCache(courseId) if (cache) { return cache } const response = await fetch(url) const buffer = await response.arrayBuffer() await saveCourseCache(courseId, buffer) return buffer }

实际项目还必须考虑一个问题：

缓存失效。

例如后台重新上传了新版PPT。

这时如果只按照：

courseId

读取缓存，就可能继续看到旧版本。

所以缓存Key更合理的设计应该包含：

courseId + 文件版本

或者：

courseId + 更新时间

例如：

const cacheKey = `${courseId}_${fileVersion}`

文件改变以后，自然会生成新的缓存。

12. 整个架构最后发生了什么变化？

最初架构：

┌──────────┐ │ 云存储 │ └────┬─────┘ ↓ ┌──────────────┐ │ 第三方PPT API │ └──────┬───────┘ ↓ ┌──────────┐ │ iframe │ └────┬─────┘ ↓ ┌──────────┐ │ 用户浏览器 │ └──────────┘

改造以后：

┌──────────┐ │ 云存储 │ └────┬─────┘ ↓ ┌──────────────┐ │ 用户浏览器下载 │ └──────┬───────┘ ↓ ┌─────────────┐ │ ArrayBuffer │ └──────┬──────┘ ↓ ┌──────────────┐ │ PPTX前端解析 │ └──────┬───────┘ ↓ ┌──────────────┐ │ 浏览器缓存 │ └──────────────┘

真正改变的不是“换了一个PPT插件”。

而是：

把核心预览能力重新掌握到了自己的系统里。

第三方接口网络波动不再直接决定用户能不能打开课件。

同时服务器端也不需要承担大量PPT解析任务。

13. 前端解析也不是万能的

把解析放到客户端，并不是说这种方案没有成本。

浏览器需要承担：

• 文件下载
• 内存占用
• PPT解析
• DOM渲染
• 动画
• 音视频

所以对于特别大的PPT或者配置比较低的客户端电脑，仍然可能有性能问题。

因此最终还是要根据项目情况做取舍。

不是：

前端解析一定比服务端好

也不是：

第三方API一定不好

真正应该考虑的是：

什么方案最适合当前业务阶段。

14. 关于“在线预览但不允许下载”的一个技术边界

这个项目还有一个很现实的需求：

用户只能看课件，不能下载。

我们可以做很多限制，比如：

隐藏下载按钮 限制原始URL访问 临时签名URL 访问鉴权 Referer限制 权限验证

但是一旦采用浏览器端解析：

PPT原始数据

实际上就需要进入用户浏览器。

从技术原理上说：

不能承诺对具备较强技术能力的人做到100%绝对无法获取文件。

如果是版权要求非常严格的场景，还需要考虑：

服务端转码 切片 动态水印 截图水印 短期签名 DRM

等更复杂方案。

这也是系统开发中需要提前向客户说明的技术边界。

15. AI在这次改造里到底做了什么？

这次其实也是一个比较典型的AI辅助开发场景。

AI没有替我们：

一键修复PPT组件

真正有帮助的是：

面对一个完全陌生的开源项目时，先帮我们快速理解：

目录 依赖 模块 调用关系 可能的问题位置

然后开发人员再通过：

断点 调用栈 运行时状态 DOM 网络请求

一步一步验证。

所以我现在越来越觉得：

AI最大的开发价值之一，不一定是帮你写多少代码，而是帮助你快速理解别人留下来的代码。

尤其在旧系统、陌生组件、历史项目和开源库里，这个作用非常明显。

16. 这个项目最后留下的几个经验

这次改造以后，我总结了几个比较现实的经验。

第一，第三方API可以用，但核心业务必须考虑可替代性。

早期通过第三方服务快速上线没有问题。

但随着业务量增加，核心链路最好不要完全掌握在别人手里。

第二，技术升级一定要有业务理由。

这次从Vue2升级Vue3，不是为了“追新”。

而是Vue2技术栈已经限制了我们解决PPT前端解析问题的选择。

第三，尽量少魔改第三方依赖。

如果通过DOM、CSS或者业务层逻辑能够解决，就尽量不要长期直接修改依赖源码。

第四，大文件场景一定要考虑缓存。

同一个课件反复下载和解析，不只是用户体验问题，也是实际的云存储流量成本。

第五，AI非常适合辅助分析陌生代码。

但最终定位问题，仍然需要真正的调试、验证和工程判断。

写在最后

这次我们解决的表面问题只是：

在线PPT预览卡顿和音频播放异常。

但真正解决的问题其实是：

一个已经运行的在线教学平台，在核心第三方服务开始影响业务以后，如何在不推翻整个系统的情况下，把核心能力重新掌握回来。

老系统改造很多时候就是这样。

不是：

重新开发一个新的。

而是：

先理解现有系统，再找到真正制约业务的那一层，然后尽可能小范围、可维护地替换。

我觉得这也是企业系统二次开发和旧系统改造里，比“使用什么框架”更重要的一件事。

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