
自动化登录总失败先排查这 5 处用脚本走登录流程最常遇到的情况是本地手动登录一切正常脚本跑起来却怎么都不对。页面没报错接口也没返回异常就是拿不到登录后的状态。这种问题九成出在细节上。按下面这 5 处挨个排查基本都能找到原因。第一处登录态到底带上了没有先确认最基础的一件事你第二次请求Cookie 真的带上去了吗。用 requests 的话只要用了同一个 Session 对象它就会自动管理。但如果你中途换了 Session或者在别的对象里发请求就等于重新变成了陌生人。importrequests srequests.Session()r1s.post(url,datapayload)print(s.cookies.get_dict())# 登录后应该有东西r2s.get(profile_url)print(r2.status_code)# 不该是 401/403先在登录之后把 cookie 打出来看一眼。如果是空的那就是登录这步就没成后面白搭。第二处请求头齐不齐服务器不一定只看 Cookie请求头里的信息也常被用来判断这个请求正不正常。最常见的是 User-Agent。用脚本发请求默认的 UA 往往直接就暴露了身份。带上一个正常的浏览器 UA能省掉不少麻烦。headers{User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...,Content-Type:application/x-www-form-urlencoded,Referer:https://example.com/login,}还有一点容易忽略登录时带什么头后续请求最好保持一致。别登录用一个 UA请求又换一个前后对不上。第三处表单里有没有会变的参数很多登录表单除了账号密码还会夹带一个隐藏字段。它可能叫 csrf_token也可能是别的名字每次打开页面都不一样。这种字段不能硬编码得先请求一次登录页从返回的 HTML 里把它抠出来再跟着表单一起提交。pages.get(login_page).text tokenre.search(rnamecsrf_token value([^]),page).group(1)payload{user:demo,pwd:123,csrf_token:token}如果漏了它服务器大概率直接拒绝而且报错还很含糊。第四处参数是不是被前端加工过有些站点的密码并不是原样提交的。前端可能在发送前加了一层处理比如拼上一个时间戳、算一次哈希。这种情况下你按原密码提交服务器自然对不上。排查的办法很简单打开浏览器的开发者工具手动登录一次看真实的请求里参数长什么样。对照着一改通常就通了。我不建议硬猜算法直接看真实请求又快又准。第五处登录后是不是还有一站还有一种情况登录接口其实成功了但你没意识到后面还有一步。比如提交之后服务器返回一个 302跳转到另一个地址同时又下发了一次 Cookie。如果你没跟着跳转或者没处理这次响应就接不上。rs.post(login_url,datapayload,allow_redirectsTrue)print(r.url)# 看最终落在哪个页面print(r.history)# 看中间经历了哪些跳转另外偶尔还会碰到人机校验比如要看图或者拖一下。这类东西设计出来就是给人操作的用脚本去硬碰性价比极低。真遇上了优先想别的正规办法别在这上面耗。排查的顺序别一处一处乱试按顺序来。先看登录有没有真的成功也就是 Cookie 有没有拿到再看后续请求有没有把证据带上然后是请求头和那些会变的参数最后看返回里有没有额外的跳转或校验。顺着走一遍问题基本无所遁形。小结自动化登录失败很少是方法不对多半是某处细节没对齐。手动能成、脚本不成恰恰说明差别就藏在你没注意的地方。多看真实请求少凭感觉猜这类问题会好解决很多。互动时间你被哪一处坑过最久是那个会变的 token还是请求头不一致评论区聊聊 声明本文为原创技术分享请遵守相关网络协议与法律法规勿将技术用于任何违规场景。