1. 项目概述：为什么我们需要关注Bilibili-Evolved的WebSocket安全

如果你是一个B站的重度用户，同时又喜欢折腾浏览器插件来获得更纯净、更强大的观看体验，那么“Bilibili-Evolved”这个名字你一定不陌生。它几乎是目前功能最全面、最受好评的B站第三方增强脚本。从去广告、下载视频、自定义界面，到直播工具箱，它几乎无所不能。但今天我们不聊它的炫酷功能，而是要深入一个绝大多数用户甚至开发者都可能忽略，却又至关重要的底层领域——它的WebSocket安全机制。

你可能会问，一个用户脚本，为什么要谈“安全机制”？这听起来像是服务器后端工程师才需要关心的事情。这正是问题的关键所在。Bilibili-Evolved作为一个运行在你浏览器里的脚本，它需要与B站的官方服务器进行大量实时通信，比如接收直播弹幕、礼物信息、房间状态变化等。这些通信，很多都是通过WebSocket协议完成的。WebSocket就像在浏览器和B站服务器之间建立了一条“双向高速公路”，数据可以实时、高效地流动。

然而，这条“高速公路”如果没有任何检查和防护，就会变得非常危险。想象一下，脚本可以随意监听所有经过这条通道的数据，甚至可以伪造数据发送给服务器。恶意脚本可以窃取你的直播互动信息、干扰你的观看体验，甚至可能利用漏洞进行更严重的攻击。因此，一个负责任的增强脚本，必须在利用WebSocket提供强大功能的同时，构建一套严谨的安全防线，确保通信的可靠性、数据的完整性以及用户隐私的安全性。这就是“Bilibili-Evolved的WebSocket安全机制”存在的核心意义。它不仅是技术实现的细节，更是开发者对用户信任的基石。接下来，我将为你层层拆解这套机制是如何工作的，以及我们在使用和开发类似功能时，应该注意哪些“坑”。

2. 核心思路：在便利与风险之间构筑防火墙

Bilibili-Evolved处理WebSocket的核心思路，并不是从零开始造轮子，而是基于“拦截、封装、管控”的策略，在B站原有的WebSocket连接之上，建立一个受控的代理层。这样做有几个关键考量：

2.1 为什么选择代理模式而非直接连接？

首先，直接创建新的WebSocket连接指向B站服务器是极其困难且不稳定的。B站的WebSocket服务（尤其是直播相关）有复杂的鉴权逻辑，连接地址往往带有动态生成的Token和参数，这些信息通常嵌入在页面初始化的JavaScript代码或后续的API响应中。脚本如果尝试自己逆向并模拟这套流程，不仅工作量大，而且一旦B站更新鉴权方式，脚本就会立刻失效。

因此，最稳妥、最兼容的方式是“搭便车”。Bilibili-Evolved会选择拦截页面自身创建的、通往B站官方服务器的WebSocket连接。页面代码已经完美地处理了所有鉴权和握手流程，脚本只需要“监听”这个已经建立好的、合法的连接即可。这相当于在官方建立的、安全的通信管道上，安装了一个“合规的监听器”和“过滤器”。

2.2 安全机制设计的三大目标

基于代理模式，其安全机制的设计围绕三个核心目标展开：

1. 隔离与沙箱化：确保脚本的WebSocket处理逻辑与页面原始逻辑完全隔离，互不干扰。脚本的行为不能导致页面原有的WebSocket功能崩溃（比如收不到弹幕），页面的更新也不应导致脚本的功能失效。这需要通过精细的事件监听和API劫持来实现。
2. 数据可信与防篡改：确保脚本接收到的WebSocket消息是真实的、来自B站服务器的，并且没有被中间人或其他恶意脚本篡改。同时，也要确保脚本发送出去的消息是符合协议规范的，不会向服务器发送非法数据导致账号风险。
3. 可控与可审计：所有通过脚本的WebSocket流量都应该是可监控、可控制的。开发者需要有能力在脚本内部对不同的消息类型进行开关控制，用户也应该能知晓脚本正在处理哪些数据。这为功能管理和隐私保护提供了基础。

2.3 技术选型：原生WebSocket与MessageEvent

在浏览器环境中，实现这一套机制主要依赖两个核心技术点：

• 原生WebSocket对象：脚本通过覆写window.WebSocket构造函数或原型链上的方法（如send、close），来拦截所有WebSocket实例的创建和操作。
• MessageEvent事件：通过重写WebSocket实例的onmessage事件处理器，或者使用addEventListener监听message事件，来截获所有通过该连接收发的数据包。

这种方案的优势是纯前端实现，无需后端支持，兼容性好。但挑战在于如何做到稳定、无感地拦截，并且处理好各种边界情况，例如WebSocket重连、多连接并存等。Bilibili-Evolved的代码中，这部分通常体现为一个独立的、高度抽象的WebSocket代理类或模块。

