动态token必须实时获取，不可硬编码或延时复用；需从html的或中精准提取，再即时注入请求头或表单，配合session保持上下文并避免跨线程共用。
动态Token必须在每次请求前实时获取，硬编码或延时复用基本都会失败。关键不是“识别”，而是“定位来源 + 精准提取 + 即时注入”。
从HTML源码里提取隐藏的CSRF Token
很多网站把Token塞在初始HTML的<meta>或<input type="hidden">里，比如<meta name="csrf-token" content="abc123">。直接用requests.get()拿到页面后，别急着解析JSON——先用lxml.html.fromstring()或BeautifulSoup查DOM。
- 用
xpath最稳：tree.xpath('//meta[@name="csrf-token"]/@content')，返回列表，取[0]即可 - 用
BeautifulSoup注意标签大小写和属性名是否带引号，soup.select_one('meta[name="csrf-token"]')['content']更直观 - 别信浏览器开发者工具里“Elements”面板渲染后的结果——要切到“Response”或“Preview”看原始HTML，否则可能被JS动态改写过
从AJAX响应中提取JWT或自定义access_token
登录成功或调用认证接口后，Token通常藏在JSON响应体的data.token、token或access_token字段里。这时候不能靠正则硬捞，容易错位或漏转义。
- 优先走
.json()解析：resp = session.post(login_url, json=creds); token = resp.json()['data']['token'] - 如果响应是纯文本但结构清晰，再考虑
re.search(r'"token"\s*:\s*"([^"]+)"', text)，但必须加re.DOTALL以防换行干扰 - 注意HTTP状态码：有些接口返回401时也会带
{"error": "...", "token": "xxx"}，别只盯着200处理
用Session保持上下文，避免Token失效
requests.Session()不只是为了复用Cookies——它让Header、Auth、默认参数都自动继承，这对Token流转至关重要。比如服务器下发的X-CSRFToken头，下次请求必须原样带上。
- 初始化Session后，第一时间发一次首页请求：
session.get("https://example.com/")，触发Cookie和初始Token下发 - 提取完Token后，立刻设进Session：
session.headers.update({"X-CSRFToken": token})，而不是每次手动传headers=... - 别在多个线程里共用一个Session实例——Cookies和Header会互相覆盖，要用
threading.local()隔离或每个线程新建Session
绕过JS动态生成的Token（如AES密钥拼接）
有些Token根本不在网络响应里，而是由前端JS运行时计算出来的，比如md5(timestamp + secret)或AES.encrypt(nonce, key)。这时候requests无法执行JS，必须换方案。
- 先确认是否真需要JS执行：用curl或requests抓包对比，如果原始HTML里已有
secret或nonce字段，可能只是Python没写对算法 - 用
execjs或py_mini_racer加载JS上下文，传入HTML里提取的参数，调用对应函数——但要注意Node.js版本兼容性 - 更稳妥的是用
Playwright或Selenium启动真实浏览器，等JS执行完再读page.evaluate("window.token")，虽然慢但可靠
真正难的从来不是“怎么取”，而是“什么时候取、取完立刻用、用完马上换”。Token一旦跨请求复用，或在Session外单独构造请求，大概率触发服务端的时效校验或绑定校验——这些细节不会报错，只会静默返回空数据或403。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
