1. 项目缘起：从“必修课”到“自动化”的转变

每到学期末，高校学生都会面临一项“必修课”——登录正方教务系统，完成对任课教师的教学评价。这套系统几乎是国内高校教务管理的标配，其界面设计、操作流程对于一届届学生来说，既熟悉又无奈。熟悉的是那套十几年如一日的蓝色或灰色UI，无奈的是那几十个需要逐一点击的评分项和文本输入框。对于学生而言，这常常是一项耗时且重复性极高的任务；对于开发者或技术爱好者来说，这却是一个观察Web自动化、反爬策略以及人机交互的绝佳样本。

“新版正方教务系统一键教学评价”这个项目，其核心诉求非常直接：将原本需要手动、重复、耗时数分钟甚至更久的评价操作，通过技术手段自动化，实现“一键完成”。这背后不仅仅是“偷懒”，更是一种效率工具思维的体现。在Web技术飞速发展的今天，许多日常操作仍停留在“原始”的点击阶段，自动化脚本的价值就在于解放人力，将重复劳动交给机器。然而，正方教务系统作为关键的业务系统，其安全性不容小觑，通常会部署一系列反自动化措施，如动态令牌、验证码、请求加密、操作顺序校验等。因此，这个“一键”实现的背后，是对目标系统网络协议、前端逻辑、安全机制的深入分析与巧妙绕过。

我之所以对这个项目感兴趣，是因为它完美地结合了实用性与技术挑战性。从实用角度看，它确实能解决大量学生的痛点；从技术角度看，它涉及HTTP请求分析、JavaScript逆向、模拟登录、会话维持、动态数据提取等一系列Web爬虫与自动化中的核心知识点。接下来，我将以一名技术实践者的视角，从头拆解这个项目的实现思路、关键技术点、可能遇到的“坑”以及最终的解决方案。请注意，本文内容仅用于技术交流与学习，旨在探讨自动化技术的实现原理与边界，请勿将其用于任何干扰系统正常运行或违反相关规定的用途。

2. 逆向工程：揭开新版正方教务系统的面纱

实现自动化的第一步，永远是“读懂”目标系统。我们不能盲目模拟点击，必须弄清楚一次完整的手动评价操作，在浏览器与服务器之间究竟发生了哪些数据交换。

2.1 网络请求抓包与分析

首先，我们需要使用浏览器开发者工具（Chrome DevTools 或 Firefox Developer Tools）的Network面板，录制一次从登录到完成所有评价并提交的全过程。

关键请求节点通常包括：

1. 登录请求：这是第一道关卡。需要找到提交用户名、密码的POST请求端点。仔细观察，密码字段很可能不是明文传输，而是经过前端JavaScript加密后的密文（常见的有RSA、AES或自定义的编码方式）。此外，登录请求往往伴随着一个动态的token或lt（Login Ticket）参数，用于防止重放攻击，这个值通常隐藏在登录页面的HTML源码或另一个前置请求的响应中。

2. 主框架/菜单加载请求：登录成功后，系统会加载一个左侧菜单栏的主框架页面。需要找到获取评价功能入口链接的请求。这个链接可能是一个静态的URL，也可能需要通过解析一个JavaScript动态生成的菜单列表来获取。

3. 进入评价页面请求：点击评价菜单后，会加载一个包含本学期所有待评价课程列表的页面。需要分析这个页面是如何渲染的：是服务器直接返回HTML，还是前端通过Ajax请求JSON数据再动态渲染？通常，课程列表数据是通过一个单独的API接口获取的。

4. 获取评价问卷请求：点击某一门课程后的“评价”按钮，会跳转到具体的评价表单页面。这个表单的HTML结构、所有的评分项（单选按钮、下拉框、文本框）的name和value，以及一个至关重要的隐藏字段——__VIEWSTATE或类似的防伪令牌（ASP.NET WebForm技术常见），都需要被准确提取。新版系统可能采用Vue/React等前端框架，评价数据可能通过API接口获取和提交，此时需要找到对应的数据接口。

