打开任何一篇讲“js自动刷视频”的帖子评论区永远分成两派一派求脚本、求代码另一派骂这玩意儿没用、早晚被封。我做了五年前端和三年自动化测试工具这类脚本从原理到翻车现场都见过不少。先把话说明白这篇讲的是这类需求背后的JavaScript技术底色也就是DOM操作、事件模拟、定时器调度、页面状态监听这些真东西目标场景是我自己搭的测试页面和授权范围内的页面功能验证。拿它去替代本人完成在线学习任务既违反平台的使用规则也把该自己学的东西刷没了这笔账怎么算都亏所以我不会给可直接套用到学习平台上的成品。但技术本身值得讲清楚因为掌握它你能做很多正经事批量验证自己开发的播放器组件、给内部培训系统做压力测试、写回归脚本。下面按我从零实现一遍的思路把整个链路拆开。1. 拆解“自动刷视频”背后的真实技术需求1.1 这类脚本本质上在解决什么问题剥掉“刷”这个字眼剩下的技术需求其实非常清晰一个网页上有一个长时播放的媒体元素或者一系列需要连续处理的条目用户希望在不手动点击的情况下让页面按照预设节奏自动推进到下一个。把它抽象成一句话就是——在页面生命周期内周期性地检测状态、触发动作、推进流程。这跟自动化测试里“等待元素出现、点击、断言结果、进入下一步”的循环没有本质区别只是外观看起来像在“刷视频”。真正让事情变复杂的是网页不是静态的。播放器可能被包在iframe里进度条可能是canvas画的下一个视频的dom节点是接口回来之后才渲染的这些变量决定了脚本的复杂度。我碰到过一个播放器组件进度信息压根不在DOM里而是挂在一个全局对象上靠读文本节点根本拿不到最后是监听组件自己派发的自定义事件才解决。所以你在动手前先要区分三种情况纯DOM可读可控的、需要事件模拟的、以及状态藏在JS运行时的。前两种用原生JS就能搞定第三种就得看你能不能找到那个状态的入口。搞清楚这一点后面选什么方案就有据可依了。1.2 为什么用JavaScript而不是别的方案有人会问为啥不直接写个桌面自动化去点鼠标因为面向浏览器页面JavaScript有几个天然优势。第一它跑在页面上下文里能直接访问DOM和运行时对象不存在坐标偏移、分辨率适配这些破事。第二浏览器的控制台就是现成的调试环境document.querySelector一敲元素拿没拿到一目了然迭代速度极快。第三它有真正的事件循环机制定时器、Promise、MutationObserver配合起来能写出响应式的流程控制。这里顺带说个容易被忽略的点。很多人写自动化脚本喜欢用setInterval无脑轮询结果页面卡、内存涨。更稳的做法是用MutationObserver监听DOM变化再配合Promise做串行推进。Promise的优势在于能把“等待某个条件成立”这件事写成链式流程避免回调地狱。比如“等播放结束再点下一步”这种逻辑用Promise包一层代码可读性比嵌套回调高一个量级。1.3 适合谁来读这篇内容如果你是会点HTML CSS但JS只停留在能改改样式的水平这篇文章能帮你把DOM操作、事件、定时器这几个概念串起来形成完整的工程直觉。如果你已经能写脚本但总是遇到“跑一会儿就停了”“按钮点了没反应”那第2章和第4章里的事件模拟和DOM监听部分应该能对上你的痛点。如果你纯粹是被“自动刷视频”这个词吸引来的建议先把第6章读了再回头看技术能少走很多弯路。2. 核心技术点从定位元素到驱动流程2.1 定位播放元素的几种思路与取舍第一步永远是找到那个真正承载播放的元素。最常见的是video标签document.querySelector(video)直接就拿。麻烦在于现在很多播放器不是原生的外面套了一层又一层div真正的video藏在深几层的结构里或者干脆用多个video做切换。这时候可以按优先级来写选择器先精确匹配带特定属性的再退化到标签名。function findVideo() { // 优先找带关键属性的更精确 return document.querySelector(video[src]) || document.querySelector(.player video) || document.querySelector(video); }切换条目的按钮同理优先考虑稳定属性id、data-*实在没有再用文本内容匹配。用文本内容匹配时要格外小心因为文字会因为多语言、动态加载、空白字符而变最好用includes做包含判断而不是全等。比如判断按钮文字里是否含“下一”用text.includes(下一)比抗造得多这就是“js判断字符串是否包含”这类基础API在实战里的价值。提示尽量不要用第几个子元素这种位置选择器比如:nth-child(3)页面一改结构就全废。稳定的属性选择器寿命长得多。2.2 触发播放与推进事件模拟的那些坑找到元素不代表能驱动它。浏览器的安全策略要求媒体播放通常得由用户手势触发脚本直接调video.play()有时候会被拦报一个播放被拒绝的错。绕过的方式是模拟一次真实点击用dispatchEvent派发一个click事件。function simulateClick(el) { const evt new MouseEvent(click, { bubbles: true, cancelable: true, view: window }); el.dispatchEvent(evt); }这里有个大坑不同框架对事件的响应方式不一样。原生监听addEventListener的派发事件就能触发。但有些老代码写的是onclick内联或者用的是React那套合成事件直接派发原生事件可能不生效。React的合成事件挂在根节点上得保证事件冒泡上去bubbles: true就是干这个的。而如果是jQuery绑的它监听的也是原生事件一般没问题。另一种思路是直接调组件暴露的方法比如播放器实例上的next()这比模拟点击稳得多前提是你能拿到那个实例。很多时候实例挂在某个全局变量上或者DOM节点的某个属性里需要点逆向的功夫去找这就是大家常说的“js逆向”范畴属于进阶内容。2.3 定时器与轮询的经典陷阱最朴素的写法是setInterval每隔几秒检查一次进度。代码三行搞定setInterval(() { const v document.querySelector(video); if (v v.ended) { clickNext(); } }, 5000);但这三行藏着问题。第一间隔选多少是个权衡太短CPU和内存压力大太长切下一个滞后明显。我一般从3000到5000毫秒起步。第二setInterval不会自动停页面关了它还在那儿挂多开几个标签页就积压一堆timer。第三也是最坑的一点轮询在页面切到后台标签时会被浏览器降频。为了省电浏览器会把后台页面的定时器从几秒一次降到一分钟甚至更久很多人脚本“切出去就不动了”就是这个原因。解决办法是给轮询加上退出条件并把推进逻辑抽成独立函数用Promise串起来一个结束了再启动下一个等待而不是裸跑一个永不停止的interval。async function waitUntil(check, timeout 300000, interval 3000) { const start Date.now(); while (Date.now() - start timeout) { if (check()) return true; await new Promise(r setTimeout(r, interval)); } return false; }这个waitUntil是个通用工具函数后面反复用。注意setTimeout套在Promise里配合async/await就能把“等条件成立”写成一行await比回调清晰太多。这也是理解“js event loop过程”的实际收益——你知道await会让出执行权宏任务微任务怎么排队就不会写出阻塞整个页面的死循环。3. 手写一个可控的页面自动化脚本合规演练3.1 先给自己搭一个测试页面真要在正式页面上折腾出问题不好排查还可能误伤。我的习惯是先写个模拟页面把要处理的场景都复现出来一个能播的视频、一个播放结束会派发事件的逻辑、一个“下一集”按钮、以及一部分异步渲染的内容。video idplayer width480 controls/video div idtip/div button idnext styledisplay:none下一节/button script const list [a.mp4, b.mp4, c.mp4]; let idx 0; const player document.getElementById(player); const nextBtn document.getElementById(next); function load(i) { player.src list[i]; player.play().catch(() {}); } player.addEventListener(ended, () { nextBtn.style.display inline-block; }); nextBtn.addEventListener(click, () { idx; if (idx list.length) { nextBtn.style.display none; load(idx); } else { document.getElementById(tip).textContent 全部完成; } }); load(0); /script这个页面刻意做了两件贴近真实的事一是“下一节”按钮初始隐藏播放结束才显示二是完成之后有个明确的结束标识。有这两点脚本才能练到条件等待和终止判断。3.2 把核心循环写出来有了测试页核心逻辑就是前面那些工具的组合。整体是一个状态机等待播放结束、检查按钮是否出现、点击、等待下一个视频就绪。async function autoLoop() { let guard 0; while (guard 100) { guard; // 1. 等到结束标志出现 const ended await waitUntil(() { const v document.querySelector(video); return v v.ended; }, 600000, 3000); if (!ended) break; // 2. 判断是否已完成 if (document.body.textContent.includes(全部完成)) break; // 3. 找按钮并点击 const btn [...document.querySelectorAll(button)] .find(b b.textContent.includes(下一节)); if (btn btn.offsetParent ! null) { simulateClick(btn); } // 4. 等新视频加载 await waitUntil(() { const v document.querySelector(video); return v !v.ended v.readyState 2; }, 30000, 1000); } console.log(流程结束); } autoLoop();这段代码里有几个刻意设计。guard是防止死循环的安全阀万一条件永远不满足最多跑一百轮就停不至于把页面卡死。offsetParent ! null用来判断按钮真的可见因为display:none的按钮虽然能被选到但点了没用。用展开运算符把NodeList转数组再find这是处理“一堆同类型元素里找特定那个”的标准手法比依赖位置靠谱。3.3 状态判断为什么用“包含”而不是“等于”第3步里我用includes判断页面文字这比等号判断稳。真实页面的文案往往带空格、换行、动态数字比如“共3节 全部完成”全等必然匹配失败。凡是拿文本做判断优先用包含、正则而不是全等。这也呼应了前面提到的字符串处理别看它是基础语法实战里判断失误十有八九栽在这儿。另外注意trim。DOM里的文本节点经常带一堆空白和换行直接includes可能都对不上稳妥做法是先把文本replace(/\s/g, )压掉空白再判断。这个细节很小但能省你半小时的困惑。4. 页面结构变化与检测机制4.1 用MutationObserver监听动态渲染前面用轮询能跑通但页面如果发呆很久轮询就是纯浪费。更好的方式是监听DOM变化什么时候目标出现了什么时候响应。MutationObserver就是干这个的。function observeFor(selector, timeout 30000) { return new Promise((resolve) { const found document.querySelector(selector); if (found) return resolve(found); const observer new MutationObserver(() { const el document.querySelector(selector); if (el) { observer.disconnect(); resolve(el); } }); observer.observe(document.body, { childList: true, subtree: true }); setTimeout(() { observer.disconnect(); resolve(null); }, timeout); }); }用subtree: true是因为目标可能藏在好几层子节点里。这个函数把“等某个元素出现”封装成一个Promise跟前面的waitUntil互补轮询适合判断状态变化ended这种观察器适合判断元素出现。两者结合脚本的响应速度和资源占用都能明显改善。这里有个隐藏风险观察器回调用的是querySelector全文档查找如果页面DOM极其庞大且变化频繁回调会被高频触发反而更耗性能。所以理想做法是在回调里先做低成本判断或者把观察范围限定到某个容器节点上别动不动就监听整个body。4.2 页面常见的“防自动化”手段及其原理说到这儿就得聊一个绕不开的话题现在不少在线平台会做一些检测识别出脚本行为之后停止计时、弹验证、甚至记录异常。了解这些机制的原理对做正规自动化测试的人同样有用因为你需要知道自己写的脚本会不会被误判。常见手段有这么几类。一类是检测焦点和可见性页面失焦或者切到后台就暂停计时因为正常用户看视频时页面是激活的而脚本行为经常发生在后台。一类是检测事件来源人工点击的事件isTrusted是true脚本派发的原生事件是false虽然不能百分百判定但结合其它信号就能提高识别率。还有一类是行为节奏分析真人点按钮的时间间隔是波动的脚本如果每次都是精确的固定间隔特征就很明显。这些设计说明一个道理平台是希望用户真的在看、真的在操作的。所以脚本用于刷量这种行为本质上是跟产品设计意图对着干被检测、被判无效是必然的严重的还会触发账号处罚。站在技术学习角度理解这些机制没问题但别把它当成“对抗工具”去研究方向就跑偏了。4.3 iframe嵌套场景的处理思路很多课程页面会把播放器塞进iframe里这时候主页面拿不到里面的元素得先进入iframe的文档上下文。const frame document.querySelector(iframe); const innerDoc frame.contentDocument || frame.contentWindow.document; const innerVideo innerDoc.querySelector(video);跨域的情况下contentDocument会拿到null因为同源策略拦着这时候主页面脚本根本碰不到里面的内容。有些页面完成一个阶段后会通过window.sendMessageToIframe这类接口给子页面发消息父页面监听message事件来刷新自身状态这种通信机制在正经开发里很常见理解它的原理对做页面交互有帮助。处理完iframe里的流程后往往还要通知父页面更新或刷新这就是postMessage该上场的地方。父页面监听message、收到后刷新列表这个链路在“iframe 关闭 并刷新父页面”这类需求里是标配。5. 常见问题速查与排查经验5.1 典型故障对照表现象可能原因排查方向脚本跑一会儿不动了轮询被后台降频让页面保持前台或改用事件驱动play()报错被拒绝缺用户手势用模拟点击触发或捕获错误后重试按钮选到了但点不动按钮不可见或被遮挡判断可见性检查是否在弹层之下文本判断永远不匹配空白/换行干扰先压空白改用includes跨域iframe拿不到内容同源策略无法直接操作需从通信接口入手多标签页互相干扰全局变量/timer共享封装作用域给timer加退出条件这张表里的每一条我基本都真实踩过。特别是第一条早期我怎么都找不到原因后来才反应过来是浏览器对后台标签的定时器节流。搞清楚这点之后凡是需要长时运行的脚本我都尽量让它依赖页面事件而不是定时器。5.2 调试阶段该养成的习惯别一上来就写完整脚本。先在控制台里一行行敲document.querySelector(video)看看拿到的是不是想要的那个video.ended打印出来看状态nextBtn.offsetParent确认可见性。每一步都验证过再往函数里装。我见过太多人整段代码复制进去出了错完全不知道哪一步断了最后只能干瞪眼。还有个好习惯是把关键变量挂到window上方便反复调。比如window.__v document.querySelector(video)之后就能在控制台直接操作它测试各种属性不用每次重新选。调试完记得清理别留在正式代码里污染全局。5.3 几个容易被忽略的细节坑第一动态音源和参数变化。有些播放器把地址放在接口返回里脚本跑的时候地址可能变了或者带时效签名。这类页面你光盯着DOM没用得理解它的数据流。像“lxmusic音源js在线导入网址”这种场景本质是播放器要从一个外部配置动态加载音源属于数据驱动渲染处理思路是监听数据就绪事件而不是硬等某个元素。第二加载时机。脚本经常在页面还没渲染完就执行选不到元素。稳妥做法是监听DOMContentLoaded或者干脆用前面的observeFor等待目标出现。别裸奔一个setTimeout(fn, 5000)赌页面五秒内加载完网络差的时候必翻车。第三字符串与URL处理。判断地址有效性、提取参数这类活儿URL对象和includes比手写正则省心得多。比如new URL(str)能帮你校验格式是否合法抛异常就说明不合法这就是“js验证url有效性”最直接的实现比自己拼正则稳。6. 关于这类脚本的边界说说我的真实看法技术层面聊到这儿基本齐了但有些话我必须说透。这些年见过太多人拿着脚本去刷在线课程图的是省事结果往往是两头空课程内容一点没学考试的时候该不会还是不会平台一旦识别出异常行为轻则判无效重听重则影响成绩和诚信记录得不偿失。学习这件事没有捷径把时间花在研究自动化本身收获的是可以复用的编程能力把时间花在“怎么绕过去”收获的只有提心吊胆。那这套技术该用在哪儿我给你列几个我自己常用的正经方向。一是给团队内部的培训播放器写回归脚本每次版本更新自动跑一遍验证播放、切集、结束这些核心流程没坏。二是给自己的个人项目做压力测试模拟多个标签页长时间播放看内存和性能表现。三是练习把这些基础API串起来查询、事件、定时器、Promise、观察器这些就是你日后写任何前端功能的底层积木练熟了写业务代码都快一截。如果你正卡在某个具体的技术点上——比如iframe里的元素就是拿不到、事件派发了但监听没反应、轮询在后台就停——把具体的报错和页面结构发出来这些才是能真正帮上忙的地方。至于怎么把脚本套到学习平台上这个问题我没法给答案也建议你别在这上面花心思。真正值得投入的是搞明白页面为什么这么渲染、事件为什么这么传、状态为什么这么存把这几件事吃透你处理任何一个网页都会比别人快一步。