用Playwright打造合规的升学e网通学习辅助工具

升学e网通“速刷”到底是什么？用 Playwright 做一个合规的学习辅助工具

说实话，第一次听到“升学e网通速刷”这个说法时，我以为是某个脚本圈的暗语，点进去才发现，大量高中生、家长甚至老师都在找一种方法：能不能用工具自动完成平台上的课程学习、作业提交和测试刷题，把“在线学习”这件事变成后台的一个进度数字。

这个需求真实存在：平台上堆积了大量视频课、课后题、周测卷，学生每天能支配的时间本来就少，如果还要一门课一门课地点开、等待、翻页，确实很消耗耐心。但更值得警惕的是，网上流传的很多所谓“速刷脚本”，要么是盗号钓鱼，要么是内嵌了恶意代码，要么是通过模拟请求直接“打”平台接口。这些方式不仅违反平台用户协议，还很容易触发风控，导致账号被封禁，甚至被系统标记为“异常学习”，反而得不偿失。

这篇文章想换一个角度：不去讲那些灰色刷课脚本，而是从浏览器自动化的技术原理出发，用 Playwright 这个开源工具，拆解学习平台的页面结构、登录流程、课程加载逻辑和测试页面的交互方式。最终你会得到一个能用的“学习辅助工具原型”——它能帮你自动完成登录、打开课程、检查播放器是否正常加载、记录学习时长、打开测试页面并截图留档。它既可以当作日常学习辅助来用，也可以作为前端自动化测试的练习项目。

这是一个安全、合规、有技术含量的切入点，也正好能回应“升学e网通速刷测试”这个搜索词背后的真实需求：要快，但不该靠作弊，而是靠把重复操作自动化。

1. 这篇文章真正要解决的问题

在看具体代码之前，先想清楚一个问题：所谓“速刷”，本质上是想把哪些重复操作交给程序？

对一个学习平台来说，学生的主要操作路径并不复杂：登录账号，进入课程列表，点开某一节视频课，等待播放，偶尔回答弹题；然后进入作业区，打开测试卷，逐题作答并提交；最后去个人中心查看学习时长和得分记录。

这套流程里真正耗时的，不是“做题”本身，而是大量重复的页面切换、等待加载、点击跳转。如果你只是想高效完成学习任务，你需要的是一个能自动执行这些点击和等待的工具，而不是一个能“骗过系统”的作弊器。两者的技术底层都是浏览器自动化，但意图完全不同，安全性也完全不同。

本文要解决的问题有三个：

第一，帮你理解这类学习平台的网页端是如何工作的：登录状态靠什么维持、课程页面怎么加载、学习进度是怎么被记录的。了解这些，你才能判断哪些操作可以安全地用程序替代，哪些操作绝对不能碰。

第二，给你一套基于 Playwright 的完整代码示例，从登录态保存、课程列表巡检、播放器加载检查，到测试页面截图验证，全部跑通。这套代码的定位是“UI 自动化测试工具”，同样一套思路，可以用于公司内部系统的前端巡检，也可以用于个人学习记录管理。

第三，帮你建立一个安全边界。哪些行为会触发风控，为什么自动答题脚本很危险，为什么验证码不能碰，为什么不要用程序频繁请求接口。这些经验比一段能跑的脚本更有价值。

需要提前说明的是，本文演示的是通用浏览器自动化技术，页面元素选择器、接口地址、登录方式都需要以实际页面为准。我不会提供绕过验证码、破解加密参数、伪造学习记录的方法，这些内容既违反平台规则，也超出了技术分享的合理边界。

2. 浏览器自动化的核心概念与平台学习原理

很多人第一次看到 Playwright 的脚本时，会觉得这是“黑科技”：代码自己打开浏览器，自己输入账号密码，自己点击按钮，看起来像有个隐形人在操作。实际上，浏览器自动化的原理非常朴素——它只是把你在浏览器里做的每一次点击、输入、滚动，变成了可以用代码控制的操作指令。

