学到这里，很多人都会有一个明显感受：明明 requests 会写了，BeautifulSoup 也会用了，可一旦换个网站，代码突然就不灵了。地址没错，结构也看着差不多，但返回的内容就是不对。

有时候拿回来的是空白页。 有时候拿回来的是登录页。 有时候明明浏览器能打开，程序却只拿到一段奇怪的提示。 有时候刚开始还能抓，抓着抓着就失效了。

这时候，很多人会觉得是不是自己代码写错了。

有时候确实是。 但还有一种非常常见的可能是：

你碰到反爬了。

所以这一章很重要。

它不是教你去“硬闯”网站。 而是要先把一个现实讲清楚：

互联网里的很多网站，并不是默认欢迎所有程序随便高频抓取的。 它们会通过各种方式识别、限制、引导、过滤请求。

这类机制，统称为反爬虫，或者更常见地叫反爬。

你只有先理解它为什么存在、常见表现是什么、自己写的程序为什么会触发它，后面学请求头、Cookie、登录态、接口分析时，思路才会清楚。

一、什么叫反爬

先别把这个词想得太神秘。

所谓反爬，本质上就是网站为了限制、识别、管理自动化抓取行为，而设计的一系列机制。

你可以把它理解成：

网站在判断，现在来访问我的，到底是一个正常用户，还是一个程序。 如果像程序，它要不要限制。 如果限制，又该怎么限制。

比如有的网站会要求登录后才能看内容。 有的网站访问太快就会报错。 有的网站会校验请求头。 有的网站会把真正数据藏在接口里。 还有的网站会加验证码、签名、动态参数、频率限制。

这些手段，虽然形式不同，但目的很接近：

控制访问行为，保护资源，降低滥抓带来的风险。

所以反爬不是单独某一个技术点。 它更像是一整套网站防护思路。

二、网站为什么要做反爬

这是理解反爬最根本的一步。

很多初学者第一次碰到反爬，会下意识觉得网站是不是故意和程序员作对。

其实从网站的角度看，它做反爬往往有很现实的理由。

第一，保护服务器资源。 如果大量程序高频请求，服务器压力会上升，正常用户体验会受影响。

第二，保护商业数据。 很多网站的数据本身就是它的核心资产，比如商品价格、评论、资讯内容、用户行为数据。

第三，降低恶意访问。 有些程序不是正常采集，而是批量刷接口、撞库、薅资源、盗内容，这对网站来说风险很大。

第四，保证业务规则可控。 有些内容只想给登录用户看，有些只想在 App 里看，有些只想通过官方接口对外开放。

所以你一定要先建立一个正确认知：

反爬不是“网站随机抽风”。 它通常是网站在资源保护、业务控制和风险管理上的正常动作。

有了这个认知，后面你就不会只想着“怎么绕”，而会先思考“为什么它会拦我”。

三、为什么有的网站特别好抓，有的网站特别难抓

这和网站本身的定位、数据价值、访问压力、防护投入都有关系。

比如一个很简单的静态博客，页面就是普通 HTML，访问量也不大，可能几乎没什么复杂限制。 这种网站你用 requests 一抓，源码就回来了。

但如果是电商平台、社交平台、内容平台、票务平台、金融类平台，它们往往更重视数据保护和访问控制。 这时防护通常会明显复杂很多。

所以你后面做爬虫时，会越来越有体会：

不是“爬虫代码会不会写”这么简单。 还得看目标站点的防护强度、内容组织方式、登录要求、请求校验方式。

也就是说，抓不抓得动，不只取决于你会不会 BeautifulSoup。 还取决于对方愿不愿意让你这样拿。

四、反爬最常见的第一种表现：浏览器能看，程序拿不到同样内容

这是最经典、也最容易让新手困惑的情况。

你在浏览器里打开页面，内容明明好好的。 可程序请求回来，却是：

空页面 提示页 登录页 验证码页 或者完全不同的一段内容

为什么会这样

因为浏览器发出的请求，和你最开始写的程序请求，并不是一回事。

浏览器在访问页面时，通常会自动带上很多东西：

请求头 Cookie 缓存信息 来源页信息 浏览器环境特征 有时还会执行 JavaScript

而你最开始写的代码，可能只是最朴素的一句：

response = requests.get(url)

从服务器视角看，这两个请求的“样子”差很多。 它就可能给出不同响应。

