2026 年 3 月，Video.js 发布了 v10.0.0 Beta。这是该项目 16 年历史上首次从零重构默认播放器 bundle，与之共同重写的还有 Plyr、Vidstack 和 Media Chrome 三个主流开源播放器项目。四个项目累计超过 75000 颗 GitHub Star、月均数十亿次视频播放，这次协作的目标只有一个：彻底解决视频播放器体积臃肿的老大难问题。
最终的成果超出预期：Video.js v10 默认播放器体积较 v8.x 版本缩减 88%。即便移除自适应比特率（ABR）模块后进行比较，v10 仍然比 v8 小 66%。这一数字背后是一套可复用的模块化架构方法论，而非简单的代码压缩。
16 年技术债务的触发点
Video.js 诞生于 Flash 向 HTML5 视频过渡的年代。2009 年的 Web 开发环境与今天截然不同：缺乏成熟的模块打包工具、没有 tree shaking、生态中也没有形成组件化的开发范式。随着时间推移，播放器承载了无数功能特性，但代码结构始终保持单体式设计 —— 一个巨大的对象承载状态管理、UI 渲染和媒体控制所有逻辑。
这种架构在功能层面没有问题，但在体积层面产生了严重后果。v8 版本的 core bundle 最小化后为 260.5 kB，gzip 压缩后仍有 75.2 kB。对于只需要基础播放能力的页面而言，这相当于加载了一个中等规模的前端框架，而其中大量代码可能永远不会被使用。
更关键的问题在于定制困难。设置 controls=false 理论上应该移除控制条相关代码，但实际上整个控制条模块仍会被打包进去。开发者若想精简体积，唯一的选择是 fork 整个代码库，这意味着长期维护成本的急剧上升。
三层分离：状态、UI 与媒体的解耦
v10 架构的核心突破是将传统单体播放器拆分为三个独立且可组合的层次：State（状态层）、UI（界面层）和 Media（媒体层）。每一层通过明确的 API 契约进行通信，而非之前的深度耦合。
这种分离的实现依赖几个关键工程决策。首先是组件粒度的精细化。createPlayer 函数接受一个 feature 数组参数，类似于 Zustand 的 slices 模式。如果播放器不需要音频功能，代码中就不会包含音量和静音相关的任何逻辑。在 v8 时代，这是不可能的 —— 除非修改源码并自行维护 fork 版本。
其次是 UI 组件的无样式化设计。v10 的界面组件借鉴了 Base UI 和 Radix UI 的思路，输出单个 HTML 元素并保留完整的 class 控制权。开发者可以直接操作 DOM 节点，不必像 v8 那样通过 CSS 特异性覆盖伪元素。Timeline 的进度条手柄在 v8 中是一个嵌套子元素的伪元素，而在 v10 中是一个真实元素，可通过 class 直接定制尺寸、样式和行为。
第三是预设系统的引入。团队分析了实际使用场景，发现视频播放器、音播放器、背景视频等用例之间的功能组合具有高度一致性。v10 将这些常见组合打包为预设（preset），开发者直接选用即可获得针对特定场景优化的体积。例如背景视频预设不包含控制条和音频功能，体积比完整视频预设再降低约 70%。
Streaming Processor Framework：流媒体的组合式引擎
v10 同时引入了名为 SPF（Streaming Processor Framework）的新流媒体处理框架。传统流媒体引擎如 HLS.js、dash.js、Shaka 都是单体架构，包含 DRM、广告、字幕、备选音频、CMCD 等众多功能的完整实现。对于只需要简单自适应码率播放的短视频场景，这构成了显著的资源浪费。
SPF 采用函数式组件的组合思路，根据实际需求组装流媒体引擎。以简单的 HLS 点播场景为例，SPF 组装的引擎仅包含 CMAF 格式解析、基本缓冲管理和 MSE 集成，体积仅为 38.5 kB（minified）/ 12.1 kB（gzip），是 HLS.js-light 的 12%，是 v8 时代 VHS 引擎的 19%。
值得注意的是，SPF 并不试图替代完整的流媒体引擎。v10 仍然兼容 HLS.js、Shaka、dash.js 等现有解决方案，开发可以根据功能需求和体积预算自由选择。
工程化参数与落地建议
基于 v10 的新架构，以下参数可供团队在实际项目中参考。
Bundle 目标值：对于常规网站嵌入的视频播放器，v10 HTML 预设的 gzip 体积为 25.1 kB，React 预设为 18 kB。若使用背景视频场景，React 版本可低至 3.5 kB。这些数字应作为新项目的体积基准线，超出则需检查是否引入了不必要的 feature。
Feature 按需引入：通过 createPlayer 的 feature 参数精确控制功能集。建议审计产品需求，逐一确认是否需要 audio、remoteDevices、persistentUserSettings 等功能，未使用的功能坚决排除。
预设优先：优先使用官方预设而非从零组装。预设经过团队优化，在体积和功能之间取得了经过验证的平衡。只有当预设无法满足需求时再考虑定制。
框架选择：React 版本的体积普遍小于 HTML 版本，因为框架特定的组件可以更好地利用 tree shaking。如果项目技术栈允许，优先选用 React 集成。
流媒体引擎选型：简单点播场景使用 SPF 引擎；需要 DRM、广告、复杂直播功能时回退到 HLS.js 或 Shaka。不要为简单场景加载完整引擎。
兼容性说明与迁移路径
v10 目前处于 Beta 阶段，API 尚未完全稳定。官方明确建议新项目试用，但生产环境仍应使用 v8.x 版本。迁移指南将在 GA 发布前推出，覆盖从 v8、Plyr、Vidstack 和 Media Chrome 的升级路径。
四个项目的团队正在推进功能整合，预计 2026 年中旬达到 GA。届时 v10 将提供与 v8 相当的功能覆盖率，包括广告支持和更多预设类型。
资料来源：Video.js 官方博客《Video.js v10 Beta: Hello, World (again)》（2026 年 3 月 10 日）