Playwright 是由微软开源维护的浏览器自动化库，支持 Chromium、Firefox 和 WebKit 三大内核。和早期的 Selenium 相比，Playwright 的安装更简单，API 设计更现代，内置了自动等待机制，还能录制用户操作并生成代码，非常适合作页面巡检和自动化测试。

在动手写脚本之前，有几个概念必须先搞清楚，否则你会在定位元素和调试脚本时花掉大量时间。

第一个概念是“选择器”。浏览器页面上的每一个按钮、输入框、图片，都在 HTML 结构里对应一个节点。选择器就是用来定位这些节点的方式，常见的有 CSS 选择器（比如#username、.login-btn）和文本选择器（比如get_by_text("登录")）。例如，你要在登录页找到账号输入框，通常会这样做：

page.get_by_placeholder("请输入手机号").fill("13800138000")

这里get_by_placeholder就是根据输入框的占位提示文本来定位元素。如果页面结构稳定，这种文本定位方式往往比 CSS 选择器更可靠，因为开发人员很少会随意修改提示文案。

第二个概念是“自动等待”。网页加载不是瞬间完成的，尤其是视频页面和测试页面，会异步加载大量数据。如果你在脚本里写了“点击按钮后立刻查找下一个元素”，很可能因为页面还没渲染完成而报错。Playwright 内置了自动等待机制，操作元素之前会等待元素可见、可点击、稳定，这就是它比简单脚本更可靠的原因。

第三个概念是“会话保持”。你登录学习平台后，服务器会返回一个标识身份的凭证（通常是 Cookie 或 Token）。浏览器在后续每次请求中都会带上这个凭证，服务器才能识别你是谁。自动化脚本要连续操作多个页面，就必须管理好这个登录态。Playwright 提供了存储和恢复登录态的能力：第一次手动扫码登录，然后保存上下文；之后每次运行脚本直接恢复上下文，无需重复登录。

明白这三个概念，你就能理解整个自动化流程了。学习平台网页端的工作链路大致是：浏览器打开登录页，提交账号信息，服务器返回认证凭证并写入 Cookie，然后浏览器带着 Cookie 请求课程列表接口，拿到 JSON 数据后渲染课程卡片，点击某个课程后加载视频地址，播放器组件拉取视频流并开始播放，同时前端通过定时器向服务器上报学习进度。

这个链路里，哪一步适合自动化，哪一步不适合，是非常清晰的：

• 适合自动化：打开登录页、等待扫码、保存登录态、进入课程列表、点击进入某个课程、检查播放器是否加载、打开测试页面并截图。
• 不适合自动化：代替人工答题、伪造进度上报、绕过播放限制、批量请求接口。

理解了这条边界，接下来的代码你才能用对地方。

3. 环境准备与前置条件

这一节我们搭建一个最小可用的开发环境。考虑到学习平台的页面交互比较复杂，我推荐使用 Python 版本的 Playwright，再加一个简单的日志模块，方便观察程序运行状态。整体依赖只有两个：playwright和python-dotenv（用于读取配置文件）。

环境要求如下：

• 操作系统：Windows 10/11、macOS 或主流 Linux 发行版均可。
• Python 版本：3.9 或更高。版本请以当前 Playwright 官方要求为准。
• 浏览器内核：Chromium，Playwright 可以自动下载。
• 网络环境：能正常访问学习平台网页，无需任何特殊网络工具。

建议先创建一个独立的 Python 虚拟环境，避免依赖冲突。如果你还没装virtualenv或venv，可以直接用 Python 自带的venv模块。

# 进入你的工作目录 cd ewt-assistant # 创建虚拟环境（Windows） python -m venv venv venv\Scripts\activate # 创建虚拟环境（macOS / Linux） python3 -m venv venv source venv/bin/activate

激活虚拟环境后，安装 Playwright 和 python-dotenv：

pip install playwright python-dotenv

安装完成后，还需要下载 Playwright 默认使用的 Chromium 浏览器内核：

playwright install chromium

