写爬虫的爬虫人，迟早会撞上页面跳转这堵墙。页面不是跳转那种点击按钮的跳转，是爬虫HTTP协议里那种301、302、页面或者JavaScript偷偷改地址的跳转玩法。去年我抓一个电商网站的爬虫商品列表，第一版代码跑得好好的页面，第二天突然返回一堆空数据。跳转抓包一看，爬虫服务器回了302，页面Location指向一个登录页。跳转好家伙，爬虫爬虫如果不处理跳转，页面就像开车不看路标，跳转一头扎进死胡同。

Python的requests库默认会跟着302走，但这事没这么简单。它跟是跟了，可有时候会丢header，有时候会丢cookie。我遇到过最坑的一次，是目标网站用302做反爬，每次跳转都生成新的session ID，旧的那个立即失效。requests库傻乎乎地跟着跳，每次请求都带着过期的cookie，结果永远登录不上去。后来我手动禁用了自动跳转，把allow_redirects设成False，自己解析Location头，把新cookie手动塞进下一次请求，才把数据捞出来。

还有一种跳转更隐蔽，藏在JavaScript里。你用requests拿到HTML，里面啥都有，就是没你要的数据。打开浏览器一看，页面先加载一个空壳，然后JS跑一段代码，window.location.replace()把浏览器带到真正的地址。这种跳转requests管不了，因为它根本不执行JS。解决办法要么用Selenium这类真浏览器，要么去翻页面源码里的JS文件，找到那个真实URL。我倾向于后者，因为Selenium太笨重，起一个浏览器实例要好几秒，并发起来能把你机器拖垮。

处理跳转的核心逻辑其实就一句话：看清楚是谁在跳，跳去哪，带什么参数。HTTP跳转看响应头，JS跳转看脚本代码。还有那种meta refresh的，藏在HTML的head标签里，，这种最容易漏，因为requests不会提示你，页面内容看起来正常，但数据就是不对。我写了个通用函数，拿到响应后先检查这三处，发现跳转就递归去抓新地址，设个最大深度防止死循环。

跳转链也能被利用。有些网站故意做多重跳转，中间塞进一些统计参数或者token验证。我碰到过一个老系统，从列表页到详情页要经过五次302，每一步都要更新referer，少一个就拒绝访问。当时我写了个循环，每次请求前用上一次的最终URL做referer，跑了三十分钟，终于把整个链路摸清了。那种感觉，像解一道连环锁，每一步都藏着下一步的线索。

最后说个实战技巧。遇到跳转别急着写死逻辑，先手动用curl命令跑一遍，加上-v参数看完整的响应头和请求过程。curl能显示每一次跳转的细节，比在Python里调试直观得多。我一般先curl摸清规律，再写代码模拟。另外，requests的Session对象要慎用，它虽然能自动管理cookie，但遇到跨域跳转时，有些cookie会被丢掉，反而坏事。该手动时就手动，别太依赖自动化的便利。

爬虫这行，跳转不是技术难点，但它是分水岭。只会跟着默认走的人，遇到反爬就抓瞎。愿意翻协议、看源码、手动模拟的人，才能把那些藏起来的页面数据挖出来。