因为re.search()只处理原始HTML/JS文本，不解析渲染后的DOM，而CSRF token常由JavaScript动态插入或存储在变量中，原始响应体里可能根本不存在该字段，导致匹配失败。
为什么直接用 re.search() 找不到页面里的 csrf_token？
因为网页源码里 token 往往藏在 JavaScript 变量赋值、隐藏 input 或 JSON 字符串中，而正则本身不解析 HTML 结构——它只认字符串。你看到的“页面里有 token”，实际是浏览器渲染后 DOM 的表现，re 处理的是原始 HTML/JS 文本，二者不是一回事。
常见错误现象：re.search(r'name="csrf_token"\s+value="([^"]*)"', html) 返回 None，但浏览器开发者工具里明明能看到该字段——大概率是该 input 是 JS 动态插入的，原始响应体里压根没这行。
- 先确认 token 是否在响应体中：用
requests.get(url).text打印原始内容，搜索关键词（如csrf_token、_token、__RequestVerificationToken） - 若找不到，说明 token 由前端 JS 生成或从 API 单独获取，此时正则无效，得换方案（比如执行 JS 或抓后续请求）
- 若存在，注意转义：HTML 属性值可能含换行、制表符或单引号，建议用
re.DOTALL标志，或改用更宽松的模式如r'csrf_token[^=]*=[\'"]([^\'"]*)'
提取 JS 变量中的 token 要避开哪些坑？
很多站点把 token 存在 var token = "xxx" 或 window.App.token = "xxx" 这类语句里。直接写 re.search(r'var token\s*=\s*"([^"]*)"', js_text) 极易失效。
- JS 中 token 值可能被拼接：
var t = "abc" + "def"，正则无法还原 - 变量名不固定：可能是
_csrf、authenticity_token、antiForgeryToken，需结合页面源码确定真实名称 - 字符串用单引号、反引号或无引号（模板字面量）：
token: 'abc'、token: `abc`、token: abc（后者是变量，非字符串） - 推荐写法：
re.search(r'(?:var|let|const)\s+(\w+)\s*=\s*["\']([^"\']*)["\']', js_text)，先捕获变量名再匹配值，比硬编码变量名更鲁棒
用 re.findall() 提取多个 token 时性能和准确性怎么平衡？
有些页面会埋多个 token（如 form 里一个、AJAX 请求头里一个、meta 标签里一个），re.findall() 看似方便，但容易误匹配。
立即学习“Python免费学习笔记（深入）”；
- 避免过度宽泛：
re.findall(r'[a-zA-Z0-9_-]{20,}', text)会把 UUID、sessionid、甚至邮箱都抓出来 - 优先锚定上下文：比如只搜
<meta name="csrf-token" content="(.+?)">，比单纯匹配长字符串可靠得多 - 注意贪婪匹配陷阱：
.*在跨行文本中可能吞掉太多内容；改用.*?+re.DOTALL，或明确限定字符集如[^">]+ - 如果 token 固定长度且含特定前缀（如
ey...表示 JWT），可加前置校验：r'ey[A-Za-z0-9_-]{10,}'
为什么用 re.compile() 预编译正则能防翻车？
在循环中反复调用 re.search(pattern, text) 时，Python 每次都重新编译正则表达式——不仅慢，而且在多线程下可能触发内部缓存竞争，导致偶发匹配失败。
- 预编译后复用：
token_pat = re.compile(r'<input>]+name=["\']csrf_token["\'][^>]+value=["\']([^"\']*)["\']')，后续直接token_pat.search(html) - 编译时加标志更安全：
re.compile(pattern, re.IGNORECASE | re.DOTALL)，避免漏掉大小写或跨行内容 - 调试技巧：用
token_pat.pattern打印实际正则，对比是否和预期一致；用token_pat.match(text[:200])测试开头片段，快速定位空匹配
真正麻烦的从来不是写对一行正则，而是页面结构微调后，你的正则就 quietly 失效了——留个 print 输出匹配结果，比事后查日志快十倍。
