企业官网建设流程全解析

你是不是也遇到过这种场景：监控大屏在会议室挂了一整天，页面里的EasyPlayer.js从早上拉流到下午，突然开始掉帧、音画不同步，鼠标点哪儿都没反应，最后Chrome标签页直接弹出“页面无响应”。第一次碰上这种事，我以为是网络问题，关了重开好一会儿又复发，后来才意识到，这根本不是流媒体服务不稳定，而是浏览器内存被长时间播放慢慢吃干了——典型的FLV播放内存泄漏。

这篇文章我把自己的排查过程、工具用法和修复手段完整写出来。内容围绕长时间播放FLV时的浏览器内存问题展开，包括一条直播流从网络到画面的完整链路、Chrome开发者工具的实战用法、5个高频泄漏点，以及一套可以直接抄回去的修复模板。适合正在做Web播放器、监控大屏、直播平台的开发同学，不管你是刚接手播放器项目，还是已经在被线上问题反复折磨，看完应该能少走不少弯路。

1. FLV播放器在浏览器里到底怎么吃内存？

1.1 一条FLV直播流从网络到画面的完整链路

要排查内存泄漏，先得搞清楚FLV播放器在浏览器里是怎么工作的。很多人一遇到内存高就疯狂改业务代码，结果越改越乱，其实问题出在底层机制上。

FLV播放器拉流的路径大致是这样的：先通过HTTP或者WebSocket拿到FLV二进制流，这一步网络层会把数据暂存在内存里，一般叫IO缓存；然后由解封装器（Demuxer）把FLV容器里的视频Tag、音频Tag拆出来，得到一个个编码后的数据包；再然后这些音频视频数据会被封装成MSE能识别的格式，通过SourceBuffer.appendBuffer()交给浏览器的媒体栈；最后浏览器解码器解码后把画面渲染到video标签上。

这里面有两段内存是最容易出问题的。第一段是网络层到解封装器的缓冲，本质就是一堆ArrayBuffer和Uint8Array，如果拉流速度和消费速度对不上，这里就会一直堆数据。第二段是MSE的SourceBuffer，它维护了一个buffered区间，如果你不主动清理已经播放过的内容，这个区间就会持续往后扩展，内存自然跟着涨。

打个比方，这跟家里的水管是一个道理：水管里始终要保持一段水，这样拧开水龙头才会立马有水，不至于停顿；但如果你只开进水口、下游一直不放水，水管迟早会爆。播放器也一样，缓冲区是必须存在的，关键是你得让缓冲的水流起来，一直只进不出，内存必然出问题。

1.2 内存增长不等于内存泄漏：如何区分正常水位和异常泄漏

不是说看到内存涨就是泄漏。直播流播放器刚启动时，内存快速上涨是正常的，因为播放器要建立缓冲、初始化解码器、拉取数据。你得先建立一个“正常水位”的概念。

正常的播放器内存曲线，大概是开始播放时快速冲到某个水位，之后在这个水位附近上下波动。CPU使用率可能会有波动，但整体是稳定的。当你暂停、切换线路或者频繁操作页面，内存可能出现小的波峰，但等一段时间或者手动触发垃圾回收之后，会回落到差不多的水平。

泄漏的特征就完全不一样了。最常见的是阶梯形上涨：每次切流、每次重连、每次有点交互操作，堆内存就往上爬一级，而且永远落不回去。另一种是单调递增：不管你有没有操作，只要播放器在跑，JS Heap就一路向上，直到页面卡死。还有一种情况比较隐蔽，就是DOM节点虽然从页面上移除了，但在堆快照里还能看到大量Detached节点，这说明有JavaScript对象仍然持有已经移除的DOM引用，属于典型的引用泄漏。

所以排查内存泄漏，第一件事不是改代码，而是先确认这是不是真的泄漏。我建议你先把正常播放10分钟、30分钟、1小时的内存曲线各录一份，作为基线数据存下来。后面再做任何修改，都要和这份基线去对比，否则很容易把正常的缓冲增长当成泄漏来修，最后把播放器越改越卡。

2. 排查前先武装好 Chrome 开发者工具

2.1 用 Performance 面板录一条“内存心电图”

Chrome的Performance面板是排查这类问题最直接的工具，它能把页面性能数据以时间线的形式录下来，其中就包括JS Heap、DOM节点数、事件监听器数量这些关键指标。

