1. 先把话说清楚这类脚本我不写原因不止一个后台收到不少私信问的都是同一件事有没有那种挂上就能自动把在线课程的视频刷完、进度条自己往前跑的脚本。提问的人往往还会补一句“就用一次”“反正视频我也不看”“别人都在用”。每次看到这类需求我的第一反应都不是技术上能不能做而是这件事从根上就不成立。技术上它当然做得到浏览器自动化发展了这么多年模拟点击、注入事件、劫持定时器没有一样是新鲜东西。但“做得到”和“该不该做”之间隔着一条很宽的沟这条沟不是道德洁癖而是实实在在的风险和成本核算。我把话放在前面这篇文字不会给出任何绕过课程播放、伪造学习时长的方案也不会教你怎样让脚本代替你完成考核环节。原因很直接平台的学习时长统计、观看行为校验、异常流量识别这几年做得越来越细一个本地脚本想在长时间运行中完全不露痕迹概率低得可怜。一旦被判定为异常学习行为轻则该门课程成绩清零重来重则影响整个学期的学分认定为了省下十几个小时去赌这个结果账怎么算都不划算。更别说脚本本身要拿到你的登录态账号密码交给一个来路不明的程序这个风险比挂科严重得多。那这篇还写不写写。因为“用自动化工具解放学习时间”这个诉求本身是有价值的只是绝大多数人把它用错了地方。真正消耗我们时间的往往不是那几节必须看的课而是散落在各个平台上的重复动作每天翻五六个页面确认有没有新通知、手动整理课程表和时间节点、把分散的资料复制到一个地方做归档、反复核对哪门课的作业还没交。这些动作单个只要一两分钟累积起来一周能吃掉好几个小时而且完全不产生任何学习价值。把这些交给脚本才是自动化真正该发力的地方。所以这里实际要谈的是如果你确实想用脚本管理自己的在线学习流程技术上需要哪些准备、会遇到哪些坑、边界在哪里。写作对象是那些有一点编程基础、想动手做点小工具的同学也适合完全不懂代码但想搞明白“为什么这类脚本总是不靠谱”的读者。看完你至少能判断网上那些卖脚本的人到底在卖什么以及为什么他们承诺的“稳定运行”大概率撑不过两周。还有一点必须提前说明。下面所有关于页面结构、自动化框架、稳定性处理的讨论都只在你自己拥有合法访问权限、且平台服务条款允许的范围内成立。服务条款通常写得很明确禁止使用任何自动化程序访问、干扰正常服务。这不是一句摆设账号被封的时候它是唯一的依据。你要做的第一件事是去把那份你注册时点过“同意”的文档翻出来读一遍而不是先去找脚本。1.1 一个看似省事的需求背后压着三重成本很多人算这笔账的时候只看到收益省时间。但成本是分层的而且大部分成本不会立刻显现等到显现的时候已经来不及补救。第一层是账号安全成本。市面上流传的所谓成品脚本绝大多数需要你提供账号密码或者要求你在浏览器里装一个来源不明的扩展。它拿到了你的登录凭证之后做什么你完全无法审计。有的人会说“我用小号试过没问题”可问题恰恰在于这类程序往往不会立刻发作它可能安静地跑几个月把你当成一个正常的样本然后在某个时间点集中处理。你无法证明它做了什么也无法追溯。第二层是学习记录的可信度成本。在线课程平台判断学习行为是否真实早就不止看进度条了。播放器会以固定间隔向服务端发心跳记录当前播放位置、窗口是否在前台、有没有快进操作、单次停留时长分布是否符合正常人的观看曲线。一个脚本为了让进度跑完往往会把整个视频在几十秒内“看完”这个数据分布和真人差异极大属于最容易被规则命中的模式。有些平台还会在视频中间插入交互确认脚本处理不了就直接卡死进度反而比手动看更慢。第三层是时间与机会成本。这里有个很反直觉的现象写脚本省下的时间经常小于调试脚本消耗的时间。一个能稳定跑完一整个学期课程的脚本需要处理登录态过期、页面改版、网络抖动、弹窗干扰、验证码触发等一系列问题任何一个环节变动都会让整个流程崩掉。你以为自己是在省时间实际上是在给自己开一个需要长期维护的副业。我见过太多人脚本写了两周最后还是要手动补完两头都没落下好。1.2 自动化技术本身没问题问题永远出在用法上把话说回来浏览器自动化是一项非常正经的技术测试工程师每天都在用它。回归测试、UI 自动化、数据采集、批量表单填写这些都是它最擅长的事情也是它真正创造价值的地方。区别在于测试环境是你自己的系统你对它拥有完全的控制权跑崩了大不了重来而线上课程平台是别人的系统你只是使用者擅自用程序去驱动它等于把别人家的门锁当成自己家的练习道具。我自己的判断标准很简单这件事如果被平台方知道了我会不会觉得需要解释。整理自己的课程通知、把邮件里的作业截止时间汇总成一个日历、把下载下来的课件按课程重命名归档这些都属于个人资料管理平台不会介意而让程序代替我产生“已学习”的记录本质上是在伪造一份平台用来评估我的数据这个没什么可辩解的。所以下文的重点会放在前者怎么把自动化用在管理自己的信息上怎么设计一个不会半夜挂掉的脚本怎么在页面改版的时候快速定位问题。这些技能是通用的学会了之后你去写任何流程自动化都用得上而不是只能对付某一个特定页面。2. 先搞懂页面在线课程平台到底是怎么运转的写自动化脚本第一件事永远不是打开代码编辑器而是打开开发者工具。绝大多数脚本失败原因不是代码写错了而是写代码的人根本没搞清楚页面在干什么。在线课程平台属于典型的“前后端分离 多媒体播放”结构一层是 DOM一层是网络请求二者之间存在大量你不知道的交互。不了解这些交互你写的选择器就是碰运气。2.1 播放器、进度上报与心跳机制课程播放页的核心是一个视频元素或者一个封装过的播放器组件。表面上看进度条在动实际上背后有三套东西在同时运行媒体解码负责画面播放器逻辑负责响应你点击暂停、拖拽而进度上报模块负责定时把“我看到哪了”告诉服务端。第三套才是平台真正关心的部分也是最容易被忽视的部分。进度的上报通常有两种形式。一种是定时轮询播放器每隔一段时间常见的是十几秒到一分钟发一次请求带上课程 ID、当前播放位置、本次观看时长等字段另一种是事件驱动在你暂停、切页、关闭窗口的时候触发上报。很多平台是两者混用轮询保证连续性事件保证边界准确。这意味着如果你的脚本只是让视频元素处于播放状态但页面被切到了后台浏览器会对不可见标签页的定时器做节流轮询间隔被拉长服务端收到的数据就会出现空洞进度反而对不上。还有一个容易被忽略的点心跳请求里往往带有时长校验。比如两次上报之间你声称看了 60 秒但服务端记录的间隔只有 3 秒这个矛盾就会触发异常标记。脚本想要“快进”就必须同时伪装时间而时间戳这类字段通常在服务端做二次校验本地改不了。这就是为什么很多号称“秒刷”的脚本跑完之后进度显示 100%成绩却是零。我在实际排查这类问题时第一步永远是打开网络面板把播放页完整看五分钟把所有的 XHR 请求录下来然后逐条看请求体。哪些字段是变化的、变化规律是什么、有没有签名参数、请求头里有没有特殊标识这些信息比任何教程都有价值。这一步花二十分钟后面能少走半个月的弯路。2.2 为什么模拟点击经常莫名其妙失灵新手写脚本最常见的写法是找到元素调用点击然后祈祷。跑两次成功就觉得搞定了第三次就报错说元素不存在。这类问题有个统一的名称叫“时序问题”但具体原因至少有五种得分开看。第一种是元素还没渲染出来。现代前端框架大多是异步渲染你看到页面上有按钮不代表 DOM 里已经有那个节点。脚本执行速度远快于人类很容易在节点挂载之前就去查询自然查不到。第二种是元素存在但不可交互比如被一个透明的遮罩层盖住或者样式上是display:none但依然能被选择器命中这时候点击会报“元素不可见”。第三种是元素被复用了同一个容器在切换课程时只更新内容不重建节点你缓存的元素引用指向的其实已经是另一门课的数据。第四种是框架用了事件委托真实的点击处理挂在祖先节点上你直接派发事件到子节点事件没有冒泡路径监听器收不到。第五种最隐蔽是页面处于 iframe 里你的选择器在顶层文档里怎么找都找不到。应对办法不是背一堆等待时间而是建立一个稳定的等待策略等到元素可见、等到元素可点击、等到某个业务状态出现。前端自动化框架都提供了这类条件等待用它比自己写sleep靠谱得多。sleep的问题在于它是个固定值网络好的时候浪费网络差的时候不够永远在两头不讨好。2.3 登录态、Cookie 与那些说不清的过期规则自动化脚本跑不长久的第二大原因是登录态管理。你本地调试的时候一切正常因为浏览器里存着之前手动登录留下的 Cookie脚本部署到别处跑第一次请求就是 401。更麻烦的是很多平台的登录态并不是单纯的 Cookie还叠加了本地存储里的令牌、请求头里的签名、甚至设备指纹。我的一般做法是不自己去模拟登录流程而是让脚本复用已有的浏览器用户目录。这样登录态、缓存、扩展配置全都继承过来省掉大量麻烦。缺点是这份目录不能随便提交到代码仓库也不能跨机器复制得在每台机器上手动登录一次。这个代价是值得的因为模拟登录要处理验证码、滑块、短信验证每一项都是无底洞。登录态过期这件事也得提前设计。短则几小时长则几周取决于平台策略。脚本必须能识别“过期”这个状态并且在过期时停下来通知你而不是继续跑、继续报错、把日志刷满。我见过最糟糕的实现是登录失效之后脚本还在疯狂重试一分钟发两百个请求最后账号被风控锁定这个结果比不做自动化还糟。3. 技术栈怎么选三条路线的取舍真正动手之前得先选工具。浏览器自动化这块主流的方案有三类各自适合的场景差别很大。选错了不是不能用而是要花大量时间在补短板上投入产出比很难看。3.1 三种主流方案的能力边界第一类是传统 WebDriver 系代表是 Selenium。它的优势是生态成熟、语言绑定全、社区资料多你遇到的绝大多数问题都能搜到答案。劣势是它通过驱动进程和浏览器通信速度偏慢而且对某些现代浏览器特性的支持有滞后。如果你要跑的是简单的表单填写、页面跳转、元素提取它完全够用学习成本也最低。第二类是新一代自动化框架代表是 Playwright 和 Puppeteer 这一系。它们直接走浏览器调试协议速度快内置了自动等待、网络拦截、多标签页管理这些能力写起来顺手的多。尤其是自动等待它把“等元素出现”这件事变成了默认行为省掉大量显式等待代码。代价是它们对浏览器的版本有绑定关系需要下载配套的浏览器二进制部署时多一步。第三类是直接操作调试协议自己发命令。灵活度最高什么都能控制但也什么都要自己写。除非你在做需要精细控制网络层的工具否则不建议从这条路开始调试成本太高。还有一类经常被提到的方案是请求重放抓一次请求用代码把同样的请求再发一遍。它速度快、资源占用低但对参数签名、时间戳、加密字段毫无抵抗力一旦平台加了校验就全线失效。而且这种方式完全绕开了页面等于放弃了所有前端校验提供的容错出错时你连问题出在哪都看不出来。我个人只在纯数据读取、且确认接口稳定的时候才会用。方案上手难度运行速度抗页面改版能力适用场景WebDriver 系低中中简单流程、老项目维护新一代自动化框架中快中高多数个人自动化需求直接操作调试协议高快低需要控制网络层的场景请求重放低极快极低稳定只读接口的数据获取3.2 一个最小可用的本地环境环境搭建这件事能简单就别复杂。我推荐的组合是Python 3.10 以上、一个主流自动化框架、外加一个独立的浏览器用户目录。不装虚拟环境也行但装了之后升级依赖不会污染系统环境出问题直接删掉重建心理负担小很多。python -m venv venv source venv/bin/activate pip install playwright playwright install chromium三行命令装完就能用。最后一行会下载配套的浏览器这一步在国内网络环境下可能会慢耐心等或者换镜像源。装完之后先跑一个最小验证脚本确认能打开页面、能读到标题、能截图再往下写业务逻辑。这一步千万别跳过我见过太多人上来就写几百行跑起来报错分不清是环境问题还是代码问题白白浪费一晚上。from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessFalse) context browser.new_context() page context.new_page() page.goto(https://example.com) print(page.title()) page.screenshot(pathcheck.png) browser.close()headlessFalse这个参数建议在开发阶段一直开着能亲眼看到脚本在做什么比看日志快十倍。等逻辑稳定了再切成无头模式部署到后台运行。注意不要用脚本去反复注册或登录新账号来绕过限制这类行为在平台侧的特征极其明显且涉及的问题远超技术范畴。4. 一个能长期跑的脚本该怎么设计写脚本和写一次性小工具最大的区别在于一次性工具只要跑通一次就算成功长期运行的脚本要考虑三个月后页面改版了怎么办、网络断了怎么办、跑了一半崩溃了怎么办。这部分内容才是自动化的真正门槛也是最值得花时间的地方。4.1 把任务拆成清单而不是写成一串命令新手最常见的写法是从上到下一路写下来打开页面、点登录、找课程、点播放、等结束、关浏览器。这种线性结构在顺利的时候没问题一旦中间某一步出错整个脚本就断了而且你很难知道断在哪、断之前做到哪了。更靠谱的做法是把每个动作抽象成一个任务任务之间有明确的前置条件和产出。比如“拉取今日课程公告”是一个任务它的产出是一个结构化列表“把公告里的截止时间写入日历”是另一个任务它的输入是上一步的产出。这样拆开之后每个任务可以单独测试、单独重跑失败的时候也只影响自己那一段。拆任务的时候有个很实用的原则每个任务的执行时间控制在几十秒以内。太长的任务失败代价高太短的任务调度开销大。按这个粒度切通常一个完整的日常流程能拆成五到十个任务跑一遍一两分钟出问题一眼能看出是哪一环。4.2 断点续跑让脚本崩了也不用从头再来长期运行的脚本一定要有状态记录。最简单的实现是用一个本地文件记下“哪些任务今天已完成”脚本启动时先读这个文件已完成的任务直接跳过。这个文件不需要多复杂一个 JSON 就够。{ date: 2025-03-14, done: [fetch_announcements, sync_calendar], failed: [{task: export_notes, reason: timeout}] }有了这个脚本半夜挂掉之后第二天早上重跑只补做失败的那部分不用把所有事情重新做一遍。这个小机制看着不起眼实际用起来能省掉大量重复劳动尤其是在流程比较长、中途容易被打断的场景下。状态文件还有第二个作用可观测。你打开文件就知道昨天哪些任务成功了、哪些失败了、失败原因是什么。比翻日志快得多也不需要任何额外的监控系统。4.3 日志该怎么记才有用日志这件事很多人要么不记要么记一堆没用的。我的经验是日志里必须有四样东西时间戳、任务名、当前步骤、结果。有这四样出问题的时候能快速定位到是哪一步、什么时候开始的。至于调试信息用日志级别控制平时只输出 INFO 以上排查问题时临时开到 DEBUG。另一个实用技巧是失败时自动截图。页面上的问题一张图胜过一百行日志。元素找不到、点击没反应、弹窗挡住了这些情况截图一看就明白。截图文件按时间和任务名命名保留最近若干张自动清理旧的不然硬盘很快就被塞满。def safe_run(page, task_name, func): try: func(page) logger.info(f{task_name} ok) return True except Exception as e: shot ffail_{task_name}_{int(time.time())}.png page.screenshot(pathshot, full_pageTrue) logger.error(f{task_name} failed: {e}, screenshot{shot}) return False这段代码的价值不在于它有多聪明而在于它把“出错”变成了一件可控的事。脚本不可能不出错但出错之后能不能快速知道原因直接决定了你还有没有耐心继续维护它。5. 稳定性实战那些让脚本半夜挂掉的坑理论说完了说点具体的。下面这些都是我在实际项目里反复遇到的每一条背后都有过至少一次通宵排查。5.1 元素定位失效的四种典型场景第一种是列表页的分页结构。你写的选择器取的是“第一页的第一个条目”但脚本跑的时候页面默认停在别的页码取到的数据就错了。解决办法是先读当前页码再决定要不要翻页别假设页面初始状态。第二种是动态生成的 ID。很多前端框架会给元素生成随机的 ID比如el-id-2345-67这次是 67刷新一次变成 89。用这种 ID 做选择器第一次能跑第二次就废。正确的做法是用稳定的属性定位比如文本内容、>import time, random def retry(func, times3, base2): for i in range(times): try: return func() except Exception as e: if i times - 1: raise wait base ** i random.uniform(0, 1) time.sleep(wait)加一个随机抖动是有意义的多个任务同时失败的时候避免它们在同一秒集体重试把请求打成脉冲。这个细节在单机跑的时候感觉不到一旦任务数量上来就很明显。超时时间也要分开设。页面加载的超时可以给长一点三十秒单个元素等待给十秒左右网络请求给十五秒。全用一个值要么太短误判要么太长卡死。我一开始图省事全设成三十秒结果某个接口挂住的时候脚本愣是等了半小时才发现不对劲。5.3 常见问题速查表下面这张表是我自己整理的遇到问题时先对着扫一遍能解决八成的情况。症状排查顺序一启动就退出检查解释器路径、依赖是否装全、日志目录是否可写能打开页面但读不到内容确认是否在 iframe 内、是否被重定向到登录页昨天能跑今天不行优先怀疑页面改版重新抓一次选择器偶尔成功偶尔失败时序问题把所有sleep换成条件等待跑一段时间后全挂登录态过期或触发风控需要人工介入内存持续上涨页面对象没释放检查是否在循环里不断新建上下文日志里全是超时网络问题或目标站点限流降低频率并加退避提示任何一次“偶发失败”都值得记录。因为偶发积累到一定次数就不再偶发而是某种稳定规律的暴露早发现能省掉后面的大麻烦。6. 把自动化用在真正值得的地方聊了这么多技术细节最后回到那个最初的问题怎么才能真正省下时间。我的答案可能让人失望省时间的从来不是脚本本身而是你把流程想清楚这件事。写脚本的过程本质上是强迫自己把一件模糊的事情拆解成明确步骤拆完之后你会发现有一半的步骤其实压根不需要做。6.1 先做减法再做自动化我见过最典型的浪费是把一堆本来就没必要的事情自动化了。比如每天定时去五个平台挨个看有没有新通知这件事本身就是低效的因为它假设了你必须主动去轮询。更好的做法是把通知统一收到一个地方邮件、日历、待办清单哪个顺眼用哪个然后只在那个地方看。这不是技术问题是习惯问题但省下的时间比写脚本多得多。再比如整理课程资料。有的人写脚本自动下载、自动重命名、自动分类写了三百行。实际上如果一开始就在保存的时候按统一规则命名后续根本不用整理。自动化应该用在那些无法通过改变习惯消除的重复劳动上而不是用来补救糟糕的初始习惯。我自己现在的做法是每周花二十分钟做一次回顾把下周要交的东西、要看的材料列出来扔进日历。这件事手动做因为只有二十分钟而且做的过程本身就是一次梳理比任何自动提醒都有效。真正交给脚本的是那些机械的、不需要思考的搬运工作比如把邮件里的附件按课程归档、把每周的日程导出成一份汇总。这些工作做起来枯燥交给程序正合适。6.2 值得自动化的三类事情第一类是信息聚合。散落在多个来源的内容需要你反复去翻、去比对、去复制。这类事情最适合自动化因为规则清晰、结果可验证、出错成本低。写一个脚本把几个页面的关键信息抓下来输出成一份结构化文件每天早上看一眼比挨个点开快得多。第二类是格式转换。下载下来的材料命名混乱、格式各异需要统一整理。这类事情手动做很烦写脚本很简单而且跑一次能管很久。关键在于规则要定得足够简单不要搞出十几条 if-else那样维护成本比手动还高。第三类是定时提醒和检查。某些页面需要定期确认状态比如有没有新的作业发布、某个流程有没有推进。这类事情可以写成定时任务每天早上跑一次有变化就通知你。注意频率别设太高一天一次足够了五分钟跑一次纯属给自己找麻烦。至于那些需要判断、需要理解、需要临场应变的部分别碰自动化。课程内容要自己看作业要自己想这些是学习的本体交给程序就本末倒置了。自动化能帮你腾出时间但腾出来的时间用来干什么那才是真正决定结果的地方。我踩过的最大一个坑是把大量精力花在打磨一个“完美脚本”上为了让成功率从 90% 提到 95%反复调试了两个周末。后来算了一下账这两个周末手动做那些事总共也就花两个小时。所谓的自动化收益全被维护成本吃掉了。从那之后我给自己定了个规矩一个自动化工具的开发时间不能超过它一年内能省下的手动时间的十分之一。按这个标准绝大部分想法在动手之前就该被否掉留下来的才是真正划算的。延伸出去这类技能的价值不在某一个具体场景而在于你建立起了一套“识别重复劳动、评估自动化收益、设计可维护流程”的思维方式。换一个领域换一套工具这套思路照样成立。