1. 从“刷课”这件事说起为什么需要防暂停但凡上过网课的人都懂那种感觉视频播到一半切出去回个消息回来发现进度条停了计时也断了。尤其是那种需要累计观看时长的课程页面一旦失去焦点或者鼠标长时间不动系统就判定你“不在电脑前”自动暂停播放。这不是什么高深的技术对抗纯粹是网页前端的一个监听逻辑在起作用。我最早接触这类需求是帮一个朋友处理他的在线学习任务。他报了一门课程要求在规定时间内完成若干小时的视频观看但他白天要上班晚上回家还要带孩子根本没办法坐在电脑前老老实实把视频看完。他的诉求很简单能不能让视频自己播完别老暂停。这个需求听起来有点“偷懒”但本质上是一个浏览器端自动化操作的问题跟技术伦理无关纯粹是解决一个具体的效率痛点。“快速刷党课bjut版防暂停”这个标题核心就两件事一是快速二是防暂停。快速意味着不能老老实实按原速播放得想办法加速防暂停意味着要绕过页面对于“用户是否活跃”的检测机制。这两件事在浏览器端都有成熟的实现路径而“油猴脚本”就是其中最常用的载体。油猴脚本正式名称是用户脚本管理器如Tampermonkey、Violentmonkey等它允许你在特定网页加载时注入一段自定义的JavaScript代码。这段代码可以修改页面的DOM结构、拦截事件监听、重写函数逻辑从而实现原页面不具备的功能。你可以把它理解成给浏览器装了一个“外挂插件”但这个插件是你自己写的只对你指定的页面生效。这篇文章适合几类人看一是有类似网课观看需求、想自己动手写个脚本解决问题的二是对油猴脚本开发感兴趣、想拿一个真实场景练手的三是已经用过别人写的脚本但遇到各种问题、想搞清楚背后原理的。我会从最基础的环境准备讲起一直讲到防暂停的核心逻辑和加速的边界处理中间会穿插我自己踩过的坑和实测有效的方案。注意本文讨论的技术方案仅用于个人学习和技术研究请在实际使用中遵守相关平台的使用条款。2. 油猴脚本的运行环境与基础骨架2.1 脚本管理器的选择与安装市面上主流的用户脚本管理器有三四个Tampermonkey俗称“油猴”是用户量最大的Violentmonkey是开源的替代品Greasemonkey则主要面向Firefox用户。我个人的建议是如果你用的是Chrome或Edge优先选Tampermonkey它的API兼容性最好社区文档也最全如果你对开源有偏好Violentmonkey完全够用而且它在某些API的实现上反而更规范。安装过程不复杂在浏览器的扩展商店里搜索对应名称点击安装即可。安装完成后浏览器工具栏会出现一个图标点击它就能看到“添加新脚本”的入口。这里有一个容易被忽略的细节安装完脚本管理器后建议重启一次浏览器。我遇到过好几次脚本不生效的情况排查半天发现是扩展没有完全加载重启后一切正常。2.2 元数据块脚本的“身份证”每个油猴脚本的开头都有一段特殊的注释叫做元数据块Metadata Block它用// UserScript和// /UserScript包裹起来。这段注释不是普通的注释脚本管理器会解析它来决定脚本在哪些页面上运行、什么时候运行、需要什么权限。一个典型的元数据块长这样// UserScript // name 快速刷课防暂停 // namespace http://your-namespace // version 1.0 // description 自动加速并防止视频暂停 // author You // match https://example.com/course/* // grant none // run-at document-end // /UserScript这里面几个关键字段值得展开说match决定脚本在哪些URL上生效。支持通配符比如https://example.com/course/*表示该域名下course路径的所有页面。写得太宽会误伤其他页面写得太窄又可能匹配不到需要根据实际课程页面的URL结构来定。grant声明脚本需要使用的特殊权限。如果脚本只是操作页面DOM写none就行如果需要跨域请求或者访问脚本管理器提供的存储API就需要声明对应的grant值。run-at决定脚本注入的时机。常见值有document-start页面开始加载时、document-endDOM加载完成时、document-idle页面完全空闲时。对于防暂停这类需求通常用document-end就够了因为需要等视频元素出现后才能操作。2.3 脚本注入时机的选择逻辑为什么注入时机很重要因为如果你的脚本在视频元素还没创建的时候就执行document.querySelector(video)会返回null后续所有操作都会报错。但如果你等到document-idle才执行又可能错过一些早期的事件监听。我的经验是先用document-end如果发现视频元素还没出现再加一个轮询或者MutationObserver来监听DOM变化。轮询的写法简单粗暴但有效function waitForVideo(callback) { const timer setInterval(() { const video document.querySelector(video); if (video) { clearInterval(timer); callback(video); } }, 500); }这段代码每500毫秒检查一次页面上有没有video元素一旦找到就停止轮询并执行回调。500毫秒是我实测下来比较平衡的值太短了浪费性能太长了用户能感知到延迟。3. 防暂停的核心页面是怎么检测你“不在”的3.1 常见的暂停触发机制要防暂停首先得知道页面是怎么判断你应该暂停的。我分析过多个在线学习平台的代码常见的检测手段无非以下几种第一种是页面可见性检测。浏览器提供了document.visibilityState和visibilitychange事件当用户切换到其他标签页或者最小化窗口时这个状态会变成hidden。很多平台会监听这个事件一旦发现页面不可见就暂停视频。第二种是焦点检测。通过监听window的blur事件或者document.hasFocus()方法判断当前窗口是否处于激活状态。你点击了其他窗口当前页面失去焦点就触发暂停。第三种是鼠标和键盘活动检测。页面会记录最后一次鼠标移动或键盘按下的时间如果超过某个阈值比如30秒没有任何输入就认为用户离开了。第四种是视频元素自身的事件。比如监听pause事件一旦视频暂停就记录状态或者监听timeupdate事件检查播放进度是否在预期范围内。这几种机制往往不是单独使用的而是组合起来。所以防暂停的思路也要对应地逐个击破。3.2 重写visibilityState和hidden属性最直接的思路是既然页面通过document.visibilityState来判断那我就把这个属性改成永远返回visible。但这里有个坑visibilityState是只读属性直接赋值是无效的。你需要用Object.defineProperty来重新定义它Object.defineProperty(document, visibilityState, { get: function() { return visible; }, configurable: true }); Object.defineProperty(document, hidden, { get: function() { return false; }, configurable: true });这两段代码把visibilityState永远返回visible把hidden永远返回false。这样即使你切到其他标签页页面自己检测的时候也会认为你还在当前页面。但光改属性还不够因为页面可能已经绑定了visibilitychange事件的监听器。你切标签页的时候浏览器仍然会触发这个事件监听器仍然会执行。所以还需要拦截这个事件的触发document.addEventListener(visibilitychange, function(e) { e.stopImmediatePropagation(); }, true);这里的关键是第三个参数true表示在捕获阶段拦截事件。stopImmediatePropagation会阻止事件继续传播到其他监听器。这样一来页面自己绑定的visibilitychange处理函数就收不到通知了。3.3 拦截blur和focus事件焦点检测的拦截思路类似。页面通常会这样绑定window.addEventListener(blur, function() { video.pause(); });你要做的就是在这个监听器之前拦截掉事件。但blur事件有个特点它不冒泡但可以在捕获阶段拦截。所以同样用捕获阶段的监听器window.addEventListener(blur, function(e) { e.stopImmediatePropagation(); }, true); window.addEventListener(focus, function(e) { e.stopImmediatePropagation(); }, true);不过这里要小心一个副作用如果你把所有的blur事件都拦截了页面上其他依赖焦点检测的功能可能会失效。比如某些输入框的验证逻辑。所以更精细的做法是只拦截特定目标的blur事件或者只在视频播放期间拦截。3.4 模拟用户活动定时器方案对于鼠标和键盘活动检测拦截事件是不现实的因为页面可能只是读取一个“最后活动时间”的变量。更稳妥的方案是主动模拟用户活动。最简单的方式是用setInterval定时触发一些无害的事件setInterval(() { const event new MouseEvent(mousemove, { bubbles: true, cancelable: true, clientX: Math.random() * window.innerWidth, clientY: Math.random() * window.innerHeight }); document.dispatchEvent(event); }, 10000);这段代码每10秒在页面上随机位置触发一次mousemove事件。对于页面来说就好像用户一直在移动鼠标。10秒的间隔是我测试下来比较安全的太频繁了可能被识别为异常太稀疏了又可能超过页面的检测阈值。提示有些平台会检测事件的isTrusted属性通过dispatchEvent触发的事件这个属性是false。如果遇到这种情况就需要换用其他方案比如直接修改页面用来记录活动时间的变量。3.5 直接操作video元素最暴力的兜底方案如果上面的方法都不奏效还有一个最直接的方案监听video的pause事件一旦暂停就立即播放。const video document.querySelector(video); video.addEventListener(pause, function() { this.play(); });这个方案的逻辑很简单你暂停我我就播放。但实际使用中要注意两个问题一是如果用户自己主动暂停这个逻辑会让用户无法暂停体验很差二是频繁的play/pause切换可能导致播放进度异常。改进的方案是加一个标志位只在“非用户主动暂停”时才自动恢复let userPaused false; video.addEventListener(pause, function() { if (!userPaused) { this.play(); } }); // 在用户点击视频区域时设置标志位 video.addEventListener(click, function() { userPaused !video.paused; });这样用户点击视频暂停时脚本不会强行恢复播放而页面自动暂停时脚本会立即恢复。4. 加速播放倍速的边界与风险4.1 playbackRate的合理范围HTML5视频元素有一个playbackRate属性可以直接设置播放速度。理论上你可以设置成任意正数但实际使用中要考虑几个限制浏览器限制大多数浏览器支持0.0625到16之间的倍速超出范围会抛出异常。平台检测很多学习平台会检测playbackRate的值如果发现不是1.0可能会记录异常或者直接重置。音频失真超过2倍速后音频会严重失真如果课程有听力内容基本没法听。我的建议是如果只是刷时长2倍速是安全和效率的平衡点。再高的话有些平台的风控系统会触发。如果平台不检测倍速4倍速也可以接受但要注意视频的timeupdate事件触发频率会变化可能影响进度上报。设置倍速的代码很简单video.playbackRate 2.0;但有些平台会监听ratechange事件一旦发现倍速被修改就重置回1.0。这时候你需要拦截这个事件或者用Object.defineProperty把playbackRate锁定Object.defineProperty(video, playbackRate, { get: function() { return 2.0; }, set: function() { /* 忽略设置 */ }, configurable: true });这段代码让playbackRate永远返回2.0任何试图修改它的操作都会被忽略。但要注意这样写之后你自己也没法通过常规方式修改倍速了需要提前想好。4.2 静音策略避免自动播放被阻止现代浏览器有一个自动播放策略如果视频没有静音play()方法可能会被拒绝除非用户已经与页面有过交互。在刷课场景中脚本自动调用play()时经常会遇到这个问题。解决方案是把视频静音video.muted true; video.play().catch(e { console.log(自动播放被阻止:, e); });静音之后浏览器的自动播放限制就解除了play()可以正常执行。但有些平台会检测muted属性发现静音就暂停。这时候可以用一个折中方案把音量设置成极小的值而不是完全静音video.volume 0.01;这样既不会触发自动播放限制也不会被静音检测发现。0.01的音量在实际环境中基本听不见但浏览器认为它不是静音状态。4.3 进度上报的模拟有些平台不是单纯看视频播放进度而是通过定时上报来记录学习时长。比如每30秒向服务器发送一次“心跳”包含当前播放位置和时间戳。如果你只是加速播放心跳上报的频率不变但两次心跳之间的进度差变大了平台可能会发现异常。对于这种情况有两种应对思路第一种是控制加速倍数让进度差保持在合理范围内。比如正常30秒心跳间隔2倍速下进度差是60秒如果平台允许的阈值是90秒那就没问题。第二种是拦截上报请求修改上报的数据。但这涉及到网络请求的拦截复杂度高很多而且容易触发更严格的风控。除非你非常清楚平台的检测逻辑否则不建议走这条路。我个人的经验是大多数平台的检测并没有那么精细2倍速加上防暂停基本能覆盖90%的场景。如果遇到特别严格的平台与其硬对抗不如老老实实按原速播放只是用防暂停来保证不中断。5. 脚本的调试与常见问题排查5.1 如何确认脚本是否生效写完脚本后第一件事是确认它有没有在目标页面上运行。最简单的办法是在脚本开头加一行console.logconsole.log(脚本已加载, new Date().toLocaleTimeString());然后打开浏览器的开发者工具F12切换到Console面板刷新页面看有没有输出。如果没有输出说明脚本没有匹配到当前页面需要检查match规则是否正确。如果console.log有输出但功能不生效那就需要进一步排查。我通常会在关键操作前后都加日志比如console.log(找到video元素:, video); console.log(当前倍速:, video.playbackRate);这样能快速定位是哪一步出了问题。5.2 常见报错与解决方案报错一Cannot read property play of null这说明document.querySelector(video)没有找到视频元素。原因可能是脚本执行太早视频还没加载出来。解决方案是加轮询或者用MutationObserver监听DOM变化。报错二play() failed because the user didnt interact with the document first这是浏览器的自动播放限制。解决方案是设置video.muted true或者video.volume 0.01。报错三脚本执行了但视频仍然暂停这说明页面的暂停逻辑没有被完全拦截。需要检查是否还有其他事件监听器在起作用。可以在开发者工具的Event Listeners面板中查看当前页面绑定了哪些事件。报错四倍速被重置回1.0这说明平台有检测ratechange的逻辑。解决方案是用Object.defineProperty锁定playbackRate或者拦截ratechange事件。5.3 性能与稳定性注意事项脚本运行过程中要避免过度消耗资源。比如轮询的间隔不要太短setInterval的回调里不要做太重的操作。我见过有人写了一个每10毫秒检查一次的轮询结果页面卡得没法用。另外如果脚本里用了setInterval记得在合适的时机清理。虽然对于单页面应用来说页面关闭时定时器会自动销毁但如果页面是SPA单页应用路由切换时定时器可能还在运行造成内存泄漏。// 保存定时器ID const timerId setInterval(() { /* ... */ }, 1000); // 在合适的时机清理 window.addEventListener(beforeunload, () { clearInterval(timerId); });6. 从“能用”到“好用”一些实战心得6.1 不要一次性把所有功能都打开我刚开始写这类脚本的时候喜欢把所有能加的功能都加上防暂停、加速、自动静音、自动下一集。结果就是脚本变得很复杂出了问题很难定位是哪个功能导致的。后来我学乖了每次只加一个功能测试通过后再加下一个。比如先只做防暂停确认视频不会中断了再加倍速确认倍速不会被重置再加其他功能。这样出问题的时候范围很小排查起来快很多。6.2 给脚本加一个开关不是所有时候都需要脚本生效。比如你自己想正常看视频的时候脚本的加速和防暂停反而碍事。所以最好给脚本加一个开关可以通过快捷键或者页面上的按钮来控制。最简单的开关是用localStorage存一个标志位const enabled localStorage.getItem(scriptEnabled) ! false; if (enabled) { // 执行脚本逻辑 }然后通过油猴脚本管理器的菜单或者自定义快捷键来切换这个标志位。这样你可以在需要的时候开启不需要的时候关闭灵活很多。6.3 观察平台的更新节奏在线学习平台的代码不是一成不变的它们会定期更新前端逻辑。你今天写的脚本能用可能下周平台一更新就失效了。所以如果你打算长期使用需要定期检查脚本是否还有效。我的做法是每次使用前先看一眼视频有没有正常加速和防暂停。如果发现失效了打开开发者工具看看页面的DOM结构或者事件绑定有没有变化然后对应地调整脚本。6.4 关于“快速”的边界最后说一个我自己的原则加速是为了节省时间不是为了作弊。2倍速看完一门课你至少还过了一遍内容16倍速刷完你什么都没学到只是完成了一个数字指标。如果课程内容对你真的有用建议还是正常速度看或者至少1.5倍速。脚本解决的是“我没办法坐在电脑前”的问题而不是“我不想学”的问题。这个边界想清楚了你写脚本的时候也会更有分寸不会为了追求极致的速度而把脚本写得过于激进反而触发平台的风控。6.5 一个容易被忽略的细节视频加载失败的处理在实际使用中我发现有时候视频会因为网络原因加载失败页面会显示一个错误提示或者一直转圈。这时候脚本如果还在傻傻地等video元素就会一直轮询下去。更好的做法是加一个超时机制function waitForVideo(callback, timeout 30000) { const startTime Date.now(); const timer setInterval(() { const video document.querySelector(video); if (video) { clearInterval(timer); callback(video); } else if (Date.now() - startTime timeout) { clearInterval(timer); console.log(等待视频元素超时); } }, 500); }这样如果30秒内还没找到视频元素脚本就放弃等待并输出日志不会无限轮询下去。6.6 关于多视频页面的处理有些课程页面不是单个视频而是一个列表点一个播一个。这种情况下document.querySelector(video)只会返回第一个视频元素切换视频后需要重新获取。解决方案是用MutationObserver监听DOM变化或者监听视频列表的点击事件document.addEventListener(click, function(e) { if (e.target.closest(.video-item)) { // 延迟一下等待新视频加载 setTimeout(() { const video document.querySelector(video); if (video) { video.playbackRate 2.0; video.muted true; video.play(); } }, 1000); } });这段代码在用户点击视频列表项后等1秒再获取新的视频元素并应用设置。1秒的延迟是为了给页面时间加载新视频。6.7 最后的建议保持脚本简洁我见过很多功能堆砌的脚本几百行代码各种兼容性处理最后自己都看不懂了。我的建议是只保留你真正需要的功能代码越简洁越好维护。一个50行的脚本如果能解决问题就不要写成200行。简洁的代码不仅容易调试而且平台更新时你也能更快地定位需要修改的地方。脚本开发这件事本质上是用技术手段解决一个具体的效率问题。工具是手段不是目的。把省下来的时间用在真正重要的事情上才是这个脚本最大的价值。