5. 提交评价请求：填写完所有评价项（或由脚本自动填充）后，点击提交按钮。这是最核心的请求。需要分析：

   • 请求URL：提交到哪个端点。
   • 请求方法：通常是POST。
   • 请求头：特别注意Content-Type、Referer、User-Agent以及可能自定义的X-Requested-With等头部。
   • 请求体：这是重中之重。它应该包含了所有评价项的值、课程ID、教师ID、以及上一步获取到的防伪令牌。数据格式可能是application/x-www-form-urlencoded（键值对），也可能是application/json。

一个典型的踩坑点：很多系统在提交评价时，不仅校验防伪令牌，还会校验请求的先后顺序。例如，提交评价的请求必须携带一个从评价页面获取的、有时效性的token，或者服务器会验证本次提交的评价项列表是否与之前拉取的问卷结构完全匹配，防止篡改。

2.2 会话（Session）与Cookie管理

正方教务系统毫无疑问是基于Session的。这意味着，从登录成功那一刻起，服务器会建立一个会话，并给浏览器返回一个JSESSIONID之类的Cookie。后续的所有请求，都必须携带这个Cookie，服务器才能识别出你的身份。

在自动化脚本中，我们需要使用一个能够自动管理Cookie的HTTP客户端库，例如Python的requests.Session()。它会像浏览器一样，自动保存服务器返回的Cookie，并在后续请求中自动附加上去。

注意：有些系统可能会在关键操作（如提交评价）前，通过JavaScript动态设置或更新Cookie。如果遇到提交失败但登录和获取数据都成功的情况，需要检查关键请求的Cookie是否完整，必要时可以尝试从页面中提取并手动设置。

2.3 动态参数与前端加密破解

这是自动化过程中技术难度最高的部分之一。新版系统为了安全，可能会引入更多动态机制。

• 动态Token：除了登录时的lt，评价页面或提交接口可能有一个动态生成的csrf_token或evalcode_token。这个token通常隐藏在页面的某个<input type="hidden">标签里，或者通过一个特定的初始化接口返回。脚本需要先访问评价页面，解析HTML或调用初始化接口，提取出这个token，再将其放入提交请求中。

• 密码/数据加密：如果发现登录时密码是乱码，或者提交的评价数据是一串加密字符串，那么就需要进行JavaScript逆向。使用开发者工具的Sources面板，找到负责加密的JavaScript文件（通常经过混淆），通过断点调试、代码格式化、逻辑分析，理解其加密算法（可能是简单的Base64、MD5，也可能是复杂的RSA）。然后在脚本中，用Python的相应加密库（如hashlib,rsa,Crypto）复现该算法。

• 请求签名：更高级的防护是请求签名。服务器要求客户端在发起请求时，对请求参数、时间戳、密钥等按照特定规则生成一个签名（sign），并随请求一起发送。服务器端用同样的规则验签，不一致则拒绝。如果遇到这种情况，就需要完整逆向出签名的生成算法。

我的经验是：对于正方教务系统，大部分情况下加密不会过于复杂，多为防止明文传输的基础加密。优先尝试从网络请求中直接获取明文或简单编码后的参数，如果不行，再深入进行JS逆向。同时，可以尝试搜索是否有针对该校或该版本系统的前人分析，能节省大量时间。

3. 技术选型与核心脚本设计

分析清楚系统交互逻辑后，就可以开始设计自动化脚本了。技术栈的选择多种多样，这里以最常用的Python为例。

3.1 核心工具库

1. HTTP请求库：requests

   • 为什么选它：requests是Python最人性化的HTTP库，其Session对象能完美处理Cookie持久化、连接复用，简化了登录态维持的流程。相比于更底层的urllib，它的API简洁明了。
   • 关键使用：创建一个requests.Session()实例，所有操作都通过这个session进行。

