真正可用的 Gemini 网页爬虫方案（代码版 + 无代码版）

很多关于“gemini web scraping”的教程，读起来都像是写给同一个人看的：一位已经配好虚拟环境、Pydantic schema，还对异步库很有主见的 Python 开发者。如果你正好是这样，那当然很好——我们先讲代码。可如果你是销售、市场或者电商运营，只是想把一堆网页整理成结构化数据，又不想先搞懂 markdownify 到底是做什么的，那你绝对不是一个人。

Gemini 是 Google 的多模态 AI 家族，也正在快速成为网页数据提取的热门引擎之一。2025 年 Stack Overflow 开发者调查显示， 正在使用或计划使用 AI 工具——而基于 LLM 的抓取正是这股浪潮的重要组成部分。但“在某个单一 URL 上跑通一个酷炫演示”和“能稳定处理分页、子页面、反爬墙以及混乱 HTML 的生产级流程”之间，差距其实非常大。本文会同时覆盖 Python（代码）和无代码两条路线，结合真实的 token 计算来讲模型选择，专门讲清楚多页面抓取这个大多数教程都会跳过的步骤，并坦诚说明 Gemini 抓取在哪些地方会失效。读完后，你会知道哪条路更适合你的工作流，也会明白我见过哪些坑最容易让开发者和业务用户一起踩雷。

什么是 Gemini 网页抓取？

Gemini 网页抓取，指的是把网页内容——HTML、Markdown，甚至截图——发送给 Google 的某个 Gemini AI 模型，由它来理解页面并返回结构化数据。没有 CSS 选择器，没有 XPath，也没有那种网站稍微改一下布局就全坏掉的脆弱规则。

核心流程大致如下：

1. 抓取页面（用 requests、无头浏览器，或者 Chrome 扩展）
2. 清洗并转换内容（通常是 HTML → Markdown，以降低 token 成本）
3. 发送给 Gemini，并附上你想要的字段 schema
4. 接收结构化 JSON 返回，直接用于表格、CRM 或数据库

这和传统用 BeautifulSoup 或 Selenium 的抓取方式完全不同：传统方式需要你硬编码像 div.product-title > span.price 这样的选择器，然后祈祷网站下周二别改版。Gemini 读取页面的方式更像人类：它能理解上下文、适应布局变化，并且在没有自定义规则的情况下处理凌乱格式。

还有一点值得注意：Gemini 原生支持多模态输入。它可以在一次请求里处理文本、图片、视频、音频、PDF 和代码。这就打开了很多其他 LLM 做不到的抓取思路，比如直接发截图而不是 HTML。后面我们会讲到。

为什么 Gemini 网页抓取对业务团队很重要

如果你在想，为什么市场经理或电商分析师要关心 LLM 和网页抓取，答案很简单：它能省下惊人的时间，而且网站更新时也不至于动不动就坏。

2025 年约 10 亿美元增长到 2030 年超过 20 亿美元，而 AI 驱动的数据提取是增长最快的细分赛道。这不是噱头，而是真实反映了团队采集数据方式的变化。

Gemini 抓取在日常业务流程中的典型场景包括：

实际收益主要有两点。第一，你不必反复编写、测试和调试解析脚本——模型每次都会重新读页面。第二，每当网站改个 <div>，你也不需要再去找开发者救火。Gemini 的免费额度意味着小规模任务几乎可以零成本试验：，而且不需要信用卡。

应该选哪个 Gemini 模型？（Flash Lite、Flash 还是 Pro）

并不是所有 Gemini 模型都同样适合抓取。这部分是我希望每篇教程都能写清楚的实用对比，因为选错档位，要么浪费钱，要么拿回一堆垃圾数据。

目前这三款 Gemini 2.5 模型都支持 1,048,576 token 的上下文窗口，并且都是多模态。区别主要在于价格、速度，以及它们处理复杂抽取任务的能力。

（价格来自 。Batch API 可享受这些价格的 50% 折扣。）

Gemini 2.5 Flash Lite：又快又便宜，但要小心缺字段

Flash Lite 是预算型选择。它非常适合简单、扁平的数据——比如商品名、价格、单层列表——并且适合大批量处理。但它在可选字段、时间戳和嵌套数据上有已知问题。Google 论坛上一位开发者曾说，当 schema 包含非必填属性时，Flash Lite 会“发疯”，不停输出重复文本直到 token 用尽。如果你的 schema 超过两层嵌套，或者某些字段在部分页面上可能缺失，Flash Lite 会同时消耗你的 token 和耐心。

