企业官网建设流程全解析

被反爬折磨过的人，大概率都见过这样的页面：明明浏览器里一切正常，requests 一上去就给你一个 403；或者状态码 200，返回内容却是一堆看不懂的 JavaScript 拼接逻辑；再或者采集脚本刚跑几十条，滑块验证就弹了出来。这些情况我刚开始写 Python 爬虫的时候全部踩过，每一种都让我怀疑自己是不是入错了行。后来被虐的次数多了，慢慢沉淀出三个实测有效的处理思路：请求头伪装、请求节奏控制、动态渲染兜底。这篇文章把这套方法完整拆开，每一步都带上可直接参考的代码和踩坑记录。需要先说明的是，这里讨论的所有内容都只面向公开的正常数据采集，动手之前建议先看目标网站的 robots.txt，同时把请求频率控制在合理范围内，不要给目标服务器造成压力。

1. 别急着上方案，先判断反爬到底拦在哪里

1.1 同样是反爬，背后的拦截逻辑完全不一样

反爬不是一套统一的系统，而是由各种检测逻辑组合出来的结果。我习惯把常见的拦截方式分成三类。第一种是请求头检测，目标服务器会检查 User-Agent、Referer、Accept-Language、Accept 等字段，只要发现请求头里的内容跟真实浏览器的差距太大，就直接拒绝。第二种是频率限制，服务器统计某个 IP 在单位时间内的请求次数，超过阈值就会触发 403、429 或者验证码。第三种是动态渲染，页面关键数据并不是直接写在 HTML 源码里的，而是通过 JavaScript 请求接口后动态拼装出来的，这种场景下，你用 requests 看到的 HTML 只是一个空壳。

这三类反爬经常会叠加出现，所以第一步不是急着写代码，而是先判断当前遇到的是哪一类。判断错了，后面所有优化都是白费。比如你用很长一段代码实现了随机延时，结果问题出在请求头没有伪装，那封禁依然会持续。反过来也是一样，你花了很多时间去做渲染，结果页面只是简单做了 UA 校验，反而把采集速度拖慢了几十倍。这也是为什么我在项目里会先做一轮探测，而不是直接套模板。

判断反爬类型时，还可以顺手记录一个细节：返回内容里有没有明显的验证页面关键字。比如captcha、verify、slider这类单词，出现频率越高，说明目标站点的风控策略越重。不要试图去破解验证码，只要识别到这些特征，就先停下来降低频率，或者考虑换一个入口。技术上能绕过去是一回事，规则上能不能做是另一回事。

1.2 用最小探测代码摸清目标底细

我建议所有爬虫项目都先写一个最小探测脚本，把目标 URL 的响应状态、响应头、响应体长度和内容片段全部打印出来。这样你才能根据实际反馈做判断，而不是靠感觉。下面这段代码可以直接抄走：

