很多人第一次听到“Python模拟登录教务网”这八个字时第一反应往往是“这是不是搞爬虫破解啊”。坦率讲我大学那会儿也是这么想的直到真被期末查成绩这件事逼到墙角才认真把这条链路从头到尾走了一遍做出来的东西后来帮我省了不少事。这篇就以某高校教务网为例完整复盘一次“Python模拟登录教务网”的实现过程从抓包、还原请求到用requests保持会话、登录、抓成绩再到那些不跑一遍绝对发现不了的坑。无论你手上是什么系统、什么学校只要登录入口还是“网页表单提交”这一套核心逻辑基本都是相通的。这篇文章适合两类人一种是刚开始学Python、想找个真实项目练手的同学另一种是每天要手动进教务系统查成绩、查课表想省点力气的同学。看完你至少能自己写出一个能用的登录脚本而不是停留在“看懂了但不会跑”的状态。1. 登录教务网这件事本质上就是一次带Cookie的表单提交1.1 从“浏览器帮你做的事”说起我们平时在教务系统里登录感觉就是填个账号密码、输入验证码、点一下登录按钮。但浏览器在背后做的事情其实有固定的一整套流程先向服务器要登录页拿到页面内容和临时凭证再向验证码接口要一张图片然后把账号、密码、验证码连同一些隐藏在页面里的字段一起提交最后跟着服务器返回的跳转指令进入系统主页。计算机里这叫“HTTP无状态”问题。服务器默认记不住你它需要通过一个叫Cookie的小型标识来识别“你是谁、你是否已经登录”。所以“模拟登录”说白了就是三件事复现请求顺序、保持同一个会话、提交正确字段。签名、加密、验证码都只是这中间多出来的绊脚石。我用一个生活里的类比教务系统的服务器就像一个封闭小区你第一次进门要登记姓名、房号还要跟保安对个暗号验证码。登记成功后保安给你一张临时门禁卡Cookie你后面进出任何一栋楼都得带着这张卡。物业工作人员看到卡就知道“这是登记的住户”不用每进一栋楼重新登记一遍。Python模拟登录要做的就是写一个脚本替你把“登记”这件事干了然后把“门禁卡”收好后面查成绩、看课表、查考勤时自动带着它去请求。1.2 表单里的隐藏字段和会话标识很多高校教务系统是国内常见的ASP.NET架构登录表单除了用户名、密码、验证码以外还会带着__VIEWSTATE、__EVENTVALIDATION这类隐藏字段。新手第一次看抓包数据时经常懵明明页面上没看见这些输入框怎么提交时多出来一堆参数这两个字段属于ASP.NET的页面状态机制。__VIEWSTATE保存的是页面控件的状态__EVENTVALIDATION用来校验这个POST请求是不是从当前页面正常发出来的。服务器拿到POST请求后会校验这些字段的有效性如果缺失或过期它会直接拒绝回发表现为“页面过期”或“验证失败”。因为这类字段是动态生成的同一个Session里每次打开页面可能都不一样所以模拟登录的第一步必须先去登录页面“抓”一份最新的隐藏字段再和其他参数一起提交。这步顺序反了后面怎么调都是白费功夫。另外教务系统普遍用“Session”来管理登录状态。客户端这边表现为Cookie中的一个SessionId服务端则存着一份对应的会话数据。简单说你必须用同一个请求会话在requests里就是一个Session对象去完成“拿页面—取验证码—提交登录—访问成绩页”整条链路。很多人模拟登录失败根本原因就是每次请求都新建了连接导致Cookie对不上号。2. 开发者工具里还原登录该看哪些请求、该抄哪些字段2.1 抓包前先让浏览器“交代”全部动作真正动手写代码前我会花半小时把浏览器开发者工具打开手动登录一次完全看清网页到底给服务器发了什么。这一步是整篇文章最枯燥但也最值钱的部分。操作步骤如下打开Chrome按F12进入开发者工具切到Network面板勾选Preserve log保留日志。这个选项很重要因为登录成功后会有一个302跳转如果不勾选跳转前的请求信息会被清掉你就看不到POST表单了。然后地址栏输入教务网登录地址此时Network面板里会出现首个页面请求。清空面板手动输入账号密码验证码点击登录。全程观察新增的网络请求。我一般会重点抓四个请求打开登录页的GET请求拿到HTML页面Set-Cookie里能看到SessionId。验证码图片的GET请求拿到验证码图片别忘了看它的URL和请求头。点击登录后的POST请求这是最核心的所有表单字段都在这里。登录成功后的页面跳转确认最终落地地址服务器用什么方式告诉你“登录成功”。看到这四条你的抓包任务就完成了。不要急着看那些JS文件、CSS文件绝大多数跟登录逻辑没关系。2.2 登录请求里的字段清单和它们的来历以我手头这个ASP.NET架构的教务系统为例POST请求的Form Data大致长这样字段名类型作用__VIEWSTATE隐藏字段页面状态从登录页HTML里提取__EVENTVALIDATION隐藏字段回发校验从登录页HTML里提取txtUserName文本框学号/工号txtPassword文本框密码txtCaptcha文本框验证码btnLogin按钮登录按钮的value值可能为“登录”当你发现自己的系统字段名不一样时别慌字段名只是表象。你需要关注的是“哪些字段在页面上看得到、哪些藏在HTML里、哪些是固定常量”。把这三个问题弄清楚你就掌握了这套系统的登录格式。如果你遇到的是前后端分离的新系统登录接口可能不是表单POST而是fetch或ajax发送的一段JSON比如{username:...,password:...}。原理一样只是Content-Type不同、参数形式不同。开发者工具里看Payload一栏就能明明白白分辨出来。我在实际抓包时还养成了一个习惯在Network面板里右键点击那个登录POST请求CopyCopy as cURL。然后在命令行里执行这条cURL看返回值是否和浏览器登录结果一致。如果一致说明你已经拿到了“浏览器帮你拼好的请求”如果不一致大多是Cookie或Header缺失先补上再继续。这个小技巧能帮你少走很多弯路。3. requests会话登录验证码、隐藏字段、302跳转一次跑通3.1 先搭一个session再谈后续请求用Python写模拟登录我建议直接使用requests库。它是Python生态里最顺手的HTTP客户端简洁、直观自带Session支持。安装方式不赘述pip install requests即可。额外用到BeautifulSoup和lxml做HTML解析提前装好。代码的第一步永远是创建一个Session对象。所有请求都用这个Session发出requests会自动帮你保存Cookie模拟浏览器的“门禁卡”逻辑。同时我给Session设置默认的请求头至少带上User-Agent否则部分服务器会直接拒绝陌生客户端访问。import requests from bs4 import BeautifulSoup # 创建会话Requests会自动帮我们保存Cookie session requests.Session() session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0 Safari/537.36, Accept-Language: zh-CN,zh;q0.9, })接着模拟浏览器打开登录页。这一跳的作用有两个一是获取页面HTML提取隐藏字段二是让服务器把SessionId种到Cookie里后面的验证码请求、登录POST都要用这个会话身份。login_page_url https://jw.example.edu.cn/default.aspx resp session.get(login_page_url, timeout10) resp.encoding resp.apparent_encoding # 教务系统常见GBK/GB2312用自动探测更稳 html_text resp.text判断页面是否获取成功不要只看状态码是不是200最好检查HTML里有没有出现登录表单的关键字样比如“用户名”“验证码”。有些系统即使返回200也可能是跳转到了错误页。3.2 提取隐藏字段ASP.NET系统的隐藏字段通常在input typehidden标签里。用BeautifulSoup解析非常方便。soup BeautifulSoup(html_text, lxml) viewstate soup.find(input, {name: __VIEWSTATE})[value] eventvalidation soup.find(input, {name: __EVENTVALIDATION})[value] print(已获取 __VIEWSTATE:, viewstate[:50], ...)如果某个字段在你这个系统里不存在就用None代替不用强行赋空字符串。另外提醒一点每次新建会话打开登录页都要重新提取一次隐藏字段。不要图省事把上一次的值硬编码进代码因为这个字段可能每次会话都不同一旦失效登录必然被拒。3.3 验证码的务实处理先人工再自动化验证码这部分我要说点实在的。很多人一听到验证码就想到图像识别、机器学习实际上在日常模拟登录场景里最务实的方式是“把验证码图片取回来存成本地图片人工看一眼手动输入”。对个人自动化工具来说人工输入验证码完全够用还能绕开一堆图像识别的脏活累活。代码层面就两步。第一步用同一个Session去请求验证码接口拿到图片二进制数据。第二步用Pillow打开/保存图片命令终端里请你输入看到的字符。from PIL import Image import io captcha_url https://jw.example.edu.cn/captcha.aspx captcha_resp session.get(captcha_url, timeout10) # 写入临时文件方便人工查看 with open(captcha.png, wb) as f: f.write(captcha_resp.content) # 也可以直接在内存里用Pillow打开 img Image.open(io.BytesIO(captcha_resp.content)) img.show() captcha input(请输入验证码).strip()注意部分系统的验证码接口需要带Referer字段。如果你发现图片请求返回403或验证码图片无法显示给验证码请求加上登录页的网址作为Referer即可。这不是什么高深技巧就是模拟浏览器访问时必须带全的“身份信息”。如果你的目标是想学习验证码OCR那另说。简单数字验证码用开源OCR工具配合图像去噪识别率能做到七八成彩色干扰线、扭曲变形的验证码识别成本会高很多对个人项目不划算。3.4 构造表单并提交小心处理302跳转表单数据构造时除了账号密码验证码隐藏字段一定要带上。btnLogin这种按钮字段也建议带上很多ASP.NET程序会校验被按下的按钮名。login_data { __VIEWSTATE: viewstate, __EVENTVALIDATION: eventvalidation, txtUserName: 学号, txtPassword: 密码, txtCaptcha: captcha, btnLogin: 登录, }提交时我强烈建议先设置allow_redirectsFalse不要自动跟随跳转。为什么因为登录成功和失败都可能走302只是跳转地址不同。关掉自动跳转后你可以直接看状态码和Location头判断这次登录到底成没成。比如成功时Location: /main.aspx失败时又跳回/default.aspx一目了然。login_url https://jw.example.edu.cn/default.aspx resp session.post( login_url, datalogin_data, allow_redirectsFalse, timeout10 ) print(状态码:, resp.status_code) print(Location:, resp.headers.get(Location, 无))如果状态码是302并且Location指向系统主页说明登录请求本身已经通过了剩下的就交给一个GET请求跟随过去。如果状态码是200那多半是失败了。此时不要埋头猜直接把响应文本里的提示信息打印出来。if resp.status_code 302 and main.aspx in (resp.headers.get(Location) or ): # 手动跟随跳转进入系统主页 index_resp session.get(https://jw.example.edu.cn/main.aspx, timeout10) print(登录成功主页大小:, len(index_resp.text)) # 检查主页是否包含个人信息关键字比如姓名、学号 if 某某某 in index_resp.text: print(主页验证通过) else: # 把错误页面上的提示文本提取出来定位问题 tmp_soup BeautifulSoup(resp.text, lxml) tips tmp_soup.get_text()[:200] print(登录失败返回页面提示, tips)到这里一个最基础的登录流程已经跑通了。你手上有同一个Session有登录后的身份接下来查成绩、查课表不过就是“拿着门禁卡去开不同楼门”的事。4. 登录成功之后成绩数据是怎么被拿下来的4.1 先搞清楚成绩页面是整页刷新还是AJAX加载登录只是第一步大部分人做模拟登录是为了后面能自动查成绩、查课表。登录成功后手动进一次成绩查询页面同时盯着开发者工具看判断它是“整页刷新”还是“局部AJAX刷新”。老一点的教学系统通常是整页刷新点击成绩查询菜单地址栏变化整个页面重新加载成绩就在表格里。这种页面用BeautifulSoup就能解析。新一些的系统可能是局部刷新点击后地址栏不变某个区域通过AJAX从接口拿数据。你需要在Network里找到返回JSON或片段HTML的那个XHR请求然后直接请求这个接口解析返回数据。我这里以最常见的情况举例一个成绩查询页面请求方式是GET响应HTML里有一张成绩表格。4.2 解析HTML表格整理成结构化数据拿到HTML之后我优先推荐用pandas的read_html它能把符合条件的HTML表格自动解析成DataFrame省去手写遍历标签的大量代码。几行代码就够import pandas as pd score_url https://jw.example.edu.cn/score_list.aspx score_resp session.get(score_url, timeout10) score_resp.encoding score_resp.apparent_encoding df_list pd.read_html(score_resp.text) if df_list: score_df df_list[0] print(score_df.head())read_html偶有解析错位的状况如果表格行列对不上再退回用BeautifulSoup手动解析table、tr、td。这里给一个手动解析的思路方便你遇到复杂表格时自己兜底from bs4 import BeautifulSoup soup BeautifulSoup(score_resp.text, lxml) table soup.find(table, {id: DataGrid1}) # id以实际页面为准 for tr in table.find_all(tr): cells [td.get_text(stripTrue) for td in tr.find_all([td, th])] print(cells)如果你想把成绩导出成Excelpandas一行就搞定score_df.to_excel(my_scores.xlsx, indexFalse)注意有些成绩查询页需要传学期参数比如?term2024-2025-1。参数名和取值可以从手动点查询时的请求URL里抄下来然后在代码里维护一个变量切换学期就切换参数。登录后的会话状态会维持一段时间但如果脚本长时间不发请求服务器可能让会话过期。长任务的思路是重要请求前先访问一次主页或个人中心刷新会话再执行具体数据抓取。这不优雅但够实用。5. 最容易翻车的五个细节我的排查过程和修复记录5.1 验证码总提示“错误”不一定是眼神不好登录失败最高频的错误之一就是明明验证码看着没错提交后却说验证码错误。我一开始以为是自己看错了反复试了好几遍才反应过来问题出在会话不一致。具体过程是这样我先用Session A拿到了验证码图片输入之后提交但提交用的是Session B或者我中途又新建了Session去GET了一次登录页。结果提交时Cookie携带的是Session B的SessionId而验证码是Session A生成的服务器一对不上自然当作验证码错误。修复方式很朴素拿验证码和提交登录必须严格使用同一个requests.Session对象。如果代码里不小心出现两次requests.get没有用session那就等于每次都是一个全新会话验证码必然失效。把全部请求都收敛到同一个session对象上之后这个问题就再也没出现过。5.2 出现“回发或回调参数无效”多半是隐藏字段过期还有一种非常典型的错误登录页打开太久或者脚本里反复GET登录页但最终用了旧的隐藏字段值提交导致ASP.NET抛“回发或回调参数无效”。排查时我建议打印提交前使用的__VIEWSTATE和__EVENTVALIDATION再对比一下刚刚GET到的页面里提取的新值。如果不一样说明流程里某一步覆盖了之前提取的数据。解决方法是登录前只GET一次登录页提取完隐藏字段立刻提交中间不要再刷新登录页。因为隐藏字段常常是一大长串Base64编码肉眼看了也白看。我用了一个轻量办法把提取到的字段值和提交时的字段值在日志里做前后对比只要保持一致就能排除“旧数据提交”的嫌疑。5.3 Referer缺失被服务器拦下来有些教务系统对Referer比较敏感尤其是验证码接口和POST登录接口。少了Referer轻则验证码图片取不到重则登录POST返回403。如果你遇到响应码403或“非法请求”之类提示可以在请求头里补上Referer值填登录页地址即可。顺手把Origin也加上Origin是协议加域名比如https://jw.example.edu.cn。这两个头对ASP.NET系统尤其管用。很多博客教程不强调这一点觉得requests默认不带头也行。事实上我在几个不同系统上实测过带全和带不全差别很大建议大家默认就把请求头补完整。更省事的做法是像开头那样在Session级别统一设置默认请求头所有子请求自动继承。5.4 浏览器里没问题Python里全是乱码登录成功之后我遇到过一个很坑的乱码问题浏览器打开成绩页完全正常python打印响应文本全是“锟斤拷”。原因很简单页面编码是GBK或GB2312而requests从响应头里没捞到charset便默认按ISO-8859-1处理中文自然变成乱码。修复方式是用resp.apparent_encoding从内容里推断实际编码然后给resp.encoding赋值。我通常在Session外面封装一个小函数每次请求后统一做编码处理def session_get(session, url, **kwargs): resp session.get(url, **kwargs) if not resp.encoding or resp.encoding.lower() iso-8859-1: resp.encoding resp.apparent_encoding return resp顺带一提少数系统的登录页和成绩页编码还不一样一个UTF-8一个GBK这种情况下千万别在Session级别写死编码按页面动态判断才是正解。5.5 有些系统密码不是明文传输的别慌后来我在帮人调试另一个系统时遇到过密码被前端JS加密的情况。点击登录后POST里的密码字段不是明文而是一串不可读的密文。这是因为页面用了RSA或AES在前端把密码加密后再提交。遇到这种情况不要慌也不要试图绕过加密。正确做法是找到加密逻辑在Network面板里看是哪个JS文件参与加密在Sources面板里搜关键字比如RSA、encrypt、setPublicKey。把公钥找出来Python端用rsa或Crypto库按同一套算法加密并提交。这里有一个经验之谈很多系统的加密只在密码字段上做文章账号和验证码还是明文。你先在浏览器里故意输错一次密码看POST payload里的字段是明文还是密文就能快速判断是否需要处理加密。不要一上来就四处找“万能JS解密工具”没必要也不安全。6. 边界与后续模拟登录能做什么、不该做什么6.1 同一条链路还能应用到哪些场景把教务网模拟登录跑通之后你会发现自己掌握了一套通用方法。接下来想查课表、查考勤、查图书馆借阅记录只要这些系统的登录逻辑相似无非是改一下请求地址、字段名、解析规则就能复用。我自己的实际项目里就用这套链路做了三件事成绩查询后自动算学期绩点并输出Excel每天早上自动登录一次把当天课表发到本地日志考试周来临前批量导出本学期所有课程成绩。每一个都不复杂但确实帮我省了反复打开网页的麻烦。另外这套“先抓包、再复现请求、最后解析数据”的思路并不仅限于教务系统。内网工单系统、线上报修平台、资源预约站点凡是有账号密码的地方都可以用同样的方法去做个人自动化。这种能力不是某个学校某个系统的特定技巧而是一种通用工程思路。6.2 自动化是有边界的也是可以做得体面的最后说几句关于边界的话。写这种脚本之前先想清楚它是干嘛用的、数据是谁的、请求频率是否会给服务器造成压力。我自己的原则是只登录自己的账号只查本人的数据请求间隔至少几秒以上绝不做批量并发。密码处理上我从来不会把账号密码硬编码在代码里。脚本里统一从本地环境变量读取比如import os username os.getenv(STU_ID) password os.getenv(STU_PASSWORD)这样代码即使发给别人也不会泄露凭证。再说了硬编码密码的脚本一旦在公共场合被看到把柄可就落下了。模拟登录、页面解析这类技术本身是中性的用来写个查成绩的小工具、方便自己的生活是个挺好的Python实战项目。但如果拿去撞库、爬取他人数据、频繁测试学校系统漏洞那就越界了。我在给学弟写这个脚本时也反复强调过技术能让你进去不代表你可以随便翻东西登录之后“只拿自己该拿的”这才是体面的做法。跑通这个脚本之后我对“网页自动化”这块的理解明显上了一个台阶。后来再看各种需要登录才能访问数据的站点脑海里第一反应不再是“好复杂”而是“先抓包看看”。如果你照着这条链路走一遍应该也会有同样的感觉。