如果你的网络环境下载浏览器内核比较慢，可以换用系统里已有的 Chrome 或 Edge，然后在启动浏览器时指定可执行文件路径。例如：

browser = p.chromium.launch( channel="chrome", headless=False )

这种方式的好处是不需要额外下载浏览器，缺点是不同机器上浏览器路径可能不一致，跨机器运行时需要调整配置。

环境准备完成后，建议先用一个最简单的脚本验证 Playwright 是否能正常工作：

# 文件路径：quick_test.py from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch(headless=False) page = browser.new_page() page.goto("https://www.ewt360.com") print("页面标题：", page.title()) browser.close()

如果运行后能打印出平台首页的标题，说明环境没有问题。如果报错，优先检查浏览器内核是否下载成功，以及 Python 解释器是否指向了虚拟环境。

4. 登录与页面结构分析

登录是所有自动化操作的基础。如果你连登录态都拿不到，后续的课程列表、视频播放、测试页面全都无法访问。观察一个典型的学习平台登录页，通常包含手机号/账号输入框、密码输入框、登录按钮，部分情况下还会出现短信验证码或滑块验证。

这里要特别说明：验证码环节不能自动化绕过。滑块、点选等行为验证码存在的意义就是区分人和机器。如果你的脚本试图模拟滑块轨迹或者调用第三方打码平台，轻则被风控系统识别导致登录失败，重则账号被临时封禁。正确的方式是：第一次运行时，让脚本自动填写账号密码，然后由人工完成验证码环节；登录成功后保存登录态，下次运行直接恢复。

这听起来不够“全自动”，但它是所有合规自动化方案的标准做法。真正生产级的爬虫和测试框架，也都是这样处理登录态的。

下面是登录模块的完整代码：

# 文件路径：login.py from playwright.sync_api import Page def login_with_password(page: Page, username: str, password: str) -> None: """ 自动填写账号密码，并等待人工完成可能出现的验证码。 登录成功后页面会跳转到首页。 """ page.goto("https://www.ewt360.com", wait_until="domcontentloaded") # 打开登录弹窗 login_button = page.get_by_text("登录") if login_button.is_visible(): login_button.click() # 填入账号密码 username_input = page.get_by_placeholder("手机号") if not username_input.is_visible(): username_input = page.get_by_placeholder("账号") username_input.fill(username) password_input = page.get_by_placeholder("密码") password_input.fill(password) # 点击登录按钮 page.get_by_text("立即登录").click() # 等待人工处理验证码，最长等待 60 秒 page.wait_for_url("**/home**", timeout=60000)

这段代码有几个值得注意的细节：

第一，get_by_placeholder是一种文本定位方式，只要输入框的 placeholder 属性包含“手机号”或“账号”字样，就能命中。如果平台改了提示文案，你需要重新检查页面元素。

第二，wait_for_url会阻塞程序，直到页面跳转到包含/home的地址。如果你的平台登录后跳转到其他地址，需要相应调整。这种等待方式比单纯time.sleep(10)可靠得多，因为它是“等结果出现”，而不是“盲目等待固定秒数”。

第三，验证码环节没有出现在代码里，而是通过人工在浏览器窗口里完成。这也是为什么这里不能使用headless=True无头模式——无头模式下你看不到验证码，也就无法人工完成验证。

登录成功之后，登录凭证保存在浏览器上下文中。为了让后续运行免登录，我们需要把上下文保存到本地文件。

# 文件路径：storage_manager.py from pathlib import Path from playwright.sync_api import BrowserContext STORAGE_FILE = Path("auth_storage.json") def save_storage_state(context: BrowserContext) -> None: """保存登录状态到本地 JSON 文件。""" context.storage_state(path=str(STORAGE_FILE)) print(f"[提示] 登录态已保存至：{STORAGE_FILE}") def load_storage_state(browser) -> BrowserContext: """ 从本地文件恢复登录态。 如果文件不存在，则返回一个全新的上下文，需要手动登录。 """ if STORAGE_FILE.exists(): context = browser.new_context(storage_state=str(STORAGE_FILE)) print("[提示] 已恢复本地登录态") else: context = browser.new_context() print("[提示] 未找到登录态文件，需要手动登录") return context