Gemini 2.5 Flash：大多数抓取任务的甜蜜点

如果是我做几乎任何真实抓取任务，我都会先从 Flash 开始。它在结构化抽取上表现稳，能处理分页逻辑，输入成本大约是 Flash Lite 的 3 倍——但准确率提升值得这个价差。在 上，Flash 的表现离 Pro 只差几个点，这意味着它足够胜任抓取中真正需要的推断、归一化和扁平化工作。

Gemini 2.5 Pro：处理复杂数据时追求最高准确率

Pro 是精度工具。适合提取深层嵌套 schema（比如一个商品有多个变体组，每个变体组下面还有尺码、颜色和价格），或者当你不能接受伪造字段时（法律、金融、医疗数据）。它的输入成本大约是 Flash Lite 的 12 倍，所以建议把它留给“准确率比价格更重要”的任务。

成本示例：10,000 个商品页面

假设你先把 HTML 预处理成 Markdown（这是应该做的，下面会详细说），那么一个典型商品页会从大约 20,000 token 的原始 HTML 降到约 4,000 token 的 Markdown。输出 JSON 每页大约 500 token。

如果不做 Markdown 预处理，直接用原始 HTML（输入约 2 亿 token），这些数字会涨 4–5 倍。预处理是整个流程里收益最高的优化。

代码版还是无代码版：Gemini 网页抓取的两条路

现在来到分岔口。如果你是开发者，要搭建自定义流程，那么 Python + Gemini API 路线能给你最大的控制权。如果你是业务用户，只想立刻拿到数据，又不想碰终端，那无代码 AI 爬虫会更快帮你落地。

是我们在 Thunderbit 提供的无代码方案——一个 Chrome 扩展，底层使用 AI（包括 Gemini、ChatGPT、Claude 等）自动推荐字段、两步完成抓取，并导出到你想用的工具。我会在下面把两条路线都讲一遍。

对于以表格为中心的用户，Quadratic 也是一个值得了解的选择——它是一个 AI 表格工具，可以在单元格内部运行基于 Gemini 的网页抓取。但如果你的流程是从一个明确网页开始的（比如商品列表、名录、线索数据库），Thunderbit 更贴近用户的思维方式。

分步教程：使用 Python 进行 Gemini 网页抓取

这一部分是给开发者看的。如果你想看无代码方案，可以直接往后跳。

开始前先确认：

• 难度： 中级（需要熟悉 Python）
• 预计耗时： 第一次抓取约 20–30 分钟
• 你需要准备： Python 3.10+、Google AI Studio 账号（免费）、目标 URL

第 1 步：配置 Python 环境和 Gemini API Key

先创建项目文件夹和虚拟环境，然后安装所需库：

1mkdir gemini-scraper && cd gemini-scraper
2python -m venv venv && source venv/bin/activate
3pip install -U google-genai requests beautifulsoup4 markdownify pydantic

重要提醒： 到 2026 年，唯一正确的 SDK 是 google-genai。旧版 google-generativeai 包已经在 2025-11-30 结束生命周期，现在属于弃用状态。如果你在教程里看到 import google.generativeai as genai，那段代码已经过时了。

接下来，到 获取 API Key。点击 “Get API Key”，新建密钥，然后把它保存成环境变量：

1export GEMINI_API_KEY="your-key-here"

这样你就完成了 Python 环境和依赖安装，API key 也准备好了。

第 2 步：抓取目标页面 HTML

使用 requests 请求页面。这里以一个商品页为例：

1import requests
2url = "https://example.com/product/widget-pro"
3response = requests.get(url, headers={"User-Agent": "Mozilla/5.0"}, timeout=30)
4html = response.text

如果网站依赖大量 JavaScript 渲染，或者有强反爬保护，requests.get() 可能只会返回空壳页面或 403。我们会在限制部分讲怎么应对——不过对很多公开网站来说，这种方式已经足够好用。

第 3 步：清洗 HTML 并转换成 Markdown

这一步是很多教程会提到、但很少量化的一步。一个普通商品页的原始 HTML 大约有 20,000 token。经过 BeautifulSoup 清理和 Markdown 转换后，通常会降到大约 765–4,000 token——相当于 ，能真正省钱，也能减少幻觉。

1from bs4 import BeautifulSoup
2from markdownify import markdownify
3soup = BeautifulSoup(html, "html.parser")
4main = soup.select_one("main") or soup  # 只保留主体内容
5markdown_content = markdownify(str(main))

