怎么处理JavaScript渲染页面？Python+Selenium动态网页抓取入门

Cora

发布时间：2026-10-26| 7人浏览过

原创

在编写爬虫抓取网页数据时，如果发现用 requests 请求返回的 HTML 源码中缺少目标文本，而浏览器页面上却清晰可见，这通常是因为页面依赖前端 JavaScript 进行异步加载与动态渲染。处理这类页面的核心路径主要有两种：一是通过浏览器开发者工具直接逆向并请求底层数据接口（API）；二是使用自动化测试工具驱动真实的浏览器引擎解析并执行脚本，直接获取渲染完成后的 DOM 树。本文围绕第二种方案，详细讲解使用 Python + Selenium 进行动态网页抓取的基础原理、环境搭建、等待机制、核心代码实操以及常见的性能与避坑要点。

一、为什么常规抓取方法会“抓空”？

传统的网络爬虫通常使用 requests 或 urllib 库向服务器发起 HTTP GET 请求。服务器返回的响应是静态的 HTML 文本。在早期的网站架构中，服务端直接将数据库中的内容拼接进 HTML 模板中返回给客户端，爬虫直接解析这段 HTML 即可提取所需文本。

然而在现代 Web 应用中，普遍采用了诸如 Vue、React 或 Angular 等前端单页面（SPA）框架。当爬虫发起 GET 请求时，服务端返回的仅仅是一个仅有基础结构的“空壳”HTML，主体数据区域往往只有一个空的容器标签（如 <div id="app"></div>）以及若干个 JavaScript 脚本引入标签。

浏览器在加载这个骨架后，会接着下载并执行其中的 JavaScript 脚本。脚本通过 fetch 或 XMLHttpRequest 向后端异步请求真正的业务数据，再通过 DOM 操作将数据渲染成用户可见的列表、卡片或表格。由于 requests 只是一个 HTTP 通信客户端，它不具备 JavaScript 解释器（如 Chrome 的 V8 引擎），无法执行前端脚本，因此拿到的是未渲染的骨架页面，自然无法提取到目标数据。

怎么处理JavaScript渲染页面？Python+Selenium动态网页抓取入门

图 1：传统 HTTP 抓取与动态浏览器渲染抓取的执行链路差异

二、环境准备与驱动管理机制

在过去，使用 Selenium 驱动浏览器（如 Google Chrome）需要在本地下载与当前浏览器版本完全一致的二进制驱动文件（例如 chromedriver.exe），并手动将其路径添加到系统环境变量中。一旦浏览器自动升级，驱动便会因为版本不匹配而报错。

从 Selenium 4.6.0 开始，官方内置了 Selenium Manager 机制。当 Python 代码初始化浏览器实例时，Selenium 会自动检测当前机器安装的浏览器版本，并由底层驱动管理器静默下载对应版本的驱动，开发者不再需要手动寻找、下载和配置驱动路径。

在终端中执行如下命令安装 Selenium 最新稳定版：

pip install selenium

安装完成后，确保本地已经安装了主流的 Chrome 浏览器。通常在无图形化界面的服务器或后台自动化抓取任务中，我们还会为浏览器配置“无头模式”（Headless Mode），这样浏览器便会在后台静默运行，不弹出可视化窗口，大幅度降低系统图形界面的开销。

图 2：Python + Selenium 动态爬取核心四步走架构与执行阶段

三、核心实操：编写动态网页抓取代码

编写动态抓取脚本需要将配置、导航、等待、提取和清理有序串联。一个健壮的爬虫脚本必须处理异步渲染的时延，并且在发生异常时确保浏览器进程能够正常退出。

下面的代码展示了一个完整的动态抓取示例。该示例配置了无头浏览器、访问动态渲染目标页面、使用显式等待监听商品列表渲染完毕，并依次提取其标题和价格：

from selenium import webdriver
from selenium.webdriver.chrome.options import Options
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

def fetch_dynamic_products():
    # 1. 基础配置：设置无头模式与常规反爬参数
    options = Options()
    options.add_argument("--headless=new")  # 使用 Chrome 109+ 引入的全新无头模式
    options.add_argument("--disable-gpu")
    options.add_argument("--no-sandbox")
    options.add_argument("--window-size=1920,1080")
    options.add_argument("user-agent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36")
    
    # 屏蔽 webdriver 自动化特征标识
    options.add_argument("--disable-blink-features=AutomationControlled")

    # 2. 启动驱动实例
    driver = webdriver.Chrome(options=options)
    
    try:
        target_url = "https://example.com/dynamic-shop"
        driver.get(target_url)

        # 3. 显式等待：最长等待 10 秒，直到商品卡片节点在 DOM 树中被渲染出来
        wait = WebDriverWait(driver, timeout=10)
        items_locator = (By.CSS_SELECTOR, ".product-card")
        elements = wait.until(EC.presence_of_all_elements_located(items_locator))

        results = []
        # 4. 遍历已渲染的节点提取数据
        for el in elements:
            # 在父元素内相对查找具体字段
            name = el.find_element(By.CSS_SELECTOR, ".product-name").text.strip()
            price = el.find_element(By.CSS_SELECTOR, ".product-price").text.strip()
            results.append({"name": name, "price": price})

        return results

    except Exception as err:
        print(f"抓取过程中发生异常: {err}")
        return []
    finally:
        # 5. 必须在 finally 块中退出驱动，防止产生僵尸浏览器后台进程
        driver.quit()