这里用到了 Playwright 的storage_state机制。它会把当前上下文里的 Cookie、LocalStorage 等登录凭证序列化成 JSON 文件。下次启动浏览器时，通过new_context(storage_state=...)把凭证重新注入，浏览器就像完成了登录一样。

这套方案是业界标准做法，也被 Playwright 官方文档推荐。它不需要复制密码到本地文件，也不会泄露账号密码，安全性远高于把密码明文写死在脚本里。

5. 完整示例：课程列表巡检与播放器加载检查

登录态搞定之后，我们进入核心实战环节。这一部分会写三个相互独立的模块：课程列表巡检、视频播放页检查、测试页面截图验证。每个模块解决一个真实问题。

5.1 配置管理

先用一个简单的配置文件保存账号信息。注意，不要把一个真实的密码硬编码到代码里，而是通过环境变量读取。

创建.env文件：

# 文件路径：.env EWT_USERNAME=13800138000 EWT_PASSWORD=your_password_here EWT_HOME_URL=https://www.ewt360.com

再写一个config.py来加载配置：

# 文件路径：config.py import os from dotenv import load_dotenv load_dotenv() USERNAME = os.getenv("EWT_USERNAME", "") PASSWORD = os.getenv("EWT_PASSWORD", "") HOME_URL = os.getenv("EWT_HOME_URL", "https://www.ewt360.com")

5.2 课程列表巡检

课程列表页面的价值在于：你可以快速检查当前有多少门课程在学、哪些课程进度不足、哪些课程需要优先处理。一个自动化巡检脚本可以帮你生成一份“课程学习清单”，避免每次都要打开页面手动翻找。

# 文件路径：course_checker.py from playwright.sync_api import Page def get_course_list(page: Page) -> list: """ 在个人中心页面中提取课程名称列表。 选择器需要根据实际页面结构调整。 """ page.goto("https://www.ewt360.com/home", wait_until="domcontentloaded") page.wait_for_selector(".course-item", timeout=10000) courses = page.locator(".course-item").all() result = [] for idx, course in enumerate(courses, start=1): # 提取课程名称 name = course.locator(".course-name").inner_text() # 提取学习进度 progress = course.locator(".progress-text").inner_text() result.append({"序号": idx, "课程": name, "进度": progress}) return result

这里需要解释一下.course-item、.course-name这类类名是怎么来的。在实际项目中，你需要打开浏览器开发者工具（F12），在 Elements 面板里查看课程卡片的 HTML 结构，找到能唯一标识一个课程节点的 CSS 类名。不同平台的类名风格差异很大，所以在代码里注释里我特别强调“选择器需要根据实际页面结构调整”。

运行这个函数后，你会得到一个包含课程名称和进度的列表。把它打印到控制台，或者写入文本文件，就形成了一份简单的学习清单。

5.3 视频播放页检查

视频课程页面是整条学习链路中最复杂的一环。页面会异步加载视频地址、弹题、字幕等资源，如果某个资源加载失败，视频可能无法播放，学习进度也就不会增加。用自动化脚本做“播放器加载检查”，相当于给系统做了一次冒烟测试。

# 文件路径：player_checker.py from playwright.sync_api import Page def check_player(page: Page, course_url: str) -> dict: """ 进入指定课程页面，检查播放器是否正常加载。 不执行任何伪造进度的操作，仅做页面功能巡检。 """ page.goto(course_url, wait_until="domcontentloaded") # 等待播放器容器出现 page.wait_for_selector("video", timeout=15000) # 检查视频元素是否可见 video_visible = page.locator("video").is_visible() # 检查是否有播放按钮 play_btn = page.get_by_text("播放") play_btn_exists = play_btn.count() > 0 # 尝试点击播放按钮（如果未自动播放） if play_btn_exists and play_btn.is_visible(): play_btn.click() page.wait_for_timeout(3000) # 读取当前播放时间，验证视频是否真的在播 current_time = page.eval_on_selector("video", "el => el.currentTime") paused = page.eval_on_selector("video", "el => el.paused") return { "视频元素可见": video_visible, "存在播放按钮": play_btn_exists, "当前播放时间（秒）": current_time, "是否暂停状态": paused, }