2. HTML解析库：BeautifulSoup4或lxml

   • 为什么选它：用于从服务器返回的HTML页面中提取关键信息，如防伪令牌__VIEWSTATE、课程列表链接、评价表单的各输入框ID等。BeautifulSoup语法更友好，lxml解析速度更快。
   • 关键使用：soup.find()和soup.select()方法。

3. 浏览器自动化备选：selenium或playwright

   • 什么时候需要：当目标系统的反爬措施极其严格，所有关键参数都由前端JavaScript动态计算生成，且难以通过静态分析逆向时，可以考虑使用浏览器自动化工具。它们能驱动一个真实的浏览器（如Chrome）执行操作，完美绕过前端加密和动态渲染问题。
   • 为什么慎用：浏览器自动化资源消耗大、速度慢、不够稳定，且容易被检测（虽然对于教务系统这种级别的防护，通常检测不强）。它应该是“迫不得已”的最后手段。我们的目标应该是尽可能使用轻量级的requests模拟请求。

4. 数据处理与编码库：hashlib,base64,rsa等

   • 为什么需要：用于复现前端可能使用的加密算法。

3.2 脚本核心逻辑流程图（文字描述）

一个健壮的脚本应遵循以下逻辑顺序：

1. 初始化会话：创建requests.Session()对象，并设置合理的请求头（User-Agent,Accept-Language等），模拟真实浏览器。
2. 登录系统： a. GET请求登录页面，提取隐藏的动态参数（如lt,execution）。 b. （如果需要）分析或调用JS加密函数，对密码进行加密处理。 c. 构造登录表单数据，使用Session发起POST请求。 d. 检查响应，确认登录成功（如检查返回的HTML中是否包含用户名，或是否跳转到主页）。
3. 导航至教学评价模块： a. 访问系统主菜单页面。 b. 解析页面，找到“教学评价”或类似功能的链接地址。可能需要解析JavaScript或iframe。 c. 访问该链接，进入评价列表页面。
4. 获取待评价课程列表： a. 解析评价列表页面，获取所有本学期待评价的课程信息（课程名、课程ID、教师名、教师ID、评价链接等）。这些信息可能在一个<table>里，也可能通过Ajax加载。 b. 将课程列表存储在程序变量中，如一个字典列表。
5. 遍历课程并完成评价： a. 对于列表中的每一门课程，访问其具体的评价页面。 b. 从评价页面HTML中提取关键隐藏字段，如__VIEWSTATE、__EVENTVALIDATION以及课程和教师的唯一标识符。 c.构造评价数据：这是脚本的“策略”核心。你可以选择： *默认好评：将所有评分项设置为最高分（如95，100），文本评价填写“老师讲课认真负责，受益匪浅”等通用好评。 *随机化评价：在“良好”及以上等级中随机选择分数，文本从预设的好评语料库中随机选择一条，避免完全雷同。 *（高级）个性化模板：根据课程类型（必修课、选修课、实验课）应用不同的评价模板。 d. 将构造好的数据与隐藏字段一起，组装成POST请求的表单数据或JSON数据。 e. 使用Session发起提交评价的POST请求。 f.检查提交结果：解析服务器返回的响应，判断是否成功（通常页面会提示“评价成功”或返回特定的成功状态码）。如果失败，记录日志（课程名、失败原因），并决定是重试还是跳过。
6. 善后与日志：所有课程处理完毕后，输出一份详细的执行报告，包括成功评价的课程数、失败的课程及原因。脚本应具备一定的容错能力，单门课程评价失败不应导致整个脚本崩溃。

3.3 关键代码片段示例（Python + requests）

以下是一个高度简化的伪代码框架，展示了核心步骤：