3. 核心机制深度解析：从拦截到分发的全链路

理解了核心思路，我们进入实战环节，看看这套机制具体是如何一步步构建起来的。我会结合常见的实现方式和潜在问题来讲解。

3.1 连接拦截与实例封装

第一步是抓住页面创建的WebSocket连接。通常，这会在脚本加载的早期，通过一段“注入代码”来完成。

// 这是一个简化的原理示例，并非Bilibili-Evolved的直接源码 const originalWebSocket = window.WebSocket; window.WebSocket = function(...args) { const socket = new originalWebSocket(...args); // 判断这个连接是否是我们需要关注的（例如指向B站直播服务器） if (isTargetWebSocket(args[0])) { return new Proxy(socket, { get(target, propKey) { // 重点拦截 `send` 方法和 `onmessage` 属性 if (propKey === 'send') { return function(...sendArgs) { // 在数据真正发送前，可以进行安全检查或记录 console.log('[安全代理] 发送消息:', sendArgs[0]); // 调用原始的send方法 return target.send.apply(target, sendArgs); }; } // 拦截对 `onmessage` 的赋值，以控制消息接收 if (propKey === 'onmessage') { return target._customOnMessageHandler; } if (propKey === 'set onmessage') { return function(handler) { // 将用户设置的处理函数，包裹在我们自己的处理逻辑中 target._customOnMessageHandler = function(event) { // 1. 先经过我们的安全处理和分发 const processedEvent = processMessageEvent(event); // 2. 如果处理后的消息仍然需要传递给页面原逻辑，则调用原handler if (handler && processedEvent.originalData) { handler.call(target, processedEvent); } }; }; } return target[propKey]; } }); } // 非目标连接，直接返回原对象 return socket; };

注意：这里使用了Proxy进行演示，因为它更直观。在实际生产环境中，为了更好的兼容性和性能，可能会选择直接修改WebSocket.prototype.send和WebSocket.prototype.addEventListener。关键是要确保拦截逻辑只应用于特定的B站WebSocket连接，避免影响页面其他正常的WebSocket功能（如第三方登录、客服聊天等），否则会导致网站功能异常。

3.2 消息协议解码与校验

拦截到连接后，核心工作在于处理onmessage收到的MessageEvent。B站WebSocket传输的数据通常是经过编码的，常见的是JSON格式或自定义的二进制格式（如直播弹幕常用的Protobuf）。