import requests url = "https://example.com/list" headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 " "(KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36" } resp = requests.get(url, headers=headers, timeout=10) print("状态码:", resp.status_code) print("Content-Type:", resp.headers.get("Content-Type")) print("响应体长度:", len(resp.text)) print("响应体前500字:", resp.text[:500])

跑完这段代码后，你可以按下面几个关键特征去归类。如果状态码直接是 403 或者 418，大概率是请求头部检测没有通过。如果状态码是 200，但响应体里没有任何跟目标数据相关的关键字，而是出现大段<script>标签，那就说明数据是动态渲染的。如果状态码先是正常，跑了一会儿之后突然变成 429 或者 503，那就是触发了频率限制，又或者你的出口 IP 已经被临时封禁。

出口 IP 这个概念需要单独说一下：它指的是你当前访问目标服务器所用的公网地址。同一个公网地址在一段时间内发出太多请求，很容易被服务商标记。换一个公网地址往往能解决一部分问题，但这不是银弹，后面第三部分会展开讲。现阶段你只需要先理解，判断反爬的核心思路是“差异比对”：用命令行请求一次，再用浏览器打开同一个地址，对比返回结果差异在哪里，差异就是反爬的切入点。

另外，我强烈建议把浏览器开发者工具里看到的真实请求头完整保存下来。做法是打开 Network 面板，刷新页面，找到第一个文档请求，右键复制为 cURL，然后把它转成 Python 字典。这样做的好处是，你能拿到浏览器真实的 Header 顺序和值，而不是网上抄来的旧模板。反爬系统对 Header 的匹配程度通常很敏感，真实请求作为对照标准，比自己拍脑袋写得要准确得多。

2. 第一个实用技巧：把请求头伪装得像真人，而不是代码

2.1 基础请求头：不是只改一个 User-Agent

很多初学爬虫的朋友一提到反爬，第一反应就是改 User-Agent。这个方向没错，但只做这一件事远远不够。目标服务器除了看 User-Agent，还会看请求头里有没有奇怪的字段缺失，以及字段值的组合是否符合真实浏览器的行为。这里我列一个日常爬虫中比较常见的基础请求头配置，你可以根据自己的场景调整。

把这些字段都带上之后，你的请求从“看起来像代码”变成了“看起来像浏览器”。但要注意，这些字段不是万能的，部分网站会校验收紧关系，比如 Referer 必须匹配当前页面域名，或者 Sec-Fetch-Site 值与实际跳转路径不一致就拒绝。所以第一次写请求时，最好先打开浏览器开发者工具，切到 Network 面板，找到真实请求的 Headers 区域，然后把自己 request 里的 headers 调整成和浏览器完全一致。

这里我提醒一个容易忽略的细节：不要每次都随机更换 User-Agent，尤其是没有维护合理 UA 列表的时候。随机拼接出来的 UA 经常会因为没有版本对不上号而更可疑。更好的做法是准备五到十个真实浏览器的 UA 字符串，然后在需要切换时轮换使用。这样既不会因为同一个 UA 太显眼，也不会因为 UA 格式乱套触发额外检测。

还有一个不少教程不会提的小点：请求头的顺序。在 HTTP 协议层面，头部顺序理论上不重要，但不少网站会把请求头发送给后端的风险控制组件做模式匹配，而风险控制组件可能直接按“浏览器常见顺序”来判断。你可以在前面保存的 cURL 命令里看到浏览器发送 Header 的真实顺序，然后用一个OrderedDict或 Python 3.7 以上的字典结构来维持这个顺序。实测中，这种细节有时候能帮你在某些严格网站上少踩很多坑。

2.2 用 Session 保持 Cookie，先访问首页再访问目标页

很多反爬逻辑会校验 Cookie 的有效性，尤其是你直接请求一个内页地址，而服务器认为你没有经历从首页跳转过来这个流程，Cookie 缺失就会拒绝。解决办法很简单：用requests.Session()创建一个会话对象，先请求一次首页拿到初始化 Cookie，再带着同一个会话请求目标页。代码大概是下面这样。

import requests session = requests.Session() session.headers.update({ "User-Agent": "Mozilla/5.0 ...", "Accept-Language": "zh-CN,zh;q=0.9", }) # 先访问首页，让服务端种下基础 Cookie home_url = "https://example.com/" session.get(home_url, timeout=10) # 再访问目标页面 target_url = "https://example.com/list" resp = session.get(target_url, timeout=10) print(resp.text[:300])

这种做法的本质是模拟真实用户从入口进入站点的浏览路径。有些网站还会根据浏览路径生成加密标识，如果一上来就直捣黄龙，缺少前置页面访问，即便 Cookie 里多了几个字段，也可能因为某个参数的时间戳对不上而被识破。用 Session 统一管理 Cookie，可以避免很多不必要的头疼。

需要留意的是，Session 对象默认会帮你保存 Cookie，但如果你在中间使用了session.cookies.clear()或者重新创建了 Session，就必须重新走一遍首页访问流程。我在实际项目里会写一个init_session()函数，专门负责创建 Session 并完成前置访问。这样后面不管重试多少次，都能保证每次重试都带着完整的 Cookie 状态，而不是拿一个残缺的会话去请求。

2.3 进阶：TLS 指纹和 HTTP/2 指纹

请求头伪装做到一定程度，你会发现有些网站依然能识别出你是脚本。这种时候往往不是 Headers 的问题，而是底层连接指纹的问题。正常浏览器在建立 TLS 连接时，会有一套特定的加密套件顺序和扩展列表；requests 底下的 urllib3 库则有另一套顺序。这种差异被称为 TLS 指纹。服务器可以在不解析请求头的情况下，仅凭连接握手阶段的指纹判断对方不是浏览器。

遇到这种情况，我平时的做法是引入curl_cffi这个库，它能模拟 Chrome 等浏览器的 TLS 指纹，并且支持 HTTP/2。安装命令是：

pip install curl_cffi

一个简单的请求示例是：

from curl_cffi import requests as cffi_requests resp = cffi_requests.get( "https://example.com/list", impersonate="chrome", timeout=10 ) print(resp.status_code) print(resp.text[:300])

impersonate="chrome"会直接模拟 Chrome 浏览器的连接特征，很多普通 requests 搞不定的网站，换成这个库之后就能正常返回。不过我不会一上来就建议你用它，因为你得先确认基础 Headers 和 Cookie 都已经处理正确。如果前面没有做好，直接换库也只是把问题往后推了一级。总之，这个技巧属于第二梯队，它解决的是更底层的问题，在日常项目中可以作为备用招数。

这里也要插一句：curl_cffi的模拟能力并不是无限期的，浏览器版本更新后，旧的指纹模拟可能失效。所以使用这类库时，要关注它的更新日志，定期升级到支持新浏览器版本的版本。爬虫本身就是一场持久战，工具也要跟着环境走。

3. 第二个实用技巧：控制请求节奏，让服务器觉得你不是机器

3.1 固定延时和随机延时的本质区别

爬虫采集数据时最容易犯的一个错误就是把循环写得非常紧凑，每一条请求之间只间隔 0.1 秒甚至更快。这样采集速度虽然好看，但服务器端的数据模型非常容易识别出规律。固定延时虽然会好一点，比如每次 sleep(1)，但在模型看来，这种间隔太规律了，同样有特征。真实用户浏览页面的速度有快有慢，不可能每次都精确卡在同一个时间点上。

所以更合理的做法是让延时服从一个随机区间。比如每次请求后等待random.uniform(1.5, 4.5)秒。这样服务器看到的请求间隔会呈现出自然波动，不容易被简单规则一下子判断出来。下面这段代码演示了在循环里抓取多页时的基础节奏控制。

import time import random for page in range(1, 11): url = f"https://example.com/list?page={page}" resp = session.get(url, timeout=10) print(f"第{page}页，状态码：{resp.status_code}") time.sleep(random.uniform(1.5, 4.5))

这里有一个很有意思的细节：区间两端最好不要选整数。比如random.uniform(1, 3)虽然也是区间，但看起来还是太规整。我一般会写成random.uniform(1.7, 4.3)这类带小数的上下限，让随机出来的数更自然。另外，随机函数每次运行之间的间隔会有一定概率出现连续两次很短或很长的情况，这种波动其实是好事，因为人类行为本身就充满了突发性。

如果你的目标站点是内容型网站，用户浏览一页很可能要花几秒甚至十几秒，那么延时设置在 1 到 3 秒之间其实是偏快的，长期跑一样会被识别。可以适当把区间放大到 3 到 8 秒。如果只是临时抓取几十条数据，那就无所谓，重点别一口气把几千个请求全砸出去。延迟不是越慢越好，而是越真实越好。跑完一轮后，把实际耗时记录下来，能帮你判断当前节奏是否符合要求。

3.2 带退避的重试机制

反爬不是每次都直接给你返回 403 让你发现，更多时候是偶尔成功、偶尔失败，甚至会在返回内容里夹带一个怪异的验证页面。所以请求函数里必须包含重试和异常处理逻辑。重试不是简单的“失败就再来一次”，而是要带上退避策略，也就是第一次失败后等 2 秒再试，第二次失败后等 4 到 6 秒，第三次失败后等待更久。这样一方面给服务器留出恢复时间，另一方面也避免失败后立刻疯狂重试导致被封得更狠。

下面是我常用的一个带退避重试的请求函数。

import requests import time import random def get_with_retry(session, url, max_retries=3): for attempt in range(max_retries): try: resp = session.get(url, timeout=10) if resp.status_code in (403, 429): wait_time = random.uniform(2, 5) * (attempt + 1) print(f"请求被限流，状态码：{resp.status_code}，{wait_time:.1f}秒后重试") time.sleep(wait_time) continue return resp except requests.RequestException as exc: wait_time = random.uniform(1, 3) * (attempt + 1) print(f"请求异常：{exc}，{wait_time:.1f}秒后重试") time.sleep(wait_time) return None

注意这个函数里对 403 和 429 做了特殊处理。如果返回 200，就直接返回响应对象；如果返回其他状态码，比如 404，说明不是反爬问题，没有重试必要，直接返回即可。很多新人喜欢对所有异常都重试，结果网站明明没有该页面，还在那里反复请求，效率非常低。正确做法是只对限流和具有临时性的连接异常做重试。

退避间隔为什么要乘上(attempt + 1)？本质上是让等待时间随重试次数指数增长。第一次等 2 到 5 秒，第二次等 4 到 10 秒，第三次等 6 到 15 秒。这个设计借鉴了网络领域里的指数退避思想，目的是在“不放弃请求”和“不给服务器加压”之间找一个平衡点。如果重试到第三次仍然失败，我会认为当前出口 IP 可能已经被重点关照，这时候再继续重试意义不大，应该进入换 IP 流程。

3.3 什么时候需要换出口 IP，以及怎么换

频率控制做到位之后，依然有可能会碰到 IP 被临时封禁的情况。判断标准其实不难：当你的请求一直返回 403 或 429，而且换了不同的 User-Agent、清了缓存、等了很久都没恢复，大概率就是出口 IP 被目标服务器限制了。这种情况下，最直接的办法是换一个出口 IP。

具体怎么操作？常见做法是准备一组出口 IP 资源，在请求失败时自动切换下一个。你可以在云服务商那儿购买按量计费的弹性公网 IP，也可以使用拨号服务器在每次拨号后获得新地址，还可以找专门提供住宅 IP 资源的服务商。不过这里必须提醒一句：任何 IP 切换方案都要在法律和平台规则允许的范围内使用，如果你抓取的是公开数据，并且目标网站没有明确禁止，控制好频率和量级通常问题不大。如果目标网站服务条款明确禁止采集，那就不要抱有侥幸心理。

代码层面，你可以在get_with_retry外面再包一层逻辑，当重试次数用尽时，调用一个“切换 IP”的函数，然后用新的出口地址重新请求。这个切换函数根据你的资源类型来实现，比如调用云服务商的 API 更换公网地址，或者重启拨号网络。把这个动作和重试逻辑分开，代码会清晰很多，也不会因为频繁切换而误伤正常请求。

提示：IP 资源池不是越多越好。你发出请求的出口 IP 如果频繁变化，反而容易被更高层级的风险控制盯上。保持每个 IP 的请求量在合理范围，比单纯拥有大量 IP 更重要。

还要记住一个容易踩的坑：切换出口 IP 之后，原来 Session 里保存的 Cookie 不一定还能继续使用。因为 Cookie 里可能包含了 IP 维度的绑定信息，如果 IP 变了而 Cookie 没变，部分网站会直接判定为异常。所以切换 IP 后，我通常也会重新建立 Session，重新走一遍首页访问流程，确保新 IP 和新的 Cookie 状态是匹配的。这样看起来才像是一个全新的用户，而不是同一个脚本换了个马甲。

4. 第三个实用技巧：动态渲染页面就让浏览器替你干活

4.1 当 requests 拿不到数据时，别急着啃 JS

动态渲染的反爬方式，在很多现代网站里非常常见。你打开浏览器能看到完整列表，但用 requests 抓回来的 HTML 里根本没有这些数据，只有一段又一段的 script。原因是数据通过接口异步加载，然后由 JavaScript 动态创建 DOM 节点。面对这种情况，很多人的第一反应是去逆向分析 JS，找到加密函数，然后手动模拟生成参数。这个方法不是不行，但成本很高，而且一旦目标网站更新 JS 逻辑，之前的破解代码立刻作废。更高效、也更不容易出错的思路是：让一个真正的浏览器去加载并渲染这个页面，渲染完成后再从 DOM 里取数据。

这就是无头浏览器的用途。所谓无头浏览器，就是一个没有界面的完整浏览器内核，它会像真实浏览器一样执行 JavaScript、发送异步请求、等待资源加载。我们只需要通过自动化库去控制它打开页面、等待内容出现、然后提取 HTML。网络请求层面的反爬，大多数情况下对它无效，因为服务器看到的就是一个标准浏览器。

怎么判断一个页面是不是动态渲染？最简单的方法是在 Network 面板里勾选 Fetch/XHR，刷新页面，看有没有额外的异步接口为页面提供数据。如果有，并且这些接口返回的数据格式不是直接的 JSON，而是经过加密的内容，那就别费劲分析了，直接上浏览器渲染。当然，如果接口返回的是干净的 JSON，那直接用 requests 请求这个接口会快得多，没必要上浏览器。判断的核心是“成本对比”，哪种方式实现的成本低、维护简单，就用哪种。

4.2 Playwright 最小可用流程

在几个浏览器自动化库里面，我用得最多的是 Playwright。相比 Selenium，它的 API 更现代，等待机制更可靠，启动速度也更快。安装其实很简单，只需要执行两行命令：

pip install playwright playwright install chromium

第一行是安装 Playwright 库，第二行是下载 Chromium 浏览器内核。下载过程中可能会稍微慢一点，耐心等待即可。装完之后，下面这段代码就可以跑起来，打开一个动态页面并输出渲染后的 HTML。

from playwright.sync_api import sync_playwright def render_page(url): with sync_playwright() as p: browser = p.chromium.launch(headless=True) page = browser.new_page() page.goto(url, timeout=60000) # 等待某个关键元素出现，比固定 sleep 更可靠 page.wait_for_selector(".list-item", timeout=10000) html = page.content() browser.close() return html html = render_page("https://example.com/list") print(html[:500])

这段代码里最核心的是wait_for_selector。它会让页面一直等待指定的 CSS 选择器出现，最多等 10 秒。如果页面数据是异步加载的，这个等待机制可以有效避免你拿到还没渲染完成的空白页面。不要让程序盲目地 sleep 几秒就开抓，那样既浪费时间，又容易在目标页面网络变慢时抓不到数据。等待选择器，比任何固定延时都更符合真实渲染时序。

如果你想从渲染后的页面里提取具体内容，可以继续用 Playwright 的 locator 接口。比如抓一个列表里所有条目的标题，可以这样写：

items = page.locator(".list-item") for i in range(items.count()): title = items.nth(i).locator(".title").inner_text() print(title)

这种取值方式比正则表达式解析 HTML 要稳定得多。只要页面结构不变，代码基本不用改。如果你需要翻页，可以在循环里调用page.goto，也可以点击页面底部的“下一页”按钮。一般来说，直接修改 URL 参数翻页更快，也更不容易被前端逻辑干扰。

4.3 渲染模式下的降速与异常处理

用浏览器渲染抓取，虽然能解决动态内容的问题，但效率通常比纯 requests 低很多。因为浏览器要加载图片、样式、脚本，资源消耗非常大。所以我在实际项目中一般遵循一个原则：能用 requests 拿到的数据，绝不轻易上浏览器；只有确认数据是异步渲染，或者接口请求需要复杂的 JS 生成参数时，才把 Playwright 请出来。

如果你确实需要循环抓取多个页面，那要注意浏览器的资源管理。下面的示例里，我不会每次循环都重新启动浏览器，而是复用同一个浏览器实例，只新建或切换页面，这样速度会快很多。

from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch(headless=True) page = browser.new_page() for page_num in range(1, 6): url = f"https://example.com/list?page={page_num}" try: page.goto(url, timeout=60000) page.wait_for_selector(".list-item", timeout=10000) items = page.locator(".list-item").count() print(f"第{page_num}页抓到 {items} 条数据") except Exception as exc: print(f"第{page_num}页出错：{exc}") # 适当停顿，给浏览器和服务器一点喘息时间 page.wait_for_timeout(2000) browser.close()

这里我用了固定 2000 毫秒的停顿，目的是给目标服务器和本地浏览器一个缓冲。你也可以在循环里随机 sleep 更长的时间。遇到单页异常时，try/except可以保证整个循环不会因为一个页面报错就中断。把错误信息打出来，方便后续排查。

还有一个细节：如果使用 Playwright 自动打开开发者工具或用headless=False的非无头模式调试，请避免在正式运行环境中长期这样操作，因为在有界面的浏览器里，可能出现人工干预弹窗、无法自动关闭等问题。我通常只在调试阶段用headless=False，正式采集全部切回headless=True。

此外，用 Playwright 连续抓取几十个页面后，浏览器进程可能会吃掉大量内存。如果发现系统越来越卡，可以在循环里定期关闭当前页面，再开一个新页面，或者直接重启浏览器实例。不要觉得这是浪费，内存溢出导致的半途而废，往往比慢一点更耽误时间。

5. “90%都能绕过”是错觉，但这三点能让你少被虐

5.1 为什么不存在一个万能技巧

你可能在不少文章里看到过“90% 的反爬都能轻松绕过”这种说法。我自己写爬虫这么多年，对这种话基本是打折扣看的。反爬是一个持续对抗的过程，目标网站会根据攻击特征不断调整检测策略。你今天靠请求头伪装绕过了，明天对方可能加入 TLS 指纹校验；你今天用无头浏览器渲染解决了动态内容，明天可能对方的脚本开始检测浏览器自动化特征。不存在一个一劳永逸的技巧，能让你永远不碰到反爬。

但反过来讲，上面这三个技巧组合起来，确实能覆盖绝大多数常见反爬场景。请求头伪装解决的是“你是不是脚本”的问题，请求节奏控制解决的是“你是不是太贪心”的问题，动态渲染解决的是“你能不能拿到渲染后页面”的问题。三者对应着不同层面的拦截，组合使用时，能处理掉我日常遇到的大部分反爬情况。我更愿意把它理解成一个基础工具箱，而不是“万能钥匙”。

我见过不少新人的做法是，遇到反爬就疯狂找开源库，想把所有反爬都“绕”过去。这种心态反而容易陷入工具竞赛。反爬技术升级的速度永远比单一工具快，真正有效的策略是把你手头的这几个基础能力打磨好，然后根据目标网站的反馈灵活组合。有时候最简单的 Headers 伪装加合理延时就能解决，根本不需要上浏览器。技术选型越贴近问题本质，后期维护就越省心。

5.2 爬取前的合规自检清单

无论标题怎么吸引人，我都建议在动手之前先按下面的清单过一遍。这不是为了让你束手束脚，而是为了让你长期跑数据的过程中少一些风险，也更尊重目标网站。

这张表是我每次接手新采集需求时都会对照的。尤其是 robots.txt 这一项，很多人会忽略，但它能帮你避开很多不必要的麻烦。如果目标网站明确禁止爬取，那就换公开数据集或者寻找其他合法来源。技术上能做到的事，不代表你应该去做。

另外，采集到的数据如果用于发布文章、做数据分析、训练模型，还要注意数据的版权归属和用户隐私。就算数据本身是公开的，也不代表你可以随意二次传播。特别是在做数据清洗和存储的时候，建议只保留必要的业务字段，不要把所有原始内容一股脑存下来。减少数据冗余，既是对他人的尊重，也是给自己降低合规压力。

5.3 一条写在最后的个人经验

如果你是一个刚开始学爬虫的开发者，我的建议是不要一上来就追求最复杂的对抗方案。先把前面三个技巧练熟，在日常项目里积累对反爬特征的判断能力。遇到问题时，用最小脚本去探测，根据响应状态和返回内容逐步调整，而不是盲目叠加各种库和参数。写爬虫真正的乐趣不是“破解”某个网站，而是通过观察、分析、验证，找到一套符合自己使用场景的可持续方案。我的经验是，带着“尽量不给服务器添麻烦”的心态去写代码，反而能在反爬对抗中走得更远。

最后再分享一个小技巧：每次采集任务结束后，把当时的反爬特征、应对方案、响应状态码和最终效果记到一个简单的日志文件里。下次再碰到类似网站，翻一翻历史记录，很多问题都能直接找到参考方案。我靠这个习惯省下过大量重复排查的时间，也慢慢锻炼出了对反爬策略的判断直觉。希望这篇分享也能帮你少走一些弯路。