import requests from bs4 import BeautifulSoup import re class JwxtAutoEval: def __init__(self, username, password, base_url): self.session = requests.Session() self.base_url = base_url self.username = username self.password = password # 设置请求头，模拟浏览器 self.session.headers.update({ 'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ...', 'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8', }) def login(self): # 1. 获取登录页，提取动态参数 login_page_url = f"{self.base_url}/login.jsp" resp = self.session.get(login_page_url) soup = BeautifulSoup(resp.text, 'html.parser') lt_token = soup.find('input', {'name': 'lt'})['value'] execution = soup.find('input', {'name': 'execution'})['value'] # 2. 构造登录数据（假设密码需要加密，这里简化处理） # 实际情况可能需要调用JS加密函数，此处用明文示例 login_data = { 'username': self.username, 'password': self.password, # 注意：真实情况这里可能是加密后的密码 'lt': lt_token, 'execution': execution, '_eventId': 'submit', 'rmShown': '1' } # 3. 提交登录 login_post_url = f"{self.base_url}/j_spring_security_check" # 示例端点 resp_post = self.session.post(login_post_url, data=login_data) # 4. 验证登录是否成功，例如检查响应中是否包含登出链接或用户名 if '退出系统' in resp_post.text or self.username in resp_post.text: print("登录成功") return True else: print("登录失败") return False def get_course_list(self): # 访问评价主页面 eval_main_url = f"{self.base_url}/evaluate/forwardEvaluate.action" resp = self.session.get(eval_main_url) soup = BeautifulSoup(resp.text, 'html.parser') courses = [] # 假设课程列表在一个id为`dataTable`的表格中 table = soup.find('table', {'id': 'dataTable'}) if table: for row in table.find_all('tr')[1:]: # 跳过表头 cols = row.find_all('td') if len(cols) > 3: course = { 'name': cols[0].text.strip(), 'id': cols[1].text.strip(), 'teacher': cols[2].text.strip(), 'eval_link': cols[3].find('a')['href'] if cols[3].find('a') else None } if course['eval_link']: courses.append(course) return courses def evaluate_course(self, course_info): # 1. 访问该课程的评价页面 eval_page_url = self.base_url + course_info['eval_link'] resp = self.session.get(eval_page_url) soup = BeautifulSoup(resp.text, 'html.parser') # 2. 提取隐藏字段 viewstate = soup.find('input', {'name': '__VIEWSTATE'}) viewstate = viewstate['value'] if viewstate else '' # 可能还有其他隐藏字段，如 __EVENTVALIDATION # 3. 构造评价数据（示例：所有评分项打95分，文本填通用好评） # 需要根据实际页面的input name来构造 form_data = { '__VIEWSTATE': viewstate, 'txtEvaluation': '老师教学认真，课堂内容丰富，互动良好。', # 文本评价 'radScore1': '95', # 假设的评分项1 'radScore2': '95', # 假设的评分项2 # ... 其他评分项 'btnSubmit': '提交' } # 4. 提交评价 submit_url = eval_page_url # 通常提交到当前页面 resp_submit = self.session.post(submit_url, data=form_data) # 5. 检查结果 if '评价成功' in resp_submit.text: print(f"课程《{course_info['name']}》评价成功") return True else: print(f"课程《{course_info['name']}》评价失败") # 可以在这里保存失败的页面源码用于调试 return False def run(self): if not self.login(): return courses = self.get_course_list() print(f"找到 {len(courses)} 门待评价课程") success_count = 0 for course in courses: if self.evaluate_course(course): success_count += 1 print(f"评价完成。成功：{success_count}， 失败：{len(courses)-success_count}") # 使用示例 if __name__ == '__main__': # 请替换为实际的URL、学号、密码 auto_eval = JwxtAutoEval('你的学号', '你的密码', 'https://jwxt.your-university.edu.cn') auto_eval.run()

重要提示：以上代码仅为概念演示，实际系统中的参数名、URL、页面结构千差万别，必须根据你所在学校的正方系统实际情况进行抓包分析并修改。

4. 实战中的“坑”与应对策略

理论很美好，但实战中总会遇到各种意想不到的问题。下面分享几个我遇到过的典型“坑”及其解决思路。

4.1 验证码（CAPTCHA）拦截