function processMessageEvent(originalEvent) { const originalData = originalEvent.data; let parsedData; let isValid = false; // 尝试解析数据 try { // 假设是JSON格式 parsedData = JSON.parse(originalData); // 进行基础校验：检查是否有预期的字段，或数据签名 isValid = validateMessage(parsedData); } catch (e) { // 可能不是JSON，或者是二进制数据 // 对于二进制数据，需要特定的解码器，如Protobuf // parsedData = decodeProtobuf(originalData); // isValid = validateBinaryMessage(parsedData); console.warn('[安全代理] 消息解析失败:', e); // 即使解析失败，也应考虑将原始数据传递回去，不影响页面原有功能 return { originalEvent, originalData, parsedData: null, isValid: false }; } if (isValid) { // 消息有效，进行业务分发（如触发弹幕渲染、礼物通知等） dispatchMessageToModules(parsedData); // 返回处理后的结果，通常我们会保留原始数据供页面使用 return { originalEvent, originalData, parsedData, isValid: true }; } else { // 消息校验失败！这可能是损坏的数据包或恶意伪造的数据。 console.error('[安全代理] 收到无效或可疑消息，已拦截:', parsedData); // 安全策略：可以选择丢弃此消息，不传递给页面原逻辑 // 这里返回一个修改过的event，其data为null，阻止后续处理 const blockedEvent = new MessageEvent('message', { data: null }); return { originalEvent: blockedEvent, originalData: null, parsedData, isValid: false }; } } function validateMessage(message) { // 示例校验逻辑： // 1. 检查必要字段是否存在 if (!message.cmd || !message.data) { return false; } // 2. 检查命令类型是否在预期的白名单内（例如，已知的弹幕、礼物、入场命令） const allowedCmds = ['DANMU_MSG', 'SEND_GIFT', 'INTERACT_WORD']; if (!allowedCmds.includes(message.cmd)) { console.log(`[安全代理] 忽略未知命令类型: ${message.cmd}`); return false; // 或者根据策略决定是否放行 } // 3. （如果协议支持）可以检查数据签名或时间戳，防止重放攻击 // if (message.signature !== calculateSignature(message)) { return false; } return true; }

实操心得：validateMessage中的“命令白名单”机制至关重要。B站的WebSocket协议可能会不断增加新的命令（cmd）。脚本如果盲目处理所有未知命令，可能会导致错误或资源浪费。一个健壮的实现应该有一个可配置的白名单，并且对于未知命令，默认采取“记录日志并忽略”的策略，而不是直接抛出错误导致整个消息流中断。同时，校验逻辑不宜过重，以免影响实时性。

3.3 事件分发与模块隔离

消息经过解码和校验后，需要安全、有序地分发给脚本内部各个需要消费这些数据的模块（如弹幕过滤器、礼物记录器、直播间状态显示器等）。这里需要一个内部的事件总线或发布-订阅系统。

class WebSocketEventBus { constructor() { this.handlers = new Map(); // cmd -> [handler1, handler2] } // 模块注册对特定命令的处理函数 subscribe(cmd, handler) { if (!this.handlers.has(cmd)) { this.handlers.set(cmd, []); } this.handlers.get(cmd).push(handler); } // 分发消息 dispatch(cmd, data) { const cmdHandlers = this.handlers.get(cmd) || []; const globalHandlers = this.handlers.get('*') || []; // 全局监听器 // 安全执行：确保一个模块的处理错误不会影响其他模块 [...globalHandlers, ...cmdHandlers].forEach(handler => { try { handler(data); } catch (error) { console.error(`[安全代理] 模块处理命令 ${cmd} 时出错:`, error, handler); // 可以选择上报错误，但不要阻断其他handler } }); } } // 在 processMessageEvent 中调用 function dispatchMessageToModules(parsedData) { const { cmd, data } = parsedData; eventBus.dispatch(cmd, data); }

这种设计实现了模块间的解耦。弹幕模块只关心DANMU_MSG，礼物模块只关心SEND_GIFT，它们互不知晓，也互不影响。这提升了代码的维护性和安全性，即使某个模块有bug或崩溃，也不会波及其他功能。

4. 高级安全策略与防御实践

除了基础的消息拦截和校验，一个工业级的增强脚本还需要考虑更多深层次的安全问题。

4.1 重连机制与状态同步

WebSocket连接并不总是稳定的。网络波动、服务器重启都会导致连接中断。页面自身的代码会处理重连，但我们的代理层也必须能优雅地应对这种状况。

• 监听连接状态：代理需要监听onopen、onclose、onerror事件。当连接关闭时，应清理内部可能存在的、依赖于该连接的状态（例如，清空正在缓冲的弹幕队列）。
• 避免重复代理：当页面重连成功，创建一个新的WebSocket实例时，我们的拦截代码会再次执行。必须确保不会对同一个逻辑连接进行多次代理包装，导致消息被重复处理。通常可以通过缓存已代理的连接URL或实例ID来判断。
• 状态恢复：连接恢复后，某些模块可能需要重新向服务器发送一些初始化请求（例如，重新获取直播间榜单）。事件总线应提供onReconnect这样的事件，让各模块有机会执行恢复逻辑。

4.2 流量控制与资源保护

直播间的消息流量可能非常大，尤其是在热门直播间。无限制地处理所有消息可能会阻塞浏览器主线程，导致页面卡顿。

• 消息节流：对于高频消息（如某些类型的节奏弹幕），可以在分发层进行节流。例如，确保每秒最多只处理N条相同类型的消息，超出部分合并或丢弃。
• 异步处理：将耗时的消息处理逻辑（如复杂弹幕渲染、礼物动画）放入requestAnimationFrame或Web Worker中，避免阻塞消息接收循环。
• 内存管理：建立消息队列的上限。如果消费速度跟不上生产速度，应丢弃旧消息，防止内存无限增长。这对于长时间挂机的用户尤其重要。

4.3 隐私数据过滤

这是安全机制中关乎用户伦理和法律的一环。WebSocket消息中可能包含其他用户的敏感信息（如部分用户名、UID、发言IP地区等）。一个负责任的脚本应该：

• 默认过滤：在内部处理数据时，默认不记录、不显示、不上传任何可能关联到具体自然人的信息。
• 提供明确开关：如果某些功能确实需要用到相关数据（如高亮某个特定用户的弹幕），必须向用户提供清晰、明确的授权开关，并说明数据用途。
• 本地化处理：所有数据处理尽量在用户浏览器本地完成，避免将原始WebSocket消息发送到第三方服务器。

4.4 对抗脚本冲突与恶意注入

在浏览器环境中，可能存在多个脚本同时运行。如何避免与其他也试图修改WebSocket的脚本冲突？

• 特性检测：在覆写WebSocket前，可以先检查是否已被其他代码修改过。如果是，可以尝试以更安全的方式“链入”自己的逻辑，而不是粗暴覆盖。
• 使用唯一标识：在代理对象或事件上添加一个唯一属性（如__bilibiliEvolvedProxy），方便自身逻辑识别，也避免与其他脚本混淆。
• 提供卸载清理：当脚本被禁用或卸载时，应尽可能地清理自己所做的修改，将WebSocket还原。这是一个良好的实践，但完全还原在复杂的拦截场景下可能很困难。

5. 常见问题、调试技巧与实战避坑指南

在实际开发和日常使用中，你会遇到各种各样的问题。下面是我总结的一些典型场景和解决方法。

5.1 问题排查：脚本生效了，但收不到任何WebSocket消息

这是最常见的问题。可以按照以下流程排查：

1. 检查拦截是否成功：在脚本的拦截代码入口处打console.log，确认window.WebSocket被成功覆写，并且目标URL的连接被正确识别。
2. 检查连接URL白名单：B站的WebSocket服务器地址可能不止一个，且可能随版本更新而变化。确保你的isTargetWebSocket函数覆盖了所有可能的域名模式（如*.live.bilibili.com/sub，*.chat.bilibili.com/sub等）。使用浏览器开发者工具的“网络”选项卡，筛选WS类型，查看页面实际建立的WebSocket连接地址。
3. 检查消息事件监听：确认你对onmessage的包装函数被正确设置。在包装函数内部打日志，看是否被触发。
4. 检查页面代码执行时机：你的脚本可能在页面创建WebSocket连接之后才加载。对于这种情况，需要额外的逻辑来“捕获”已经存在的WebSocket连接。可以通过遍历document.scripts或监听DOM事件来探测，或者直接检查window对象上是否已存在活跃的WebSocket实例。

5.2 问题排查：页面原有功能（如弹幕显示）异常

这通常是因为我们的代理逻辑错误地修改或丢弃了原始消息，导致页面的onmessage处理函数收到了错误格式的数据或根本没收到数据。

• 解决方案：确保在processMessageEvent函数中，无论消息是否被脚本内部处理，只要校验通过（或即使不通过但选择放行），都要将原始的、未被篡改的MessageEvent或一个格式完全相同的副本，传递给页面原来的事件处理器。“不破坏原页面功能”是代理模式的第一原则。

5.3 问题排查：脚本导致浏览器性能下降或内存泄漏

• 使用Performance和Memory工具：利用Chrome DevTools的Performance面板录制一段时间内的操作，查看是否有长时间的阻塞任务。使用Memory面板拍摄堆快照，检查WebSocket、MessageEvent或你自定义的事件总线对象是否被意外地大量持有，无法被垃圾回收。
• 审查你的分发逻辑：是否每个消息都触发了昂贵的DOM操作或计算？是否在闭包中形成了不必要的引用？确保在模块卸载时，从事件总线中注销监听器。

5.4 开发与调试技巧

• 建立模拟环境：在本地开发时，可以编写一个简单的Node.js服务器，模拟B站WebSocket服务器的行为，发送预设的测试消息。这比依赖真实的、不稳定的直播环境要高效得多。
• 消息录制与回放：在真实环境中，将拦截到的原始消息数据（originalEvent.data）录制保存为JSON文件。在调试时，可以从文件读取并回放，实现场景复现。
• 精细化日志系统：实现一个可分级（如DEBUG, INFO, WARN, ERROR）的日志系统，并允许用户通过配置开关。在调试时打开DEBUG日志，可以看到消息流转的每一个细节；在正常使用时关闭，避免console输出影响性能。

5.5 安全红线：绝对不能做的事情

1. 不要尝试解密或干扰非公开协议字段：如果消息中有加密或含义不明的字段，除非你有绝对把握且有必要，否则不要试图去解密或修改它们。只处理你明确知道其含义和作用的字段。
2. 不要高频次或大量发送数据到服务器：通过代理的send方法发送消息时，必须极度谨慎。除非是模拟用户正常交互（如发送心跳包、领取活动奖励），否则不要主动发送任何可能被服务器视为异常或攻击的请求。这可能导致你的IP甚至账号被风控。
3. 不要将原始消息数据上传到自己的服务器：这不仅涉及隐私和法律风险，也可能违反B站的服务条款。所有数据处理和分析都应发生在客户端。
4. 不要绕过或破坏页面的付费、认证逻辑：这是底线中的底线。增强功能的目的应是改善体验，而非获取不当利益。

理解Bilibili-Evolved的WebSocket安全机制，不仅仅是为了看懂一个脚本的工作原理。它更是一堂生动的客户端安全实践课，展示了如何在开放的浏览器环境中，以一种协作而非对抗的方式，安全、稳健地扩展第三方功能。无论你是想贡献代码的开发者，还是追求更好体验的高级用户，希望这份详解能让你在“折腾”的路上，走得更稳、更远。