这段代码的核心逻辑是：先检查video标签是否存在并可见，然后点击播放按钮，等待几秒后通过eval_on_selector读取视频元素的currentTime和paused属性。如果当前播放时间大于 0，且不是暂停状态，说明播放器工作正常。

这里完全没有伪造进度。播放器自然播放三秒钟，产生的进度是真实的学习行为，和人工手动点开视频看三秒没有区别。如果你想用它做“学习提醒”，可以扩展为：在每天定时打开当天要学的课程，播放器加载成功后就关闭，然后通过企业微信或钉钉机器人发送一条“今日课程已就绪”的通知。这是很好的学习辅助场景。

5.4 测试页面截图验证

很多学习平台会在课程结束后附带一套测试卷。如果你需要一个“每日测试入口巡检”，可以在程序里自动打开测试页面，检查页面是否正常渲染，并截图留档。这样即使你当天没有时间作答，也能确保系统没有出现白屏或接口报错。

# 文件路径：test_page_checker.py from playwright.sync_api import Page from pathlib import Path OUTPUT_DIR = Path("screenshots") OUTPUT_DIR.mkdir(exist_ok=True) def check_test_page(page: Page, test_url: str) -> str: """ 打开测试页面，检查页面主体是否渲染成功，并保存截图。 只做页面可用性检查，不参与任何自动答题。 """ page.goto(test_url, wait_until="domcontentloaded") # 判断页面是否加载出标题和题目区域 page.wait_for_selector(".question-content", timeout=10000) # 获取页面标题 title = page.title() # 统计题目数量 question_count = page.locator(".question-item").count() # 截图保存 timestamp = "test_page" screenshot_path = OUTPUT_DIR / f"{timestamp}.png" page.screenshot(path=str(screenshot_path), full_page=True) print(f"页面标题：{title}") print(f"题目数量：{question_count}") print(f"截图保存：{screenshot_path}") return str(screenshot_path)

为什么要截图？因为浏览器自动化跑完后，你不可能一直盯着控制台。截图是事后排查问题最有效的证据：如果页面加载异常，截图里会直接显示白屏或报错弹窗；如果题目数量不对，截图里也能看到漏掉了哪一块区域。

5.5 主入口脚本

最后，用一个主脚本把这几个模块串起来。

# 文件路径：run.py from playwright.sync_api import sync_playwright from config import USERNAME, PASSWORD from login import login_with_password from storage_manager import save_storage_state, load_storage_state from course_checker import get_course_list from player_checker import check_player from test_page_checker import check_test_page def main() -> None: with sync_playwright() as p: # 启动浏览器，使用有头模式以便观察验证码和页面状态 browser = p.chromium.launch(headless=False, slow_mo=100) context = load_storage_state(browser) page = context.new_page() # 检查是否已登录：尝试打开首页，看是否跳转到登录页 page.goto("https://www.ewt360.com", wait_until="domcontentloaded") if "login" in page.url: print("需要登录，开始自动填写账号密码，请留意验证码。") login_with_password(page, USERNAME, PASSWORD) save_storage_state(context) else: print("登录态有效，无需重复登录。") # 巡检课程列表 print("开始巡检课程列表...") courses = get_course_list(page) for c in courses: print(c) # 巡检第一个课程的播放器 if courses: first_course_url = "https://www.ewt360.com/course/example" print("开始检查播放器状态...") result = check_player(page, first_course_url) print(result) # 巡检测试页面 print("开始检查测试页面...") check_test_page(page, "https://www.ewt360.com/test/example") browser.close() print("所有巡检任务执行完成。") if __name__ == "__main__": main()