select_one("main") 这一步会去掉 header、footer、导航栏和脚本——这些都是浪费 token、还会干扰模型的噪音。如果网站没有 <main> 标签，可以试试 .product-detail、#content，或者任何包住核心数据的容器。

完成这一步后，你应该会拿到一个干净的 Markdown 字符串，只保留页面真正有意义的内容。

第 4 步：定义数据 schema 并发送给 Gemini

用 Pydantic 定义你想要的返回结构。google-genai SDK 可以直接接收 Pydantic 的 BaseModel 作为 response_schema：

1from google import genai
2from google.genai import types
3from pydantic import BaseModel
4class Product(BaseModel):
5    name: str
6    price: str
7    sku: str | None = None
8    description: str
9    sizes: list[str] = []
10    colors: list[str] = []
11client = genai.Client()  # 会从环境变量读取 GEMINI_API_KEY
12response = client.models.generate_content(
13    model="gemini-2.5-flash",
14    contents=f"从这个页面提取商品详情：\n\n{markdown_content}",
15    config=types.GenerateContentConfig(
16        response_mime_type="application/json",
17        response_schema=Product,
18    ),
19)
20product = response.parsed
21print(product)

这里有几个来自 的坑需要注意：

• 不要在传给 Gemini 的 schema 里使用 Field(default=...)——API 会抛出 ValueError。请直接在类型层写成 sku: str | None = None。
• 保持嵌套层级尽量浅（最多 3 层）。太深的嵌套会让 Flash 和 Flash Lite 输出递归内容，或者括号不闭合。
• 在使用 Flash Lite 时，把字段尽量设为必填，并用空字符串占位，不要省略；Flash Lite 对可选字段的处理。

这样你就能得到一个解析后的 Product 对象，里面是页面提取出的结构化数据。

第 5 步：导出并保存抓取结果

把结果保存成 JSON 或 CSV：

1import json
2with open("products.json", "w") as f:
3    json.dump(product.model_dump(), f, indent=2)

如果要写入 Google Sheets，可以使用 gspread 库。要入库的话，就按你自己的 ORM 序列化即可。Gemini 的结构化输出已经足够干净，可以直接送进大多数下游工具。

分步教程：不用代码进行 Gemini 网页抓取（使用 Thunderbit）

这部分适合业务用户——或者不想写一次性抓取脚本的开发者。

开始前先确认：

• 难度： 初级
• 预计耗时： 第一次抓取约 5 分钟
• 你需要准备： Chrome 浏览器、（免费版可用）

第 1 步：安装 Thunderbit Chrome 扩展

打开 ，点击“添加至 Chrome”。用邮箱注册即可——整个过程不到一分钟。和上面 15–30 分钟的 Python 配置相比，差别非常明显。

第 2 步：打开目标网页并点击“AI Suggest Fields”

进入你要抓取的网站——商品列表、房产目录、线索库，什么都可以。点击浏览器工具栏里的 Thunderbit 图标，然后选择 “AI Suggest Fields”。

Thunderbit 的 AI 会自动读取页面，并推荐列名和数据类型，比如“商品名称”“价格”“评分”“图片链接”。你可以修改列名、删除不需要的字段，或者为每一列添加自定义 AI 提示词（例如“分类为高/中/低”或“翻译成英文”）。

在真正开始抓取之前，你就能先看到一个带有已配置列的表格预览。

第 3 步：点击“Scrape”并检查结果

只需要点一次。Thunderbit 会自动处理分页——无论是点击“下一页”按钮还是无限滚动——并把数据提取成结构化表格。你可以选择：

• 云端抓取： 速度更快，可同时处理最多 50 个页面。适用于公开网站。
• 浏览器抓取： 在你已登录的浏览器标签页中运行。适合需要身份验证的网站（CRM、受限目录、内部工具）。

结果会直接出现在扩展侧边栏的表格里。导出前先快速扫一眼，检查有没有明显错误。

第 4 步：导出到 Excel、Google Sheets、Airtable 或 Notion

点击导出按钮，然后选择格式。Thunderbit 可以免费导出到 Excel、Google Sheets、Airtable 和 Notion，没有付费墙。图片字段还可以直接上传到 Notion 和 Airtable 的图片库，如果你在抓商品图或头像，这个功能特别顺手。

不用解析 JSON，不用写脚本。数据拿到手就能用。

使用 Gemini 进行多页面和子页面抓取

大多数教程会在单个 URL 之后悄悄结束，但真实项目不会。

