川农教务网代码跑不通?3个高频面试题级Bug排查实战
刚把同事给的 sichuan-agri-login.py 丢进 PyCharm，回车一敲，屏幕直接弹红字 SSLError: certificate verify failed。那种“明明文档上写着能跑，为什么我这儿就不行”的无力感，每个转行搞后端或者自动化的同学都懂。更扎心的是，这种因为环境、协议或者反爬机制导致的“水土不服”，恰恰是面试官最爱追问的细节。很多候选人觉得爬个学校教务网很简单，但当你深入到底层 HTTP 请求封装、会话保持、甚至数据解析的容错机制时，才发现这里藏着不少高频面试题级别的考点。
今天咱们不整虚的，直接以川农教务网（Sichuan Agricultural University）的自动登录与课程查询场景为例，拆解一段真实项目中踩坑无数的源码。你会发现，所谓的“代码跑不通”，90% 的原因不在业务逻辑，而在你忽略的网络层细节和异常处理。
入口定位：从 URL 到 Session 的生死线
很多人写爬虫，第一步就是 requests.get(url)。但在川农教务网这类基于 CAS（Central Authentication Service）单点登录系统的校园网中，直接 GET 登录页往往拿不到正确的 token 或 lt 参数。
为什么？因为 CAS 的认证流程是有状态的。你在浏览器里看到的“登录成功”，其实是浏览器自动维持了 JSESSIONID 和 TGC（Ticket Granting Cookie）。如果代码里新建了一个 Session 对象却没有正确初始化，或者在多次请求间丢失了 Cookie，服务端就会认为你是非法请求，直接重定向到错误页或返回 403 Forbidden。
这就引出了第一个核心痛点：上下文丢失。
在实际项目中，我们通常不会用裸的 requests 库，而是封装一个带有状态管理的 Client。以下是基于 requests.Session 封装的基础入口类，这里展示了如何正确初始化会话并处理重定向。
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
class JwClient:
def __init__(self):
# 1. 创建 Session 对象，确保 Cookie 在多次请求间共享
self.session = requests.Session()
# 2. 配置重试机制，防止因网络波动导致偶发失败
# 注意：total 设置为 3 次，backoff_factor 为 0.3，实现指数退避
retries = Retry(
total=3,
backoff_factor=0.3,
status_forcelist=[500, 502, 503, 504]
)
# 3. 挂载重试适配器到 HTTP/HTTPS 两个协议上
self.session.mount('http://', HTTPAdapter(max_retries=retries))
self.session.mount('https://', HTTPAdapter(max_retries=retries))
# 4. 设置 User-Agent，伪装成常规浏览器
# 参考官方文档推荐，使用最新版 Chrome 的 UA 字符串
self.session.headers.update({
'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36',
'Referer': 'https://jw.sicau.edu.cn/'
})
逐行解析与设计意图：
self.session = requests.Session()：这是最容易被新手忽略的一行。如果你每次请求都新建 requests.Session()，Cookie 就会重置。川农教务网的 CAS 登录依赖 Cookie 传递票据，一旦重置，登录态立刻失效。
Retry 与 HTTPAdapter：校园网环境复杂，偶尔的 DNS 解析失败或连接超时是常态。通过 urllib3 的 Retry 机制，我们可以自动重试那些非业务逻辑错误（如 5xx 状态码）。这在面试中常被问及：“如何处理网络不稳定导致的脚本中断？”答案就是：区分业务错误与系统错误，对系统错误进行指数退避重试。
headers.update：很多学校教务系统会校验 Referer 和 User-Agent。缺失这两个字段，直接返回 403 是常见现象。这里参考了官方文档中关于浏览器指纹校验的最佳实践，确保请求看起来像真实用户。
核心片段：CAS 登录流程的逆向与封装
搞定了 Session，接下来是登录。很多初学者会盯着 F12 里的网络请求，看到 POST /cas/login 就直接发请求。但川农教务网的 CAS 登录有一个隐藏字段：_eventId 和 execution 令牌。
如果你只复制了表单里的 username 和 password，请求一定会失败。因为 execution 是一个一次性的令牌，每次刷新登录页都会变化。这就是为什么“复制来的代码跑不通”——环境变了，令牌也变了。
我们需要先 GET 登录页，从 HTML 中提取 execution 和 lt，然后再 POST 凭证。
import re
def login(self, username: str, password: str):
执行 CAS 登录流程
base_url = https://jw.sicau.edu.cn
login_url = f{base_url}/cas/login?service={base_url}/jwapp
# 1. GET 登录页，获取初始参数
# allow_redirects=True 确保跟随重定向，拿到最终的登录表单页
resp = self.session.get(login_url, allow_redirects=True)
# 2. 解析 HTML，提取 execution 和 lt 参数
# 使用正则匹配 input 标签中的 name 和 value
html_content = resp.text
execution_match = re.search(r'name=execution value=([^]+)', html_content)
lt_match = re.search(r'name=lt value=([^]+)', html_content)
if not execution_match or not lt_match:
raise ValueError(Failed to extract execution/lt tokens. Check if HTML structure changed.)
execution = execution_match.group(1)
lt = lt_match.group(1)
# 3. 构造 POST 请求数据
# 注意：CAS 登录通常还需要 _eventId 和 service 参数
post_data = {
'username': username,
'password': password,
'execution': execution,
'lt': lt,
'_eventId': 'submit',
'service': f'{base_url}/jwapp'
}
# 4. 发送登录请求
# 关键点：不要自动跟随重定向！
# CAS 登录成功后，会 302 跳转到 service 地址并携带 ticket
# 我们需要手动捕获这个 302，以便验证 ticket 是否有效
login_resp = self.session.post(
f{base_url}/cas/login,
data=post_data,
allow_redirects=False
)
# 5. 判断登录状态
# 登录成功时，HTTP 状态码为 302，Location 头包含 ticket
if login_resp.status_code == 302:
location = login_resp.headers.get('Location')
if location and 'ticket=' in location:
print(Login Success!)
return True
else:
print(Login Failed: Redirected to unexpected location.)
return False
else:
# 如果返回 200，通常意味着登录失败，页面重新渲染
# 此时可以解析页面中的错误提示 div
error_div = re.search(r'div id=error[^]*(.*?)/div', login_resp.text, re.DOTALL)
if error_div:
print(fLogin Error: {error_div.group(1).strip()})
return False
逐行解析与避坑指南：
正则提取 execution：这是川农教务网（以及所有基于 CAS 的系统）的核心。execution 是服务端生成的会话令牌，绑定在特定的浏览器会话上。如果代码中硬编码了这个值，第二天必挂。面试中常问：“如何保证脚本的健壮性？”答案：动态解析动态参数，避免硬编码。
allow_redirects=False 的妙用：这是新手最容易错的地方。很多教程让你开 allow_redirects=True，但对于登录接口，我们需要知道它跳转去了哪里。如果跳转到了 /cas/logout，说明密码错了；如果跳转到了业务系统并带着 ticket，说明成功了。手动控制重定向，让我们能精准判断登录结果。
错误信息解析：登录失败时，服务端不会返回 401，而是返回 200 并展示一个带有错误信息的页面。通过正则提取 div id=error 的内容，我们可以把具体的错误原因（如“账号或密码错误”）反馈给用户，而不是抛出一个冷冰冰的异常。
设计思想：为什么不用 Selenium？
很多转岗同学看到复杂登录，第一反应是上 Selenium 模拟浏览器点击。确实，Selenium 能解决大部分前端 JS 渲染的问题，但它在川农教务网这种轻量级教务系统中，往往是大材小用，且极其不稳定。
核心设计思想：最小化依赖，最大化确定性。
性能差异：requests 发起一次登录请求耗时约 200ms，而 Selenium 启动浏览器、加载页面、定位元素、输入密码、点击按钮，全流程耗时至少 3-5 秒。对于需要批量处理数据的场景（比如帮全班同学查成绩），Selenium 的效率无法接受。
维护成本：教务系统的 UI 经常微调。如果改了按钮的 class 名，Selenium 脚本直接崩盘。而 CAS 协议是标准化的，只要后端不更换 CAS 服务器，接口结构基本不变。官方文档中明确指出，CAS 协议保证了接口的稳定性，因此优先使用 HTTP 客户端而非浏览器自动化。
资源占用：Selenium 需要无头浏览器（如 Chrome Headless），内存占用动辄几百 MB。在服务器端部署定时任务时，运行 10 个 Selenium 实例可能就把内存吃光了。而 10 个 requests.Session 几乎不占资源。
什么时候该用 Selenium？
当川农教务网引入了复杂的 JS 加密（如 md5(username + timestamp + salt)）且加密算法隐藏在混淆的 JS 文件中时，逆向 JS 难度极高。此时，用 Selenium 执行 JS 拿到加密后的密码，再配合 requests 发送请求，是更务实的选择。但这属于进阶技巧，对于基础的登录和查询，纯 HTTP 方案更优。
手写简化版：一个可复用的教务查询模块
为了让大家能直接上手，我手写了一个简化的查询模块。这个模块不仅包含登录，还封装了获取课程列表的逻辑。代码结构清晰，注释详细，适合作为面试时的“白板代码”参考。
class JwQueryService:
def __init__(self, username: str, password: str):
self.client = JwClient()
self.username = username
self.password = password
self.is_logged_in = False
def ensure_login(self):
确保已登录，若未登录则执行登录
if not self.is_logged_in:
if not self.client.login(self.username, self.password):
raise Exception(Login failed. Please check credentials.)
self.is_logged_in = True
def get_course_list(self):
获取当前学期的课程列表
假设 URL 结构为: /jwapp/course/list?term=20231
self.ensure_login()
# 1. 构建查询 URL
# 注意：term 参数需要根据当前学期动态获取，这里硬编码为示例
url = https://jw.sicau.edu.cn/jwapp/course/list
params = {
'term': '20231', # 2023学年第一学期
'page': '1'
}
# 2. 发送 GET 请求
resp = self.client.session.get(url, params=params)
# 3. 判断响应
if resp.status_code != 200:
raise Exception(fQuery failed with status {resp.status_code})
# 4. 解析 HTML 或 JSON
# 假设教务系统返回的是 HTML 表格，这里简化处理
# 实际项目中建议使用 BeautifulSoup 或 lxml 解析
# 此处仅为演示逻辑流程
if 'course-table' in resp.text:
print(Course data fetched successfully.)
return self._parse_course_table(resp.text)
else:
print(No course data found.)
return []
def _parse_course_table(self, html: str):
解析课程表格
简化版：实际应使用 BeautifulSoup
courses = []
# 示例：正则提取每一行
rows = re.findall(r'tr class=course-row(.*?)/tr', html, re.DOTALL)
for row in rows:
# 提取课程名、学分、教师
name = re.search(r'td class=name(.*?)/td', row)
credit = re.search(r'td class=credit(.*?)/td', row)
teacher = re.search(r'td class=teacher(.*?)/td', row)
if name and credit and teacher:
courses.append({
'name': name.group(1).strip(),
'credit': credit.group(1).strip(),
'teacher': teacher.group(1).strip()
})
return courses
设计亮点：
ensure_login 模式：将登录逻辑与业务逻辑解耦。每次调用查询方法前，先检查登录态。如果 Session 过期，自动重新登录。这提高了脚本的长期运行稳定性。
参数化查询：将 term（学期）作为参数传入，而不是硬编码在 URL 中。这样当学期切换时，只需修改参数，无需改动代码结构。
分层解析：将网络请求与数据解析分开。_parse_course_table 只负责处理 HTML 字符串，不关心网络状态。这使得单元测试更容易编写——你可以直接传入一段静态 HTML 字符串测试解析逻辑，而无需真实访问川农教务网。
应用场景：从教务网到企业级系统
虽然本文以川农教务网为例，但其中的设计思想完全适用于其他企业级系统，尤其是那些基于 SSO（单点登录）或 OAuth2 的内部平台。
自动化测试：在 CI/CD 流水线中，自动化测试脚本需要频繁登录测试环境。使用 requests.Session 封装的客户端，可以快速完成登录并执行 API 测试，比 Selenium 快 10 倍以上。
数据同步：很多公司需要将教务系统中的学生信息、成绩数据同步到数据仓库。通过定时任务运行上述脚本，可以每小时增量拉取最新数据，实现数据自动同步。
个人效率工具：对于学生或教师，可以封装一个命令行工具，输入 python jw_query.py --term 20231 即可导出当前学期所有课程信息为 Excel 文件。
面试高频考点回顾：
Q: 如何处理 HTTP 请求中的 Cookie 管理？
A: 使用 requests.Session 对象，它会自动维护 Cookie Jar，确保在同一个会话中 Cookie 得以保持。
Q: 登录接口返回 302 重定向，如何判断登录是否成功？
A: 检查 Location 头。如果包含业务系统的 URL 且带有 ticket 或 token 参数，通常表示成功；如果跳转到登录页或错误页，表示失败。
Q: 为什么不用 Selenium 而用 requests？
A: requests 更轻量、速度更快、资源占用更少，且不受前端 UI 变更影响。Selenium 适用于复杂 JS 渲染场景，但对于纯 API 交互，requests 是更优解。
你在项目里踩过这个坑吗？比如 CAS 登录的 execution 参数丢失，或者 Cookie 过期导致的 403 错误？评论区聊聊，看看有没有更优雅的解决方案。 
长河君 · 2026/9/22 12:22:08 · 阅读 1.2k 川农教务网代码跑不通?3个高频面试题级Bug排查实战
川农教务网代码跑不通?3个高频面试题级Bug排查实战
刚把同事给的 sichuan-agri-login.py 丢进 PyCharm，回车一敲，屏幕直接弹红字 SSLError: certificate verify failed。那种“明明文档上写着能跑，为什么我这儿就不行”的无力感，每个转行搞后端或者自动化的同学都懂。更扎心的是，这种因为环境、协议或者反爬机制导致的“水土不服”，恰恰是面试官最爱追问的细节。很多候选人觉得爬个学校教务网很简单，但当你深入到底层 HTTP 请求封装、会话保持、甚至数据解析的容错机制时，才发现这里藏着不少高频面试题级别的考点。
今天咱们不整虚的，直接以川农教务网（Sichuan Agricultural University）的自动登录与课程查询场景为例，拆解一段真实项目中踩坑无数的源码。你会发现，所谓的“代码跑不通”，90% 的原因不在业务逻辑，而在你忽略的网络层细节和异常处理。
入口定位：从 URL 到 Session 的生死线
很多人写爬虫，第一步就是 requests.get(url)。但在川农教务网这类基于 CAS（Central Authentication Service）单点登录系统的校园网中，直接 GET 登录页往往拿不到正确的 token 或 lt 参数。
为什么？因为 CAS 的认证流程是有状态的。你在浏览器里看到的“登录成功”，其实是浏览器自动维持了 JSESSIONID 和 TGC（Ticket Granting Cookie）。如果代码里新建了一个 Session 对象却没有正确初始化，或者在多次请求间丢失了 Cookie，服务端就会认为你是非法请求，直接重定向到错误页或返回 403 Forbidden。
这就引出了第一个核心痛点：上下文丢失。
在实际项目中，我们通常不会用裸的 requests 库，而是封装一个带有状态管理的 Client。以下是基于 requests.Session 封装的基础入口类，这里展示了如何正确初始化会话并处理重定向。
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
class JwClient:
def __init__(self):
# 1. 创建 Session 对象，确保 Cookie 在多次请求间共享
self.session = requests.Session()
# 2. 配置重试机制，防止因网络波动导致偶发失败
# 注意：total 设置为 3 次，backoff_factor 为 0.3，实现指数退避
retries = Retry(
total=3,
backoff_factor=0.3,
status_forcelist=[500, 502, 503, 504]
)
# 3. 挂载重试适配器到 HTTP/HTTPS 两个协议上
self.session.mount('http://', HTTPAdapter(max_retries=retries))
self.session.mount('https://', HTTPAdapter(max_retries=retries))
# 4. 设置 User-Agent，伪装成常规浏览器
# 参考官方文档推荐，使用最新版 Chrome 的 UA 字符串
self.session.headers.update({
'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36',
'Referer': 'https://jw.sicau.edu.cn/'
})
逐行解析与设计意图：
self.session = requests.Session()：这是最容易被新手忽略的一行。如果你每次请求都新建 requests.Session()，Cookie 就会重置。川农教务网的 CAS 登录依赖 Cookie 传递票据，一旦重置，登录态立刻失效。
Retry 与 HTTPAdapter：校园网环境复杂，偶尔的 DNS 解析失败或连接超时是常态。通过 urllib3 的 Retry 机制，我们可以自动重试那些非业务逻辑错误（如 5xx 状态码）。这在面试中常被问及：“如何处理网络不稳定导致的脚本中断？”答案就是：区分业务错误与系统错误，对系统错误进行指数退避重试。
headers.update：很多学校教务系统会校验 Referer 和 User-Agent。缺失这两个字段，直接返回 403 是常见现象。这里参考了官方文档中关于浏览器指纹校验的最佳实践，确保请求看起来像真实用户。
核心片段：CAS 登录流程的逆向与封装
搞定了 Session，接下来是登录。很多初学者会盯着 F12 里的网络请求，看到 POST /cas/login 就直接发请求。但川农教务网的 CAS 登录有一个隐藏字段：_eventId 和 execution 令牌。
如果你只复制了表单里的 username 和 password，请求一定会失败。因为 execution 是一个一次性的令牌，每次刷新登录页都会变化。这就是为什么“复制来的代码跑不通”——环境变了，令牌也变了。
我们需要先 GET 登录页，从 HTML 中提取 execution 和 lt，然后再 POST 凭证。
import re
def login(self, username: str, password: str):
执行 CAS 登录流程
base_url = https://jw.sicau.edu.cn
login_url = f{base_url}/cas/login?service={base_url}/jwapp
# 1. GET 登录页，获取初始参数
# allow_redirects=True 确保跟随重定向，拿到最终的登录表单页
resp = self.session.get(login_url, allow_redirects=True)
# 2. 解析 HTML，提取 execution 和 lt 参数
# 使用正则匹配 input 标签中的 name 和 value
html_content = resp.text
execution_match = re.search(r'name=execution value=([^]+)', html_content)
lt_match = re.search(r'name=lt value=([^]+)', html_content)
if not execution_match or not lt_match:
raise ValueError(Failed to extract execution/lt tokens. Check if HTML structure changed.)
execution = execution_match.group(1)
lt = lt_match.group(1)
# 3. 构造 POST 请求数据
# 注意：CAS 登录通常还需要 _eventId 和 service 参数
post_data = {
'username': username,
'password': password,
'execution': execution,
'lt': lt,
'_eventId': 'submit',
'service': f'{base_url}/jwapp'
}
# 4. 发送登录请求
# 关键点：不要自动跟随重定向！
# CAS 登录成功后，会 302 跳转到 service 地址并携带 ticket
# 我们需要手动捕获这个 302，以便验证 ticket 是否有效
login_resp = self.session.post(
f{base_url}/cas/login,
data=post_data,
allow_redirects=False
)
# 5. 判断登录状态
# 登录成功时，HTTP 状态码为 302，Location 头包含 ticket
if login_resp.status_code == 302:
location = login_resp.headers.get('Location')
if location and 'ticket=' in location:
print(Login Success!)
return True
else:
print(Login Failed: Redirected to unexpected location.)
return False
else:
# 如果返回 200，通常意味着登录失败，页面重新渲染
# 此时可以解析页面中的错误提示 div
error_div = re.search(r'div id=error[^]*(.*?)/div', login_resp.text, re.DOTALL)
if error_div:
print(fLogin Error: {error_div.group(1).strip()})
return False
逐行解析与避坑指南：
正则提取 execution：这是川农教务网（以及所有基于 CAS 的系统）的核心。execution 是服务端生成的会话令牌，绑定在特定的浏览器会话上。如果代码中硬编码了这个值，第二天必挂。面试中常问：“如何保证脚本的健壮性？”答案：动态解析动态参数，避免硬编码。
allow_redirects=False 的妙用：这是新手最容易错的地方。很多教程让你开 allow_redirects=True，但对于登录接口，我们需要知道它跳转去了哪里。如果跳转到了 /cas/logout，说明密码错了；如果跳转到了业务系统并带着 ticket，说明成功了。手动控制重定向，让我们能精准判断登录结果。
错误信息解析：登录失败时，服务端不会返回 401，而是返回 200 并展示一个带有错误信息的页面。通过正则提取 div id=error 的内容，我们可以把具体的错误原因（如“账号或密码错误”）反馈给用户，而不是抛出一个冷冰冰的异常。
设计思想：为什么不用 Selenium？
很多转岗同学看到复杂登录，第一反应是上 Selenium 模拟浏览器点击。确实，Selenium 能解决大部分前端 JS 渲染的问题，但它在川农教务网这种轻量级教务系统中，往往是大材小用，且极其不稳定。
核心设计思想：最小化依赖，最大化确定性。
性能差异：requests 发起一次登录请求耗时约 200ms，而 Selenium 启动浏览器、加载页面、定位元素、输入密码、点击按钮，全流程耗时至少 3-5 秒。对于需要批量处理数据的场景（比如帮全班同学查成绩），Selenium 的效率无法接受。
维护成本：教务系统的 UI 经常微调。如果改了按钮的 class 名，Selenium 脚本直接崩盘。而 CAS 协议是标准化的，只要后端不更换 CAS 服务器，接口结构基本不变。官方文档中明确指出，CAS 协议保证了接口的稳定性，因此优先使用 HTTP 客户端而非浏览器自动化。
资源占用：Selenium 需要无头浏览器（如 Chrome Headless），内存占用动辄几百 MB。在服务器端部署定时任务时，运行 10 个 Selenium 实例可能就把内存吃光了。而 10 个 requests.Session 几乎不占资源。
什么时候该用 Selenium？
当川农教务网引入了复杂的 JS 加密（如 md5(username + timestamp + salt)）且加密算法隐藏在混淆的 JS 文件中时，逆向 JS 难度极高。此时，用 Selenium 执行 JS 拿到加密后的密码，再配合 requests 发送请求，是更务实的选择。但这属于进阶技巧，对于基础的登录和查询，纯 HTTP 方案更优。
手写简化版：一个可复用的教务查询模块
为了让大家能直接上手，我手写了一个简化的查询模块。这个模块不仅包含登录，还封装了获取课程列表的逻辑。代码结构清晰，注释详细，适合作为面试时的“白板代码”参考。
class JwQueryService:
def __init__(self, username: str, password: str):
self.client = JwClient()
self.username = username
self.password = password
self.is_logged_in = False
def ensure_login(self):
确保已登录，若未登录则执行登录
if not self.is_logged_in:
if not self.client.login(self.username, self.password):
raise Exception(Login failed. Please check credentials.)
self.is_logged_in = True
def get_course_list(self):
获取当前学期的课程列表
假设 URL 结构为: /jwapp/course/list?term=20231
self.ensure_login()
# 1. 构建查询 URL
# 注意：term 参数需要根据当前学期动态获取，这里硬编码为示例
url = https://jw.sicau.edu.cn/jwapp/course/list
params = {
'term': '20231', # 2023学年第一学期
'page': '1'
}
# 2. 发送 GET 请求
resp = self.client.session.get(url, params=params)
# 3. 判断响应
if resp.status_code != 200:
raise Exception(fQuery failed with status {resp.status_code})
# 4. 解析 HTML 或 JSON
# 假设教务系统返回的是 HTML 表格，这里简化处理
# 实际项目中建议使用 BeautifulSoup 或 lxml 解析
# 此处仅为演示逻辑流程
if 'course-table' in resp.text:
print(Course data fetched successfully.)
return self._parse_course_table(resp.text)
else:
print(No course data found.)
return []
def _parse_course_table(self, html: str):
解析课程表格
简化版：实际应使用 BeautifulSoup
courses = []
# 示例：正则提取每一行
rows = re.findall(r'tr class=course-row(.*?)/tr', html, re.DOTALL)
for row in rows:
# 提取课程名、学分、教师
name = re.search(r'td class=name(.*?)/td', row)
credit = re.search(r'td class=credit(.*?)/td', row)
teacher = re.search(r'td class=teacher(.*?)/td', row)
if name and credit and teacher:
courses.append({
'name': name.group(1).strip(),
'credit': credit.group(1).strip(),
'teacher': teacher.group(1).strip()
})
return courses
设计亮点：
ensure_login 模式：将登录逻辑与业务逻辑解耦。每次调用查询方法前，先检查登录态。如果 Session 过期，自动重新登录。这提高了脚本的长期运行稳定性。
参数化查询：将 term（学期）作为参数传入，而不是硬编码在 URL 中。这样当学期切换时，只需修改参数，无需改动代码结构。
分层解析：将网络请求与数据解析分开。_parse_course_table 只负责处理 HTML 字符串，不关心网络状态。这使得单元测试更容易编写——你可以直接传入一段静态 HTML 字符串测试解析逻辑，而无需真实访问川农教务网。
应用场景：从教务网到企业级系统
虽然本文以川农教务网为例，但其中的设计思想完全适用于其他企业级系统，尤其是那些基于 SSO（单点登录）或 OAuth2 的内部平台。
自动化测试：在 CI/CD 流水线中，自动化测试脚本需要频繁登录测试环境。使用 requests.Session 封装的客户端，可以快速完成登录并执行 API 测试，比 Selenium 快 10 倍以上。
数据同步：很多公司需要将教务系统中的学生信息、成绩数据同步到数据仓库。通过定时任务运行上述脚本，可以每小时增量拉取最新数据，实现数据自动同步。
个人效率工具：对于学生或教师，可以封装一个命令行工具，输入 python jw_query.py --term 20231 即可导出当前学期所有课程信息为 Excel 文件。
面试高频考点回顾：
Q: 如何处理 HTTP 请求中的 Cookie 管理？
A: 使用 requests.Session 对象，它会自动维护 Cookie Jar，确保在同一个会话中 Cookie 得以保持。
Q: 登录接口返回 302 重定向，如何判断登录是否成功？
A: 检查 Location 头。如果包含业务系统的 URL 且带有 ticket 或 token 参数，通常表示成功；如果跳转到登录页或错误页，表示失败。
Q: 为什么不用 Selenium 而用 requests？
A: requests 更轻量、速度更快、资源占用更少，且不受前端 UI 变更影响。Selenium 适用于复杂 JS 渲染场景，但对于纯 API 交互，requests 是更优解。
你在项目里踩过这个坑吗？比如 CAS 登录的 execution 参数丢失，或者 Cookie 过期导致的 403 错误？评论区聊聊，看看有没有更优雅的解决方案。