所以你一定要理解一个很重要的现象：

地址相同，不代表请求相同。 请求不相同，响应当然也可能不同。

这正是很多“浏览器能开、程序抓不到”的底层原因。

五、反爬最常见的第二种表现：访问频率一高就出问题

这种情况也特别常见。

你测试时，手动跑一两次，程序没问题。 可一旦加到循环里，开始连续请求几十次、几百次，网站就开始不正常了。

比如：

返回 403 返回 429 返回空数据 响应越来越慢 直接断开连接 甚至短时间内整个 IP 都被限制

这背后常见的原因就是频率限制。

网站通常会关注：

单位时间内请求次数 同一个 IP 的访问节奏 同一个账号的访问频率 某个接口是否被异常密集调用

因为真实用户操作不会那么机械、那么高频。 一旦访问模式太像程序，风险信号就会明显上升。

所以你后面写任何网络采集脚本，都要有一个基本意识：

程序跑得动，不代表应该无限快地跑。

对网站来说，过快、过密的请求，本身就可能成为触发限制的原因。

六、反爬最常见的第三种表现：页面源码里根本没有你想要的数据

这也是很多人一开始很容易误判的点。

你用 requests 把页面抓回来，再用 BeautifulSoup 看源码，结果发现：

页面结构在 但正文没有 列表没有 评论没有 价格没有

这时候很多人会以为自己解析错了。

其实还有一种很常见的可能：

你看到的浏览器页面内容，不是直接写在原始 HTML 里的，而是后续通过 JavaScript 动态加载出来的。

也就是说：

浏览器拿到初始 HTML 后，还会继续执行脚本。 脚本再去请求接口。 接口返回数据后，页面才把内容“补上去”。

而 requests 默认拿到的，只是最开始那份响应体。 它不会自动帮你跑前端脚本。

所以这类情况并不一定叫“反爬”本身，但在实际体验上，它常常会让初学者觉得“这个网站怎么不好抓”。

本质上，它是在提醒你：

不是所有页面数据都在 HTML 里。 很多数据其实在接口返回里。

这也正是为什么后面第 118 章要专门讲接口抓取。

七、反爬最常见的第四种表现：必须登录才能看

很多网站的内容不是公开完全开放的。 它可能要求：

先登录 保持登录状态 带上用户身份 或者在特定权限下才能看

这时候你直接请求页面，服务器返回的就不是目标内容，而是：

登录页 未授权提示 权限不足提示 空壳页面

这其实非常常见。

因为网站不只是看你访问哪个地址。 还会看你当前有没有合法身份状态。

而“是否登录”“是否已授权”，很多时候并不写在明面上。 它可能通过 Cookie、Session、Token 等方式保存在请求里。

所以你现在先记住一句话：

很多页面抓不到，不一定是结构复杂。 也可能只是因为这个页面本来就不是匿名可看的。

这一点后面讲 Session、Cookie、登录态时会完整接上。

八、反爬最常见的第五种表现：返回状态码不正常

前面讲 requests 的时候，我们已经说过状态码很重要。

在反爬场景里，状态码更像是一种信号。

比如你可能会遇到：

403，通常表示被拒绝访问 429，通常表示请求过多 302，有时会被跳去登录页或验证页 一些站点还可能返回看似正常的 200，但正文其实是提示页

所以你以后遇到“抓不动”的情况，第一件事别只盯着解析逻辑。 先看：

状态码是什么 最终 URL 是什么 响应体前几百个字符是什么

很多问题，其实从这三项里就能先看出大方向。

也就是说，反爬排查不是一上来就猜。 而是先看返回结果到底长什么样。

九、请求头为什么会和反爬紧紧连在一起

因为请求头是服务器识别请求来源的重要依据之一。

例如浏览器访问网页时，往往会带比较完整的请求头。 而程序最初写出来的请求头，通常很简单。

服务器就会从这些差异里判断：

你像不像正常浏览器 你像不像真实用户请求 你是否缺少必要说明 你是否符合预期访问方式

所以很多初学者第一次碰到反爬时，最先需要建立的一个意识就是：

请求头不只是“附带信息”。 它在某些网站那里，本身就是识别逻辑的一部分。

这也是为什么你后面常常会看到别人说： 先看看浏览器带了哪些头，再决定程序请求要不要补。