抓 500 个商品页、带分页和详情子页面的任务，和一个单 URL 演示之间，差距巨大。

使用 Gemini API 处理分页（代码方案）

如果是页码型 URL（最常见），就循环翻页，直到返回空结果：

1import time
2all_products = []
3for page in range(1, 101):  # 最多 100 页
4    url = f"https://example.com/products?page={page}"
5    md = fetch_clean(url)  # 你前面写好的 HTML→Markdown 函数
6    response = client.models.generate_content(
7        model="gemini-2.5-flash-lite",  # 列表页用便宜的模型
8        contents=f"提取商品名称和 URL：\n\n{md}",
9        config=types.GenerateContentConfig(
10            response_mime_type="application/json",
11            response_schema=list[ListingItem],
12        ),
13    )
14    items = response.parsed
15    if not items:
16        break
17    all_products.extend(items)
18    time.sleep(4)  # 注意免费额度的速率限制

如果是 cursor 型或无限滚动页面，你需要拦截前端调用的 XHR 接口（在浏览器 Network 面板里查看），然后直接循环请求那个接口。这比重新渲染页面更省，而且只有在字段需要 LLM 清洗时才把项目交给 Gemini。

这里要特别注意 token 成本——每多一页，账单就会叠加。简单列表页用 Flash Lite，只有在需要详情抽取时才升级到 Flash。

抓取子页面，获取更丰富的数据（代码方案）

经典的两阶段模式：第一阶段抓列表页拿 URL，第二阶段访问每个详情页提取更丰富的信息。

1# 第一阶段：用便宜的 Flash Lite 收集 URL
2class Listing(BaseModel):
3    product_urls: list[str]
4listing = client.models.generate_content(
5    model="gemini-2.5-flash-lite",
6    contents=f"提取商品 URL：\n{listing_md}",
7    config=types.GenerateContentConfig(
8        response_mime_type="application/json",
9        response_schema=Listing,
10    ),
11).parsed
12# 第二阶段：用 Flash 提取详情
13class ProductDetail(BaseModel):
14    name: str
15    price: str
16    specs: dict[str, str]
17    reviews: list[str]
18for url in listing.product_urls:
19    md = fetch_clean(url)
20    detail = client.models.generate_content(
21        model="gemini-2.5-flash",
22        contents=f"提取商品详情：\n{md}",
23        config=types.GenerateContentConfig(
24            response_mime_type="application/json",
25            response_schema=ProductDetail,
26        ),
27    ).parsed
28    # 保存详情...
29    time.sleep(0.5)

这套方案能跑，但周边工程工作很多：URL 去重、错误处理、限流、重试逻辑、缓存原始 HTML，这样即使 schema 改了也不用重新抓取。50 个页面还好，5,000 个页面就开始像在搭基础设施了。

无代码替代方案：Thunderbit 内置分页和子页面抓取

Thunderbit 会自动处理点击翻页和无限滚动分页，不需要你写循环脚本。至于子页面补充信息，“抓取子页面”功能会自动访问列表页链接的每个详情页，并把更深层字段补充回原始表格。一次点击，不是一段脚本。

云端抓取模式可以同时处理最多 50 个页面，在抓商品目录或房产目录这种规模化任务时尤其有用。对不想管理 Python 循环和重试逻辑的人来说，这是更实用的选择。（如果你想了解更多 的方法，我们也有单独的教程。）

截图抓取：Gemini 的多模态捷径

这里有一种很多教程完全跳过的方法：不是发送原始 HTML，而是把网页截图发给 Gemini 的视觉 API。某位开发者曾说，单张截图只消耗大约 258 token——即使是清洗后的 Markdown，成本也可能是它的几倍甚至更多。对于简单抽取任务来说，这个成本差异非常大。

如何使用 Gemini 的 Vision API 进行网页抓取

用 Playwright 截图、编码，然后发送给 Gemini：

1from playwright.sync_api import sync_playwright
2from google import genai
3from google.genai import types
4from pydantic import BaseModel
5class Product(BaseModel):
6    title: str
7    price: str
8with sync_playwright() as p:
9    page = p.chromium.launch().new_page()
10    page.goto("https://example.com/product/widget-pro")
11    page.wait_for_load_state("networkidle")
12    png_bytes = page.screenshot(full_page=False)  # 只截首屏
13client = genai.Client()
14resp = client.models.generate_content(
15    model="gemini-2.5-flash",
16    contents=[
17        {"inline_data": {"mime_type": "image/png", "data": png_bytes}},
18        "把商品标题和价格提取成 JSON。",
19    ],
20    config=types.GenerateContentConfig(
21        response_mime_type="application/json",
22        response_schema=Product,
23    ),
24)
25print(resp.parsed)