操作步骤很简单。打开播放页面，按F12进入开发者工具，切到Performance面板，点击录制按钮开始录制。然后让页面保持播放状态，至少录5到10分钟，有条件的话建议录半小时以上。录制结束后点击停止，面板会生成一条完整的性能时间线。

这时你要重点看Summary区域里的几个指标：JS Heap的大小走势、Documents数量、Nodes数量、Listeners数量。如果Listeners数量一直在增长，说明事件监听器有泄漏；如果JS Heap呈现台阶式上升，说明有对象被不断创建但从未释放；如果Nodes数量不断增加，说明DOM节点在循环创建但没清理。

录制时间太短看不出问题。一开始我排查的一个案例就是只录了两分钟，内存曲线看起来平平稳稳，差点把问题归到网络抖动上。后来挂了20分钟再看，阶梯状曲线非常明显。这里也顺便提一句，Performance面板里有一个手动触发垃圾回收的按钮，就在控制台Memory面板顶部的垃圾桶图标。录制结束后点一下，如果曲线的下降幅度很小，说明内存根本没有被回收，基本坐实泄漏。

2.2 用 Heap Snapshot 做三次快照对比

Performance面板告诉你“有没有问题”，Heap Snapshot告诉你“问题出在哪里”。快照的核心操作思路是：先拍一张初始状态，再拍一张运行后的状态，对比两者之间有哪些对象数量变多了、哪些对象的内存体积变大了。

实际排查的时候，我习惯拍三张快照。第一张在页面刚加载完毕、播放器开始工作10秒左右拍摄；第二张让页面持续播放20分钟以上再拍摄；第三张先手动触发一次垃圾回收，再等几秒拍摄。第三张快照非常关键，因为手动GC后，如果Heap里还有大量废弃对象没有被回收，说明这些对象被某些强引用链锁住了，这才是真正的泄漏点。

拍好快照后，把视图从Summary切换到Comparison模式，对比慢照和后续快照的差异。重点看三类东西：

• Detached DOM节点。如果数量增加，说明有DOM被移除但引用还在，比如video标签被移出DOM后还被JavaScript对象持有。
• ArrayBuffer、Uint8Array、String这类对象。数量持续增长，说明有缓冲区或二进制数据没有被释放。
• EventTarget、MediaSource、SourceBuffer对象。数量增加，说明播放器实例或者媒体资源对象没有被正确销毁。

点开具体对象，右侧的Retainers面板会显示它的引用链，也就是谁在持有这个对象。顺着引用链往上找，基本就能定位到泄漏的源头。比如说你看到一个MediaSource对象被一个闭包持有，而闭包又被一个全局数组持有，那问题就出在这个全局数组上。

2.3 用代码给播放器装上“仪表盘”

DevTools适合人工分析，但长时间挂着人工盯也不现实。我自己习惯在播放器业务代码里塞一段临时监控日志，输出关键指标到控制台，这样挂机跑一夜，回来翻日志就能看出趋势。

下面这段代码是我常用的监控模板：

setInterval(() => { const mem = performance.memory ? (performance.memory.usedJSHeapSize / 1024 / 1024).toFixed(2) : 'N/A'; const videoEl = document.querySelector('video'); let bufferedEnd = -1; let bufferedStart = -1; if (videoEl && videoEl.buffered.length > 0) { const len = videoEl.buffered.length; bufferedStart = videoEl.buffered.start(len - 1); bufferedEnd = videoEl.buffered.end(len - 1); } console.log( `[MEM] time=${(Date.now() / 1000).toFixed(0)}s`, `heap=${mem}MB`, `buffered=[${bufferedStart.toFixed(1)}, ${bufferedEnd.toFixed(1)}]s`, `current=${videoEl ? videoEl.currentTime.toFixed(1) : 0}s` ); }, 10000);

这段代码每10秒打印一次当前堆内存、video标签的缓冲区间和播放进度。这里有个判断技巧：如果bufferedEnd一直往后推，而且bufferedEnd - currentTime的差距越来越远，说明SourceBuffer的缓冲区间已经很大了，MSE侧肯定没有做清理。再结合堆内存走势，就能判断是缓冲膨胀导致的，还是纯JavaScript对象泄漏。

需要注意的是，performance.memory只有Chromium内核的浏览器才支持，Firefox和Safari里访问不到，所以代码里做了防空处理。如果测试环境是Chrome或Edge，这个指标基本够用。

3. 实战定位：五个最典型的泄漏点