主脚本的执行逻辑很清晰：启动浏览器，恢复登录态，如果登录态失效则重新登录并保存，然后依次执行课程列表巡检、播放器检查、测试页面检查。整个过程没有超高频请求，没有伪造数据和绕过校验，属于正常浏览器操作，不会对平台服务器造成压力。

6. 运行结果与效果验证

运行主脚本后，预期你会看到类似下面的输出：

[提示] 已恢复本地登录态 登录态有效，无需重复登录。 开始巡检课程列表... {'序号': 1, '课程': '高一数学同步提高班', '进度': '已学 35%'} {'序号': 2, '课程': '高一语文阅读专项', '进度': '已学 12%'} 开始检查播放器状态... {'视频元素可见': True, '存在播放按钮': False, '当前播放时间（秒）': 12, '是否暂停状态': False} 开始检查测试页面... 页面标题：课后巩固测试 题目数量：10 截图保存：screenshots/test_page.png 所有巡检任务执行完成。

如何判断运行成功？

第一，登录态恢复成功，且没有跳转到登录页。如果脚本提示“需要登录”，说明本地存储的登录凭证已过期，需要重新走一次登录流程。

第二，课程列表能正确打印出课程名称和进度。如果打印出来的是空白列表，说明选择器没有匹配到课程节点，需要回到浏览器开发者工具检查.course-item类名是否真实存在。

第三，播放器检查结果中，“视频元素可见”为 True，且 “当前播放时间” 大于 0。如果视频元素不可见，可能是课程页面加载失败或该课程已下架；如果当前播放时间为 0，可能是视频资源未加载出来。

第四，测试页面截图文件生成成功，且图片中是正常的题目列表而不是白屏。这一步也是整个巡检流程的最终验证。

如果运行失败，优先看两件事：一是 Playwright 控制台中打印的异常信息，它会定位到具体是哪一行代码、哪一个选择器失败了；二是截图文件，它记录了页面在失败时刻的渲染状态。绝大多数自动化脚本问题都出在页面结构变化导致选择器失效，而不是程序逻辑本身有误。

7. 常见问题与排查思路

在写这类自动化脚本时，有几个问题几乎每个新手都会遇到。我把它们整理成一张排查表，方便你对照处理。

关于自动播放，这里展开说明一下。Chromium 默认会阻止带声音的视频自动播放，但如果页面本身就是在用户点击后加载视频，一般不会有问题。如果遇到currentTime不增加的情况，可以先调用一下浏览器的页面设置：

context = browser.new_context( permissions=["notifications"], reduced_motion="no-preference" )

或者在启动浏览器时加上参数：

browser = p.chromium.launch( headless=False, args=["--autoplay-policy=no-user-gesture-required"] )

这个参数表示允许无用户手势的自动播放，适合视频播放器自动化测试场景。

8. 最佳实践与工程建议

代码跑通只是第一步，真正让这个脚本长期稳定工作，还需要注意几个工程层面的问题。

8.1 账号安全与最小权限原则

不要用主账号跑自动化脚本，尤其不要在脚本里保存主账号密码。如果平台允许，建议使用一个独立子账号，即使账号被风控，损失也可控。更重要的是，不要在脚本日志里打印完整密码，也不要将auth_storage.json提交到 Git 仓库。建议在.gitignore中加入该文件：

# 文件路径：.gitignore auth_storage.json .env screenshots/

auth_storage.json本质上就是你的登录凭证，任何人拿到它都能直接登录你的账号。它的敏感程度和密码一样高。

8.2 行为频率控制

自动化的最大风险不是功能错误，而是请求频率异常。一个正常用户不会在 1 秒内连续点击 20 次页面，也不会在 10 秒内打开 15 个不同页面。如果你的脚本跑得太快，风控系统的规则引擎会很容易识别出“异常行为”。

在 Playwright 中，你可以在启动浏览器时加一个slow_mo参数：

browser = p.chromium.launch(headless=False, slow_mo=300)

slow_mo=300表示每个操作之间至少间隔 300 毫秒，视觉上更接近真人操作速度。另外，程序的循环中还可以加入随机等待：

import random import time time.sleep(random.uniform(1, 3))