if __name__ == "__main__":
    data = fetch_dynamic_products()
    print(f"成功抓取到 {len(data)} 条商品数据")

代码运行提示：上面的代码中使用了 driver.find_element(By.CSS_SELECTOR, ...)。在 Selenium 4 中，旧版本的 find_element_by_css_selector 等方法已被彻底弃用，必须统一使用 By.* 枚举进行定位。

四、关键细节：为什么必须掌握“显式等待”？

在初学 Selenium 时，许多人遇到页面还没加载完就报错 NoSuchElementException 的情况，习惯直接加入 time.sleep(5)。这种做法在实际抓取中极不可靠。

在动态网页抓取中，处理加载时滞的机制主要有三种：

强制等待（time.sleep）：盲目挂起 Python 进程。如果接口在 0.5 秒内就返回了，程序依然需要死等 5 秒，导致吞吐率断崖式下跌；如果网络偶发卡顿需要 5.5 秒，程序又会直接抛出找不到元素的异常。
隐式等待（driver.implicitly_wait）：给全局驱动设置一个查找超时上限。在查找任何元素时，只要该元素尚未出现在 DOM 中，驱动就会在此时间内持续轮询。但隐式等待的缺陷在于：它只关心节点是否存在于 DOM 树，无法判断节点是否“可见”（Visible）、“可交互”（Clickable）或“内容非空”。在很多前端框架中，骨架屏的占位标签早已存在于 DOM，此时隐式等待直接返回，取到的内容依旧是空字符串。
显式等待（WebDriverWait + expected_conditions）：针对特定的节点或业务状态设置精准等待。它会在设定的最大超时时间内，按照默认 500 毫秒的频率轮询指定条件。只要条件满足，立即向下执行，兼具灵敏度与稳定性。

图 3：三种等待方式在判断机制、稳定性与执行效率上的横向对比

五、常用显式等待条件速查

在实际项目中，通过 selenium.webdriver.support.expected_conditions（通常简写为 EC）可以满足绝大部分网页状态监听需求：

EC.presence_of_element_located(locator)：只要元素被添加到了 DOM 树中即可返回，不要求可见。适合抓取隐藏在页面中的数据元信息。
EC.visibility_of_element_located(locator)：要求元素不仅在 DOM 树中，而且其宽度和高度大于 0，没有被 CSS 隐藏（如 display: none）。适合需要确保文本内容已经渲染展示的场景。
EC.element_to_be_clickable(locator)：元素处于可见且可点击状态。适合需要自动化翻页、点击“加载更多”按钮后再抓取的场景。
EC.text_to_be_present_in_element(locator, text)：监听元素内部是否已经填入了特定的文本。适合骨架屏标签已经就绪，等待前端异步数据填充完成的场景。

六、性能边界与进阶建议

虽然 Selenium 能够解决 JavaScript 渲染页面的抓取问题，但它本质上是一个浏览器自动化测试工具，并非专为高并发爬虫设计。了解其性能边界有助于做出更合理的技术选型：

1. 资源开销与并发限制：一个 Chrome 进程在无头模式下通常也会占用 150MB~300MB 的内存，且启动和加载完整资源（包括 CSS、图片和字体）会带来显著的 CPU 开销与网络带宽消耗。如果目标站点有数十万级甚至上百万级页面需要抓取，直接用 Selenium 暴力并发抓取将耗尽服务器内存。

2. 逆向 API 优先原则：在动手启动 Selenium 之前，建议首先在浏览器的“开发者工具 - Network（网络）”面板中，勾选“Fetch/XHR”类型进行抓包排查。很多情况下，前端通过清晰规范的 JSON 接口获取数据。如果数据接口没有强加密参数（如复杂的混淆 Token 或动态签名），直接使用 requests 模拟请求该接口是效率最高、开销最小的选择。

3. 资源禁止策略：如果必须使用 Selenium，可以通过 Chrome 选项禁用图片加载、CSS 渲染以及音频播放，这能大幅度加快页面加载速度并节省服务器带宽：

prefs = {
    "profile.managed_default_content_settings.images": 2,  # 禁用图片
    "profile.default_content_setting_values.notifications": 2  # 禁用通知
}
options.add_experimental_option("prefs", prefs)

图 4：动态页面抓取方案选型决策流程与生产落地注意事项总结

七、总结

当常规的静态请求无法抓取由 JavaScript 动态渲染的页面时，Python + Selenium 提供了一套直接还原用户真实浏览环境的通用解法。通过现代 Selenium 内置的驱动自动化管理机制，配合 Chrome 无头模式与标准化的显式等待，我们能够平稳、可靠地捕获前端异步加载的最终数据。

在实际工程实践中，始终建议先分析目标站点的网络请求，评估直接调用数据接口的可行性；在确需使用浏览器渲染时，规范资源释放逻辑、合理使用显式等待并剔除无用资源加载，是构建稳健高效动态爬虫的关键基石。