3.1 播放器实例没有销毁：切流越多，内存越指

我在排查一个智慧园区项目时，线上反馈播放器连续切流几十次之后必定卡死。当时打开代码一看，切流的逻辑大致是这样的：先是player.pause()，然后new一个新的播放器实例，旧的实例完全没有销毁。这个写法会让每次切流都留下一个“僵尸播放器”，它还在持有网络连接、定时器、事件监听，甚至还在悄悄解码。

这种泄漏在Heap Snapshot里特别好认。你在Class Filter里搜索播放器类名，比如EasyPlayer或者FlvPlayer，会发现实例数量等于切流次数，而且大部分实例的状态不是销毁状态。也就是所有播放器对象虽然已经不可见了，但依然被某些全局引用或者闭包牢牢锁在内存里。

排查的时候可以做一个快速验证：写一个自动化脚本，每5分钟切一次流，切个10次，然后看内存曲线。如果每次切流之后内存在原来基线上又抬了一截，并且切流后即使手动GC也回不到切流前的高度，基本就是实例没销毁。

这种问题的修复思路很明确：用统一的PlayerPool管理所有实例，切流前先销毁旧的，再创建新的。正确的切流逻辑应该是先调用播放器的destroy()方法，把内部的事件、网络、解码资源全部释放，然后再创建新实例。

3.2 事件监听器“只进不出”：匿名回调的锅

播放器的API基本都是事件驱动型的，什么播放成功、缓冲中、报错，都会触发事件。如果你的业务代码也绑了一堆事件，而且用的是匿名回调函数，那就很危险了。匿名函数解绑的时候拿不到引用，off()根本不知道要去移除谁，监听器就会越积越多。

举个例子：

player.on('timeupdate', () => { updateTimeDisplay(player.currentTime); });

这段代码本身没毛病，但如果你在同一个播放器实例上重复执行这个逻辑，每次都会新增一个匿名监听器，而之前的监听器永远留在事件列表里。时间一长，每次时间更新触发的事件回调数量成倍增长，CPU和内存都会被拖垮。

还有一个高频坑是window.addEventListener('resize', ...)或者document.addEventListener('visibilitychange', ...)。页面切后台、切回来，如果绑定的回调没有移除，监听器数量也会不断上涨。

排查技巧是在Performance面板的Summary里盯Listeners数量。如果它随播放时间稳步增长，十有八九是匿名函数导致的。修复要诀是：所有监听器都必须用具名函数绑定，并且成对出现——绑定的时候叫什么函数，解绑的时候就用同一个函数。

3.3 Timer 和重连逻辑失控：断网后后台还在疯狂拉流

播放器项目基本都会做断网重连，但重连逻辑写不好，也会成为内存杀手。最常见的问题是：在error事件里直接写setTimeout(replay, 1000)反复尝试重连，一旦服务器持续不可用，这个定时器就会无限期地执行下去，不断创建新的请求和缓冲对象。

我遇到过一个案例，页面端断网3分钟，Network面板里躺着200多个pending请求，全是重试拉流的。这些请求占用的响应数据因为网络一直没有真正断开，可能部分数据已经缓存在内存里，再加上定时器队列的积压，内存直接飙升到几百MB。

排查的时候要结合Network面板和代码一起看。如果发现重试请求的时间和数量异常，就要检查重试逻辑里有没有设置次数上限、有没有指数退避策略、有没有在成功或销毁时清理定时器。

一个相对稳妥的重连模板是这样的：

let retryCount = 0; const MAX_RETRY = 5; function onError(err) { if (retryCount >= MAX_RETRY) { showErrorMessage(); return; } retryCount++; const delay = 1000 * Math.pow(2, retryCount); setTimeout(() => { player.start(); }, delay); } function onPlaying() { retryCount = 0; }

这里每次重试的间隔是指数增长的，既不会太激进，也给服务器恢复留了时间。同时规定了最大次数，超过就不再无脑重试。另外，在播放器destroy()的流程里，一定要把重试定时器也一并清理掉，否则播放器都销毁了，定时器还会在背后继续执行。

3.4 SourceBuffer 缓冲只增不减：MSE 背压问题

这条其实是FLV直播播放最常踩的坑，也是最容易被误认为是“网络卡”的地方。问题出在MSE的SourceBuffer身上，它在播放过程中会持续累积数据，如果你不主动清理已经播放过的内容，buffered区间就会越来越大。