这个 1 到 3 秒的随机停顿基本模拟了真人阅读页面的节奏，能显著降低被识别的可能性。

8.3 日志与截图

项目一旦跑起来，你不可能每次都盯着控制台。建议把所有关键步骤写入日志文件，并保留每次巡检的截图。日志不仅用于事后追溯，还能帮助你发现页面结构的渐进式变化。比如某一天课程列表突然打印为空，你翻出前一天的日志，对比截图，就能迅速判断是网络问题还是页面改版。

8.4 保持脚本的可修改性

学习平台的页面结构会定期更新，没有哪个选择器能永久有效。写代码时，把所有页面选择器集中到一个常量文件里，方便统一修改。

# 文件路径：selectors.py # 集中管理页面元素选择器，方便平台改版后一次性修改 COURSE_ITEM = ".course-item" COURSE_NAME = ".course-name" COURSE_PROGRESS = ".progress-text" PLAY_BTN_TEXT = "播放" QUESTION_CONTENT = ".question-content" QUESTION_ITEM = ".question-item"

这样做的收益很明显：如果平台把.course-item改成了.course-card，你只需要修改selectors.py里的一行代码，而不是在所有文件里搜索替换类名。

8.5 不要碰的自动化边界

最后是几条必须遵守的底线：

第一，不要伪造学习进度。学习进度的上报通常在后端验证，前端伪造的数据会被识别为异常记录。即使你想在脚本里做这件事，技术上也不安全，因为你不了解服务端的校验逻辑。

第二，不要自动作答测试题。测试的目的是评估学习效果，自动答题不仅违反规则，而且对你的学习没有任何帮助。那个“正确答案”就算拿到了，也是虚假的好看数据。

第三，不要尝试绕过验证码。验证码是平台的合法防火墙，绕过它属于破坏别人系统的安全措施，无论从平台规则还是从法律角度，都存在明确风险。正确的自动化流程是保留人工验证步骤。

第四，不要高频抓取平台接口。本文的脚本只做页面操作，不做接口请求，这是刻意为之。接口请求频率过高会被风控系统标记，轻则限流，重则封禁。

9. 总结与后续学习方向

现在回到最初的问题：升学e网通“速刷”到底应该怎么做？

我的回答是：不要去找那些一键刷课、自动答题的灰色脚本，也不要用它来伪造学习记录。但浏览器自动化本身是一项通用且安全的技术能力，你完全可以用它来做一个合规的学习辅助工具——自动登录、巡检课程列表、检查播放器状态、自动打开测试页并截图，把重复的页面操作交给程序，把学习时间还给真正需要思考的题目。

这篇文章的核心内容有三个。

第一，拆解了学习平台网页端的操作链路：登录态如何保存、课程页面如何加载、播放器如何工作、测试页如何渲染。这个分析能力对任何 Web 自动化项目都通用。

第二，给出了一个完整的 Playwright 项目示例，从登录态保存到课程列表巡检，再到播放器检查和测试页截图，代码可以直接复制、修改、运行。这套代码既是你自己的学习辅助工具，也是一个很好的前端自动化测试练习项目。

第三，强调了自动化操作的安全边界：什么能自动化、什么不能自动化、为什么不能。这些经验在真实项目里比代码更值钱。

如果你的下一步想继续深入，建议从这几个方向入手：学习 Playwright 官方文档中关于网络拦截和请求模拟的部分，了解如何在测试框架中拦截图片、字体等静态资源以提升测试速度；研究 pytest-playwright 插件，把脚本改造成带测试报告的标准自动化测试项目；学习使用定时任务（Linux cron 或 Windows 任务计划）让巡检脚本每天自动运行一次，并结合企业微信或钉钉机器人把巡检结果推送到手机上。

到这里，这个项目的技术部分就讲完了。剩下的问题是你准备怎么用这套能力：是老老实实把学习节奏管起来，还是继续寻找“跳过思考”的捷径。技术能帮你节省重复操作的时间，但学习和成长这件事，终究没有捷径。