根据 Google 的，如果图片长宽都不超过 384 像素，成本是 258 token。更大的图片会被切成 768×768 的块，每块 258 token。一个短的首屏截图（258–1,600 token）在成本上通常完胜原始 HTML；但如果是很长的整页截图（约 5,000 token），它反而可能不如清洗后的 Markdown（约 765–1,200 token）。

截图抓取的局限

• 密集表格精度较低： 多列布局、小字号和元素重叠时，容易出现漏读和表头错位，而不是胡编乱造。
• 不能跟随链接： Vision 返回的是文本，不是可点击链接。没有分页，也没有子页面补充。
• 分辨率上限： 小于大约 10 px 的文字经常会被读错。Google 会把最长边下采样到大约 1,568 px。
• 采集开销： Playwright 启动 + 等待 networkidle 每页要 2–5 秒，规模一大就会累积得很明显。

截图抓取非常适合 JS 很重、会封机器人、或者数据嵌在图表和图片中的页面（比如 requests.get() 返回 403，但浏览器能正常渲染）。对于长文本页面，Markdown 仍然是更优选择。

Thunderbit 的图片和 PDF 抓取采用的也是类似的 AI 视觉路线——直接拖入图片或 PDF，就能返回结构化表格，不需要自己写截图脚本或处理 base64。（另见：。）

Gemini 网页抓取失败的场景，以及该怎么办

Gemini 是一个抽取引擎，不是一个抓取引擎。如果你无法先把页面内容拿到 Gemini，那它也帮不上忙，就这么简单。

有几种常见场景会让整套方法失效，而大多数教程只是轻描淡写带过。我更愿意直接说清楚。

其中有几项值得再补充一点背景。

反爬系统现在已经在主动识别 LLM。 截至 2025 年 7 月，Cloudflare 已经，前 5 个月就拦下了 4160 亿次 AI bot 请求。Datadome 也在 2025 年加入了 LLM 专属检测，并观察到 LLM bot 流量增长了 4 倍。面对 Datadome 保护的网站，直接用 requests.get() + Gemini 几乎等于失效。问题不在 IP，而在指纹——如果 TLS 指纹一看就是“Python requests”，只换 IP 也没用。

幻觉问题很隐蔽。 训练目标是“尽量帮忙”的 LLM，往往会把可选字段补成看似合理的内容，而不是返回 null。我见过模型从 URL slug 猜商品品牌、从 TLD 推断币种，甚至从骨架屏上编造出看起来很真实的评论数。应对手段包括：严格的 Pydantic schema、带校验反馈的重试循环、验证器确认提取值是否真的出现在源 HTML 中，以及（Flash 提取，Pro 抽样验证）。

100 万 token 上下文窗口并不意味着 100 万 token 都能可靠使用。 和其他研究表明，推理质量会在接近上限之前就开始下降。对于结构化抽取，实际可依赖的上限更像是 20 万–30 万 token。

决策树：你该用什么工具？

• 低频 + 简单页面 + 开发者 → Gemini API 免费层 + Python
• 中等频率 + 复杂 schema + 开发者 → Gemini 2.5 Flash 付费版 + Python + 结构化输出 + 预处理
• 任意频率 + 非开发者 + 需要登录或分页很重 →
• 超高频 + 强反爬 + 关键业务场景 → 托管式抓取基础设施（代理服务）+ Gemini 作为抽取层

Gemini 网页抓取：省时间也省钱的技巧

不管你是写 Python 还是点按钮，这些建议都能帮你少踩坑。

1. 在发送给 Gemini 之前，一定先把 HTML 预处理成 Markdown。 一般可以节省 ；如果再配合 BeautifulSoup 预裁剪，节省 95% 也不是不可能。
2. 只用 google-genai。 不要再用已弃用的 google-generativeai 包——它已经 EOL。
3. Flash Lite 只适合扁平 schema 起步。 一旦出现嵌套或可选字段，立刻升级到 Flash。
4. 传给 Gemini 的 Pydantic schema 里不要用 Field(default=...)。 请在类型层直接写 sku: str | None = None。
5. Pydantic + response_schema 很关键。 它既是契约，也是防幻觉的护栏。
6. 超过 1,000 页的任务请用 ——可享 50% 折扣，而且不计入实时 RPM。
7. 新抽取器上线前，先人工抽查 10–50 行样本。 准确率漂移往往在你真正查看之前都看不出来。
8. 把原始 HTML 缓存到磁盘。 Schema 调整不应该迫使你重新抓取。
9. 每一行都记录来源 URL。 这样后续可以只重抓单页，不必整批重跑。
10. 对无代码用户来说：在 Thunderbit 里为每一列使用自定义 AI 提示词，把提示工程放到表格层完成——翻译、分类、总结都能按列做。