播放半小时的直播，buffered区间的终点和起点可能已经相隔很远，底层数组大小在持续膨胀。尤其当播放器配置里的缓冲上限没有生效，或者项目侧误把和缓冲相关的参数调得过大时，内存涨幅会特别吓人。

类似的中间件配置大约是这样（以FLV.js系播放器为例，EasyPlayer.js如果暴露了同样参数，原理也一致）：

const config = { enableWorker: true, stashInitialSize: 384 * 1024, maxBufferSize: 3 * 1024 * 1024, maxBackBufferLength: 30, maxForwardBufferLength: 120 };

这里maxBackBufferLength控制的是已经播放过的内容向后保留多少秒，maxForwardBufferLength控制的是向前缓冲多少秒。超过这个长度，播放器内部会主动调用SourceBuffer的remove()方法，把过期的缓冲区间清理掉。

如果你用的是不带这些配置的播放器，或者想确认底层缓存是否真的在清理，可以自己写一段清理逻辑。关键是要判断sourceBuffer.updating状态，避免移除操作和添加操作冲突：

function trimSourceBuffer(sourceBuffer, videoElement) { if (sourceBuffer.updating) return; const buffered = videoElement.buffered; if (buffered.length === 0) return; const end = buffered.end(buffered.length - 1); // 如果向前缓冲已经超过30秒，就把前面的部分删掉 if (end - videoElement.currentTime > 30) { const removeStart = buffered.start(0); const removeEnd = end - 30; sourceBuffer.remove(removeStart, removeEnd); } }

不过在实际项目里，如果你能通过播放器配置解决，就尽量别自己手写。手写容易和播放器内部的清理逻辑打架，反而导致花屏或者异常卡顿。

3.5 WASM 解码上下文没释放：软解成为“钉子户”

EasyPlayer.js这类的播放器通常会提供MSE硬解和WASM软解两种模式。硬解走的是浏览器内置解码器，内存压力小；软解则要把完整的解码逻辑跑起来，内存占用高出不少。

如果你被迫使用WASM软解模式，那么重点检查解码器释放。WASM模块的解码器内部会分配很多内存块，比如YUV帧缓冲、RGB转换缓冲、环形队列等。这些内存在播放器destroy()的时候，必须通过解码器自己的销毁接口释放。如果只是简单地把video标签从DOM里移除，解码器上下文会一直残留在内存里，表现为一个大块头的WebAssembly.Memory对象或巨大的ArrayBuffer，而且数量还会随着每次切流逐步增加。

排查的时候，在Heap Snapshot的Class Filter里搜WebAssembly.Memory或ArrayBuffer，看它们的数量和内存体积。如果数量等于切流次数，而且每个实例的Retained Size都很大，那就是解码器没释放。

解决的办法，是确保销毁时按照播放器文档执行完整的销毁流程。如果播放器给了解码器层面的释放方法，比如decoder.destroy()或是terminate()，那就必须调用到位。另外如果你传了enableWorker之类的配置，销毁时还要看播放器是不是帮你在内部终止了Worker线程。Worker没有terminate()的话，它持有的内存也不会归还给浏览器。

4. 止血方案：从代码层面把泄漏堵死

4.1 封装一个播放器生命周期管理器

前面的定位说明了一个问题：大部分泄漏不是空间不够，而是生命周期管理粗心。刚上手播放器项目，很多人习惯到处new播放器，页面组件卸载也不做清理，结果必然出问题。我建议无论项目大小，都用一个简单的类统一管理播放器实例，把创建和销毁的入口收拢到一个地方。

下面是我在多个项目中用的一套简化版模板：

class PlayerPool { constructor() { this.pool = new Map(); } create(key, container, options) { this.destroy(key); // 如果已经有旧实例，先杀旧再建新 const player = createPlayer(container, options); // 具体创建逻辑按项目来 this.pool.set(key, player); return player; } get(key) { return this.pool.get(key); } destroy(key) { const player = this.pool.get(key); if (player) { if (typeof player.destroy === 'function') { player.destroy(); } clearVideoElement(player.video || null); this.pool.delete(key); } } destroyAll() { for (const key of Array.from(this.pool.keys())) { this.destroy(key); } } } function clearVideoElement(video) { if (!video) return; video.pause(); video.removeAttribute('src'); video.load(); }

这套代码能解决大部分“忘了销毁”的问题。create()方法里先destroy(key)这一步很关键，它保证同一个key下面的播放器永远是单例，不会因为重复创建而留下僵尸实例。destroyAll()主要给页面卸载场景用，比如关闭页面、组件卸载时，一行代码就能把所有播放器全部清理干净。

4.2 正确销毁的正确姿势

destroy()这个方法看起来简单，实际执行顺序很有讲究。直接粗暴地移除DOM节点，或者只调用player.pause()再不管了，都会留下隐患。

正确的销毁顺序大致是这样：

function destroyPlayer(player, videoElement) { // 1. 停止业务侧的定时器和网络请求 clearInterval(player._monitorTimer); clearTimeout(player._retryTimer); // 2. 调用播放器自己的销毁接口，让它清理内部事件、缓冲和解码器 if (player && typeof player.destroy === 'function') { player.destroy(); } // 3. 处理video元素 if (videoElement) { videoElement.pause(); videoElement.removeAttribute('src'); videoElement.load(); } // 4. 移除业务侧挂在外部对象上的事件 window.removeEventListener('resize', onWindowResize); }

第3步特别容易被忽略。video.removeAttribute('src')和video.load()的作用，是让浏览器彻底释放关联的解码资源和内存缓冲。如果你只是把video标签从DOM里移除，某些浏览器下解码器资源不会立刻释放，产生一堆Detached MediaSource。

还有一点：业务侧挂的定时器要在销毁播放器之前清理。原因很简单，如果定时器还在跑，它可能引用着播放器对象或者video元素，导致后续的destroy()方法调用了，对象依然被定时器持有，垃圾回收照样无法回收。

4.3 拉流侧的缓冲上限与清理策略

播放器长时间播放FLV，内存暴涨的很大一部分来自缓冲区不设限。这个问题的修复思路有两个方面。

第一，通过播放器配置来限制缓冲。不同的播放器暴露的配置名可能不一样，但核心参数基本是这几个：IO缓存初始大小、最大缓冲字节数、后向缓冲秒数、前向缓冲秒数。前面那张配置示例表已经给过参数了，你需要做的就是去查一下项目的播放器文档，把这几个值设置成合理的范围。

第二，如果你发现播放器配置不生效，或者用的播放器版本没有开放这些参数，那就要考虑在业务层主动做缓冲裁剪。但这里有个大坑：播放器内部的SourceBuffer对象通常不是直接暴露给你用的，不同版本API差异很大。所以在业务层操作SourceBuffer之前，一定要先确认播放器是否已经开启了自动清理。如果已经开启了，你再插入一套清理逻辑，反而可能出问题。

如果是基于FLV.js源码定制的播放器，那控制起来就方便了。你可以在源码层面组装好Trim逻辑，或者在配置里直接设好maxBackBufferLength。实际调优经验是：后向缓冲保留30秒左右足够，前向缓冲120秒左右已经很宽裕，设置得再大对用户体验没有明显改善，只会白白吃掉内存。

4.4 事件绑定与解绑的高危细节

播放器项目里事件绑定太常见了，也太容易出泄漏了。我总结几个高频雷区：

• 用匿名函数做回调，然后在高频事件里反复注册。时间更新、进度变化这类事件，回调会被频繁触发，一次绑定没解绑，量变很快变成质变。
• addEventListener和removeEventListener参数不一致。有时候绑定传的是{ once: true }，移除的时候没传，浏览器会视为不同的监听器组合，移除失败。
• 事件挂在window、document这些全局对象上。页面组件销毁后，全局对象依然存活，挂在上面的回调如果引用了组件内部变量，整个组件都无法被回收。

正确的做法很简单，绑定时用一个具名函数，解绑时用同一个函数引用：

function onTimeUpdate() { updateProgressUI(); } player.on('timeupdate', onTimeUpdate); // 销毁时 player.off('timeupdate', onTimeUpdate);

对于window和document上的事件，组件卸载时一定要移除。尤其是resize事件，如果你绑定了响应播放器尺寸变化的回调，不清理的话，每次窗口尺寸变化都会触发一堆已经废弃的组件逻辑，内存和CPU一起遭殃。

4.5 切流、重连、组件卸载三个高危场景模板

把前面的经验总结成三个可以直接套用的场景模板。

切流场景。一个页面可能有多路视频要切换，切流时先销毁旧的再建新的：

function switchChannel(newUrl) { playerPool.destroy('main'); playerPool.create('main', container, { url: newUrl, type: 'flv', autoplay: true }); }

重连场景。重连要限制次数，用退避策略，播放成功后计数清零，销毁时清理定时器：

function bindReconnect(player) { let retry = 0; function onError() { if (retry >= 5) { showErrorUI(); return; } retry++; const delay = 1000 * Math.pow(2, retry); player._retryTimer = setTimeout(() => player.start(), delay); } function onPlaying() { retry = 0; } player.on('error', onError); player.on('playing', onPlaying); }

组件卸载场景。以React为例，useEffect的清理函数里销毁播放器：

useEffect(() => { playerPool.create('main', containerRef.current, options); return () => { playerPool.destroy('main'); }; }, []);

这样组件卸载时，播放器实例、事件监听、定时器和SDK内部缓冲区都会跟着走一遍完整的清理流程，不会把记忆留给下一个组件。

5. 压测与验收：怎么知道真的修好了？

5.1 搭建一个“挂机七天”的压测方案

代码改完之后，最核心的问题是：怎么确认真的修好了？我的做法是搭建一个独立的压测页面，只保留播放器逻辑，不混入任何业务功能，然后长时间挂机观察。

测试流的准备也很重要。比较接近真实场景的做法是用ffmpeg把一路RTSP流转成FLV，推给本地HTTP服务。类似这样：

ffmpeg -i rtsp://your-camera:554/stream -c:v copy -c:a copy -f flv http://localhost:8080/live/stream.flv

如果你手头没有真实的RTSP摄像头，也可以用一个带测试频道地址的播放器Demo环境，关键是保证流稳定，避免播放器因为拉流异常引入额外的干扰变量。

压测的时候我习惯这样操作：播放器播放满1小时后，打开Performance录制，录个20分钟，然后手动触发GC，记录Heap是否回落到之前的基线。如果回落后依然比初始状态高出很多，说明还有东西没被释放。接着切流10次，每次切完等5分钟，看内存是否稳定，不会每次切流都晋升一个台阶。

如果有条件，可以用Puppeteer写个自动化脚本，循环执行“播放-暂停-切流-销毁-重建”这一套流程，每次间隔30秒左右，挂机跑一晚上。脚本里定期用performance.memory采集堆内存，输出到文件，第二天起来看数据趋势图。如果数据曲线是水平的，恭喜你，问题基本解决了。

5.2 常见问题速查表

我把排查过程中最常遇到的问题整理成了一张速查表，遇到对应现象可以直接查原因和解法：

5.3 容易误判的两种情况

排查内存泄漏时，有几种情况很容易被误判成“泄漏”，实际处理起来方向完全不同。

第一种是开播初期内存快速上涨。很多播放器在刚启动时会一次性预加载一段缓冲，内存上涨很快，看起来像泄漏，实际上播放几分钟后水位就稳定了。如果你在头两三分钟就拍板说“泄漏了”，大概率会误伤正常设计。正确做法是先让播放器跑个10分钟以上，等水位稳定后再做判断。

第二种是用WASM软解时CPU和内存天生就高。软解相对于硬解，内存占用高出几倍是正常的，不能单纯用“内存占用高”来下结论。你要对比的是同一模式下，长时间播放后内存是否会无限增长。如果只是维持在一个高位但很稳定，那只是成本问题，不是泄漏问题。

还有种情况比较隐蔽：页面里有其他模块，比如图表库、日志上报、全局状态管理，它们也可能导致内存曲线异常。如果你在排查时没把播放器单独隔离出来，很容易把别人模块的锅记到播放器头上。所以我一直强调，压测页面越干净越好，最少化复现才是排查内存问题最有效的手段。

我在实际项目里踩过最深的坑，是“明明调用destroy()了，内存还是泄漏”。后来反复看了很多次堆快照，才反应过来：destroy()只能清理播放器内部状态，但业务代码里对video标签的引用一直没清掉。那等于给对象留了一条后门，播放器销毁了，整个对象图却被这条引用牢牢拽住，永远不会被回收。从那次之后，我把所有播放器实例都收口到了PlayerPool里，统一管理销毁顺序，后来项目跑上一个月都没有再出现这类崩溃。

最后再分享一个小技巧：如果你在排查过程中发现疑似泄漏，别急着改代码。先在堆快照里把对象的Retainers引用链捋一遍，确认是谁在持有它。因为很多时候，问题不是播放器本身，而是业务侧哪一行不起眼的代码把播放器对象给卡死了。只要顺着引用链找到那行代码，修复往往只是一行删除的事。