不过要注意，理解原理和合规访问很重要。 不要把“补请求头”理解成随便伪装一切就行。 真正稳定的做法，还是先确认目标站点是否允许抓取、是否有公开接口、是否有明确的访问规则。

十、Cookie、Session、登录态，为什么也经常被误认为“反爬”

因为从新手视角看，它们的表现都很像：

为什么我请求同一个页面，结果和浏览器不一样 为什么我明明知道地址，还是拿不到内容 为什么一登录就能看，不登录就不行

这些现象表面上像“网站在拦我”，但它不一定是传统意义上的反爬。 很多时候，它只是正常的身份与会话控制。

比如：

浏览器里你已经登录过了，所以带着 Cookie。 程序里没有这层状态，所以服务器只给你未登录页面。

所以后面你要慢慢学会区分：

有些问题属于真正的反爬识别。 有些问题属于正常权限控制。 有些问题属于前端动态加载。 有些问题属于请求本身不完整。

它们表面都像“抓不到”，但底层原因并不一样。

这一章的意义，很大一部分就在这里： 先帮你把这些现象拆开，不要一股脑全叫“反爬”。

十一、为什么验证码会被很多人第一时间想到

因为验证码最显眼。

比如你访问页面时突然看到：

滑块验证 图片验证码 点选验证 行为验证页

这当然是反爬的一种典型表现。 但你也不要以为“有验证码才叫反爬”。

事实上，很多更常见的限制并不那么显眼。 比如频率限制、UA 检查、Referer 校验、动态参数、登录态校验，这些都可能在你还没看到验证码之前，就已经让程序拿不到内容了。

所以验证码只是反爬里最直观的一类。 不是唯一一类，也不是最早出现的一类。

对初学者来说，更重要的是先知道：

反爬不一定长得像一道大门。 它很多时候更像很多层小门槛。

你可能不是被“一下子挡死”。 而是被一层层限制，直到结果变得不对。

十二、JavaScript 动态加载和反爬，为什么经常一起被提到

因为从实际效果上看，它们都可能导致：

你用 requests 抓回来的页面，没有目标数据。

但两者还是要分清。

动态加载更偏向“内容获取方式变了”。 也就是数据不是直接写在 HTML 里，而是后续通过接口补上。

反爬更偏向“网站在识别和限制访问行为”。

它们当然可以叠加。 比如一个网站既用动态加载，又对接口做访问控制。 这时新手就更容易困惑。

所以你以后排查网站“为什么不好抓”时，可以按这个顺序想：

是不是 HTML 里本来就没有数据 是不是需要登录态 是不是请求头不完整 是不是访问太频繁 是不是被限制或跳转了

这样比一上来笼统地说“被反爬了”更清楚。

十三、站在程序员角度，遇到“抓不到”时该先做什么

最忌讳的做法，就是一抓不到就开始乱改代码。

更稳的排查顺序通常是：

先看状态码 再看最终 URL 再看响应体前一部分内容 再确认浏览器里目标数据到底来自 HTML 还是接口 再确认是否需要登录状态 再看请求头差异 最后再思考访问频率问题

也就是说，先诊断，再处理。

很多网站“抓不到”的原因，其实很朴素。 并不是一定遇到了多么高深的防护。 有时候只是：

请求太简陋 数据根本不在 HTML 里 页面本来就需要登录 或者你抓得太快了

所以写爬虫的时候，排查能力比盲目抄代码更重要。

十四、为什么我一直强调“先理解，不要先想着绕”

因为这是非常关键的方向问题。

如果你一上来就只想着怎么避开限制，很容易变成：

不知道问题是什么 也不知道网站规则是什么 只会机械复制一些网上片段化代码

这种方式通常既不稳，也不安全。

更好的顺序应该是：

先确认这个网站是否允许抓取 先看有没有公开 API 或数据接口 先评估访问频率和数据规模 先搞清楚页面机制 在合规、克制、尊重规则的前提下去做采集

很多时候，最好的解法根本不是“硬抓”。 而是：

官方接口 开放数据 导出功能 RSS 站点地图 授权合作方式

所以你要慢慢建立一种专业意识：

不是一切技术问题都要靠强行突破。 很多时候，先看规则、看边界、看有没有更合适的路径，才是更成熟的做法。

十五、反爬不是只影响爬虫，它其实也在影响正常产品设计

这一点你现在可以先有个印象。

将来如果你自己做网站、做接口、做后台，其实也会碰到类似问题：