还有一条：不要把免费额度直接上生产。 2025 年 12 月额度已经被削减了 50–80%，之后也可能在没有预告的情况下再次下调。

总结

从一个单 URL 的 Gemini 演示，到一个真正可用的生产级流程，中间的距离，比大多数教程说得都要大。

Python + Gemini API 路线，能让开发者完全掌控模型选择、预处理、分页和 schema 设计。无代码路线——比如 ——则让业务用户无需碰终端，也能拿到同样的结构化数据提取能力。

我会得出这几个结论：

• 模型选择很重要。 Flash Lite 适合高并发，Flash 适合平衡，Pro 适合复杂场景。别总盯着最便宜的选项，然后再奇怪为什么数据不对。
• 多页面和子页面抓取，正是多数教程讲不清、但真实工作最常见的部分。 这里介绍的两条路线都覆盖了这个缺口。
• 诚实面对限制，能帮你省下大量时间。 如果网站会拦 API 请求，靠再多的提示词工程也没用。要选对工具，而不是选最花哨的工具。
• 把 HTML 预处理成 Markdown，是整个流程里收益最高的优化。 它能把成本降低 75% 以上，还能减少幻觉。

如果你想试试无代码方案， 可以让你先抓几页看看效果。如果你更喜欢写代码，Gemini 的免费 API 额度也足够你在一个下午搭出原型。不管哪条路，你拿到结构化数据的速度都会远远快于手动复制粘贴。想进一步了解 或者，我们在博客里都做了深入讲解。

常见问题

使用 Gemini 做网页抓取要多少钱？

Gemini API 提供免费额度：截至 2026 年初，Pro 每天大约 100 次请求、Flash 500 次、Flash Lite 1,000 次（这些限制在 2025 年 12 月被下调过）。在付费层面，如果你先把 HTML 预处理成 Markdown，那么抓取 10,000 个商品页面的成本大约是：Flash Lite $1.50、Flash $6、Pro $25。若不做预处理，成本会增加 4–5 倍。对于非实时任务，Batch API 可享受 50% 折扣。

Gemini 能抓需要登录的网站吗？

Gemini API 本身不能登录网站——它只能处理你发给它的内容。你需要先用自己的已认证会话把 HTML 抓下来，比如用无头浏览器和已保存的 cookies。Thunderbit 的浏览器抓取模式原生支持这一点：它直接在你已登录的 Chrome 标签页里运行，因此浏览器里能看到的网站，Thunderbit 就能抓。

用 Gemini 抓网页合法吗？

是否合法，取决于网站服务条款、数据类型以及你所在司法辖区。在美国，经过 hiQ v. LinkedIn 和 Meta v. Bright Data 之后，抓取公开可访问、无需登录的数据通常被认为是允许的——但具体仍要看案件事实。登录后才能访问的数据，法律风险更高。欧盟居民的个人数据无论网站是否公开，都受 GDPR 约束。请始终遵守 robots.txt 和服务条款，不要在没有合法依据的情况下抓取个人数据。

Gemini 能抓动态的 JavaScript 重网站吗？

可以，但你需要先把 JavaScript 渲染出来——可以用无头浏览器（Playwright、Puppeteer），也可以直接拦截网站调用的 API 接口。拿到渲染后的 HTML 后，再像平常一样清洗并发送给 Gemini。另一种办法是使用 Gemini 的视觉 API 做截图抓取——只要它能在浏览器里渲染出来，Gemini 就能“看见”。Thunderbit 在云端和浏览器抓取模式下都能自动处理 JS 渲染页面。

用 Gemini 抓取，和像 Thunderbit 这样的专用抓取工具有什么区别？

Gemini 是抽取引擎——它负责理解内容并返回结构化数据。它不会主动访问网站，也不会处理分页、登录认证或导出到表格。你仍然需要某种方式把页面内容送进 Gemini，也需要某种方式把输出变成可用结果。像 这样的专用工具，把抓取、渲染、AI 抽取、分页、子页面补充和导出都打包到了一起——不需要自己搭管道。

了解更多