Video.js v10重写实测：4个开源播放器合体，体积砍掉88%

Video.js发布v10 beta了。不是小版本升级，是从零重写。

更狠的是，这次不是Video.js一个团队在搞——Plyr、Vidstack、Media Chrome四个开源播放器项目合并了，加起来75000+ GitHub Star，每月处理几十亿次播放。Steve Heffernan（Video.js原作者）16年后回来亲自操刀。

前端项目里视频播放器的体积一直是个老大难问题，动不动就1MB。这次号称砍了88%，我得实际看看到底怎么回事。

体积到底砍了多少

直接上数据，这是官方给的对比表，minified体积：

几个关键点：

v8默认包里捆绑了自适应码率（ABR）支持，大部分人装了video.js但根本没用ABR功能，白白多了几百KB。v10把ABR拆出去了，默认包只管基本播放。

React版居然比HTML版还小——62kB vs 97.4kB。原因是React版可以利用框架的tree shaking把没用到的UI组件彻底剔除，HTML版用Web Components做不到这么细粒度的裁剪。

最夸张的是背景视频场景，React版gzip后只有3.5kB。这个尺寸在以前想都不敢想。

新的流媒体引擎SPF

视频播放器体积大头其实不在播放器本身，而在流媒体引擎。HLS解析、分片加载、ABR切换、DRM、广告插入……这些加起来轻松几百KB。

v10搞了个新引擎叫SPF（Streaming Processor Framework），用函数式组件按需组合。不需要DRM？不打包。不需要广告？不打包。只需要简单的HLS播放？那你的引擎只有38.5kB minified。

引擎之间的对比更触目惊心：

hls.js是503kB，SPF是38.5kB，差了13倍。当然SPF目前只覆盖”简单ABR”场景，复杂的DRM、字幕、多音轨还得用hls.js。但大部分短视频、营销页、产品展示的场景，SPF完全够用。

API设计：Web Components + React双轨

v10的API设计思路跟之前完全不一样。v8那套jQuery时代的API（videojs('my-video', options)）被干掉了，换成两套方案。

HTML方案用Web Components：

<video-player>
  <video-skin>
    <video src="video.mp4"></video>
  </video-skin>
</video-player>

没有JS初始化代码，纯声明式。<video-player>是自定义元素，<video-skin>负责默认UI皮肤。如果你用的是静态站点或者不想引入框架，这套方案足够了。

React方案用createPlayer工厂：

import '@videojs/react/video/skin.css';
import { createPlayer } from '@videojs/react';
import { videoFeatures, VideoSkin, Video } from '@videojs/react/video';

const Player = createPlayer({
  features: videoFeatures,
});

function App() {
  return (
    <Player.Provider>
      <VideoSkin>
        <Video src="video.mp4" />
      </VideoSkin>
    </Player.Provider>
  );
}

React版有一等公民的TypeScript支持和Tailwind集成，Player.usePlayer()是个zustand风格的store，可以选择性订阅状态：

const paused = Player.usePlayer((s) => s.paused);
const currentTime = Player.usePlayer((s) => s.currentTime);

这意味着组件只在自己关心的状态变化时重渲染，不会因为currentTime每秒更新60次导致整个播放器UI重新渲染。这个设计比v8的事件监听模式高明太多。

极简播放器：<5kB就能跑

v10最让我印象深刻的是可组合性。如果你只需要一个视频加一个播放按钮，可以这样：

import { createPlayer, features } from '@videojs/react';
import { Video } from '@videojs/react/video';

const Player = createPlayer({
  features: [features.playback],
});

function App() {
  const store = Player.usePlayer();
  const paused = Player.usePlayer((s) => s.paused);

  return (
    <Player.Provider>
      <Player.Container>
        <Video src="video.mp4" />
        <button onClick={() => (paused ? store.play() : store.pause())}>
          {paused ? 'Play' : 'Pause'}
        </button>
      </Player.Container>
    </Player.Provider>
  );
}

gzip后不到5kB。features数组只传了playback，tree shaking会把进度条、音量控制、全屏按钮等所有没引用的组件全部剔除。

对比一下：以前用video.js做一个简单的产品介绍视频播放，最少也得75kB gzip。现在同样的功能5kB搞定。产品落地页、邮件模板里嵌视频播放，这个体积差距是质变。

四个项目合并这事靠谱吗

说实话，开源项目合并这种事历史上成功案例不多。我一开始也持怀疑态度。

但看了参与者的背景，觉得这次可能不太一样：

Video.js有39500+ Star，16年历史，npm上周下载量长期排前端库前100。Plyr是轻量派代表，109kB就能用。Vidstack是新生代，TypeScript原生、Web Components架构。Media Chrome是Mux出品，背后是专业视频基础设施公司。

这四个项目各有优势但单独发展都遇到瓶颈——Video.js架构老旧，Plyr功能太少，Vidstack生态不够，Media Chrome太底层。合并后各取所长：Video.js的品牌和生态，Plyr的轻量理念，Vidstack的现代架构，Media Chrome的底层能力。

更关键的是，Steve Heffernan亲自回来主导。创始人回归做重写，动力和话语权都够。不是社区驱动的松散合作，是有明确技术负责人的合并。

实际项目怎么迁移

如果你现在项目里用的是video.js v7/v8，迁移成本不低。API完全变了，不是改几个参数的事。

几个建议：

新项目直接上v10。beta阶段的风险是有的，但API大方向不会再改，值得赌一把。

老项目不急。v8还在维护，v10 stable之前不需要迁移。等正式版出来再看迁移指南。

如果你在用hls.js搭配其他播放器。v10兼容所有主流流媒体引擎，hls.js、Shaka、dash.js都能用。可以先换播放器壳子，引擎不动，分步迁移。

安装方式：

# HTML方案
npm install @videojs/html@beta

# React方案
npm install @videojs/react@beta

注意是@videojs/html和@videojs/react，不是以前的video.js包。npm包名都换了。

为AI Agent设计的代码库

官方博客里有一句话很有意思：”Designing the codebase and docs so AI agents building your player alongside you can actually be good at it”。

翻译过来就是：代码结构和文档刻意做了优化，让AI编程助手在帮你写播放器代码的时候能写得更好。

这个趋势值得注意。越来越多的库开始把”对AI友好”作为设计目标。具体到Video.js v10，体现在：

组件命名直白、类型完整（TypeScript原生），AI不用猜API；声明式API意味着AI只需要组合组件而不是理解复杂的命令式流程；文档结构化程度高，方便AI检索。

这不是噱头。现实是大量开发者已经在用AI写前端组件了，如果你的库API对AI不友好，开发者会换一个对AI友好的库。这正在成为前端库的隐性竞争力。

我的判断

Video.js v10是目前我见过的前端库重写中最有说服力的一次。不只是”我们重写了代码”，而是把四个项目的积累揉到了一起，同时解决了体积、架构、开发体验三个核心问题。

88%的体积缩减不是靠砍功能，是靠更好的架构——按需组合、tree shaking友好、引擎可替换。这才是正确的做法。

如果你做的产品涉及视频播放，现在就该关注v10了。不一定马上用，但至少了解它的架构思路。这套按需组合、框架原生集成的设计，大概率会成为下一代前端媒体库的标准范式。