怎么避免接口被刷 怎么限制异常流量 怎么保护关键数据 怎么避免资源被无节制抓取 怎么区分正常用户和程序访问

也就是说，反爬并不只是“对方为难我”。 它其实也是很多产品和系统设计中的正常部分。

你今天站在采集者角度学它。 以后也可能站在服务提供方角度重新理解它。

所以这一章的价值，不只是给你解释为什么有些网站不好抓。 更是在帮你理解，互联网系统为什么要做访问控制。

十六、把常见原因整理一下，你就会更有全局感

很多网站“不好抓”，常见原因大致可以归到下面这些类型：

请求太简单，和浏览器差异大。 页面内容通过 JavaScript 动态加载，不在原始 HTML 里。 资源本来就要求登录后访问。 访问频率过高，被限流。 某些关键请求需要额外校验。 网站做了行为识别、验证码或其他验证。

你会发现，这里面并不是只有“拦截”。 还有很多是“数据组织方式变化”或者“权限控制”。

所以遇到问题时，千万别只会说一句： 这个网站反爬很厉害。

更专业的说法应该是：

它的内容是动态加载的。 它要求登录态。 它对请求头比较敏感。 它有频率限制。 它可能有访问校验。

一旦你能这样描述问题，后面处理起来也会更有方向。

十七、对初学者来说，这一章最该掌握的到底是什么

不是记住十几种反爬手段的名字。 也不是上来就研究复杂绕法。

真正重要的是三件事。

第一，建立正确认知。 很多网站不好抓，不一定是你代码太差，而是它本来就有访问控制。

第二，学会分类判断。 是动态加载、登录要求、频率限制，还是请求特征问题，不要全都混叫成反爬。

第三，建立排查顺序。 先看返回结果，再分析原因，不要一上来就乱改。

只要这三点你真正建立起来，后面学 Cookie、Session、接口分析时，就会顺很多。

十八、初学者在这一章最容易踩的坑

第一个坑，是把一切“抓不到”都叫反爬。

结果动态加载、登录问题、接口变化、结构写错，全都混在一起，排查永远没方向。

第二个坑，是完全不看响应内容。

状态码不看，最终 URL 不看，响应体前几百个字符也不看，只会说“程序没抓到”。

第三个坑，是访问频率没有概念。

以为程序跑得越快越好，结果自己把自己送进限制里。

第四个坑，是只想抄现成方案，不想先理解网站到底在做什么。

这样短期也许能碰运气跑通一次，但很难真正稳定。

第五个坑，是忽视合规边界。

这点非常重要。 技术能力越往后走，越不能只看“做不做得到”，还要看“该不该这样做”。

十九、你现在应该开始有的一个新意识

从这一章开始，你面对网页时，不应该只问：

这个页面怎么抓

你还要多问几句：

这个页面的数据是直接写在 HTML 里的吗 它是不是要求登录 它的返回内容为什么和浏览器不一样 是不是请求里少了关键信息 是不是访问方式太像程序了

一旦这些问题开始进入你的脑子里，你看网页的角度就已经变了。

你不再只是一个“会写 requests 的人”。 你开始慢慢具备分析网络访问行为的能力了。

这一步很关键。

本章小结

反爬，本质上是网站为了识别、限制、管理自动化抓取行为而设计的一系列机制。

网站做反爬，通常是为了保护服务器资源、保护商业数据、降低恶意访问风险、维持业务规则可控。

对初学者来说，最重要的不是立刻研究各种复杂绕法。 而是先理解：

为什么有些网站浏览器能看、程序却抓不到 为什么有些页面内容并不直接写在 HTML 里 为什么有些资源必须登录后才能访问 为什么访问太快会触发限制

也就是说，很多“抓不到”的现象，背后原因并不相同。 你要学会把动态加载、登录要求、请求特征、频率限制、真正的反爬机制区分开来看。

当你真正建立这套理解后，后面再学 Cookie、Session、接口抓取、爬虫实战，就会有非常清楚的方向。

课后思考

第一，试着回想一个你曾经“浏览器能看、程序抓不到”的页面，想想它更可能是哪一类原因。

第二，自己总结一下：动态加载、登录要求、频率限制，这三种情况表面都像“抓不到”，它们底层到底有什么不同。

第三，试着用自己的话解释： 为什么说反爬不只是技术问题，很多时候也是网站的资源保护和业务控制问题。