自动化登录总失败？先排查这 5 处
用脚本走登录流程，最常遇到的情况是：本地手动登录一切正常，脚本跑起来却怎么都不对。页面没报错，接口也没返回异常，就是拿不到登录后的状态。
这种问题九成出在细节上。按下面这 5 处挨个排查，基本都能找到原因。
第一处：登录态到底带上了没有
先确认最基础的一件事：你第二次请求，Cookie 真的带上去了吗。
用 requests 的话，只要用了同一个 Session 对象，它就会自动管理。但如果你中途换了 Session，或者在别的对象里发请求，就等于重新变成了"陌生人"。
importrequests s=requests.Session()r1=s.post(url,data=payload)print(s.cookies.get_dict())# 登录后应该有东西r2=s.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 里把它抠出来，再跟着表单一起提交。
page=s.get(login_page).text token=re.search(r'name="csrf_token" value="([^"]+)"',page).group(1)payload={"user":"demo","pwd":"123","csrf_token":token}如果漏了它，服务器大概率直接拒绝，而且报错还很含糊。
第四处：参数是不是被前端加工过
有些站点的密码，并不是原样提交的。
前端可能在发送前加了一层处理，比如拼上一个时间戳、算一次哈希。这种情况下，你按原密码提交，服务器自然对不上。
排查的办法很简单：打开浏览器的开发者工具，手动登录一次，看真实的请求里，参数长什么样。对照着一改，通常就通了。
我不建议硬猜算法，直接看真实请求，又快又准。
第五处：登录后是不是还有一站
还有一种情况，登录接口其实成功了，但你没意识到后面还有一步。
比如提交之后，服务器返回一个 302，跳转到另一个地址，同时又下发了一次 Cookie。如果你没跟着跳转，或者没处理这次响应，就接不上。
r=s.post(login_url,data=payload,allow_redirects=True)print(r.url)# 看最终落在哪个页面print(r.history)# 看中间经历了哪些跳转另外，偶尔还会碰到人机校验，比如要看图或者拖一下。这类东西设计出来就是给人操作的，用脚本去硬碰，性价比极低。真遇上了，优先想别的正规办法，别在这上面耗。
排查的顺序
别一处一处乱试，按顺序来。
先看登录有没有真的成功，也就是 Cookie 有没有拿到；再看后续请求有没有把证据带上；然后是请求头和那些会变的参数；最后看返回里有没有额外的跳转或校验。
顺着走一遍，问题基本无所遁形。
小结
自动化登录失败，很少是"方法不对"，多半是某处细节没对齐。手动能成、脚本不成，恰恰说明差别就藏在你没注意的地方。
多看真实请求，少凭感觉猜，这类问题会好解决很多。
互动时间：你被哪一处坑过最久？是那个会变的 token，还是请求头不一致？评论区聊聊 👇
声明：本文为原创技术分享，请遵守相关网络协议与法律法规，勿将技术用于任何违规场景。