这是自动化脚本最大的敌人之一。有些学校的正方系统会在登录或提交评价时弹出验证码。

• 应对策略：
  1. 尝试规避：验证码有时只在密码错误多次后触发。确保脚本使用正确的密码，避免触发风控。
  2. 人工干预：对于低频、一次性的评价任务，可以在脚本运行到需要验证码的环节时，暂停并提示用户手动输入。可以通过input()函数在控制台接收，或者用selenium弹出浏览器让人工识别。
  3. OCR识别：如果验证码是简单的数字、字母扭曲，可以尝试使用OCR库（如pytesseract）进行识别。但正方系统的验证码通常针对性较强，识别率不高。
  4. 打码平台：接入第三方打码平台API，将验证码图片发送给平台，由人工或高精度模型识别后返回结果。这是最稳定但需要付费的方案。
  5. 终极思考：对于教学评价这种合法但自动化的需求，验证码的出现本身值得商榷。如果遇到，或许也意味着自动化这条路被官方一定程度上堵上了。

4.2 请求频率过快导致被封禁

脚本如果无延迟地快速提交所有课程评价，很可能被服务器识别为异常流量，导致IP或会话被临时封禁。

• 应对策略：
  • 添加随机延迟：在每个关键请求（如访问课程页面、提交评价）之间，使用time.sleep()添加一个随机延时（例如2-5秒），模拟人类操作的不确定性。
  • 处理失败重试：如果请求失败（返回403、429等状态码），脚本应能捕获异常，等待更长一段时间（如30秒、1分钟）后重试，并设置最大重试次数。
  • 使用代理IP池：对于大规模应用，可以考虑使用代理IP来分散请求。但对于个人评价，通常不需要。

4.3 页面结构或接口突然变更

教务系统可能会不定期升级，导致页面HTML结构、API接口地址或参数发生变化。

• 应对策略：
  • 健壮的解析代码：写解析代码时不要依赖过于具体和脆弱的CSS选择器或标签顺序，尽量寻找具有唯一id或name的元素。
  • 关键元素存在性检查：在提取__VIEWSTATE等关键元素前，先检查该元素是否存在，如果不存在则给出明确的错误提示，便于快速定位问题。
  • 配置化：将容易变化的URL、参数名、表单字段映射关系提取到配置文件（如JSON）中。当系统升级时，只需更新配置文件，而无需修改核心代码逻辑。
  • 日志与通知：脚本应记录详细的操作日志。如果运行失败，能通过日志快速定位到是哪个环节（登录、获取列表、提交）出了问题，方便针对性调试。

4.4 “一键”评价的道德与风险考量

虽然技术上是可行的，但我们必须清醒地认识到：

1. 数据真实性丧失：教学评价的本意是收集学生反馈以帮助教师改进教学。全自动的“默认好评”使得评价数据失去了参考价值，违背了制度设计的初衷。
2. 违反系统使用规定：绝大多数学校的教务系统用户协议中，都明确禁止使用自动化脚本、机器人等非人工方式访问系统。一旦被系统管理员发现，可能导致账号被警告、限制功能甚至处分。
3. 技术滥用风险：此类脚本如果被用于恶意刷评、攻击系统，会造成更严重的后果。

因此，我的个人建议和体会是：将这个项目视为一个纯粹的技术学习与实践的沙盒。通过它，你可以深入理解Web协议、前端安全、自动化测试等知识。但在实际使用上，请务必谨慎。或许可以开发一个“半自动”辅助工具，例如：自动填充所有课程的评分项为“未评价”，但保留文本评价框让用户手动填写；或者自动列出所有待评价课程，用户只需点击一次“全部提交”但脚本会确保每项评价有合理的延迟。在提升效率的同时，保留评价的实质意义，并严格遵守相关规定。

技术是中立的，但使用技术的人需要为其后果负责。在追求效率与便利的同时，守住技术的伦理边界，是每一位开发者应有的素养。