---
title: "Web search / fetch"
description: "Gemini CLI Web search 和 Web fetch：搜索最新资料、读取指定 URL、比较多个来源，并把网页知识应用到代码。"
verifiedAt: "2026-05-09"
---

Gemini CLI 可以搜索和抓取网页。官方工具文档把它拆成两类：`google_web_search` 用来发现和综合搜索结果，`web_fetch` 用来读取你明确给出的 URL。搜索负责找线索，fetch 负责深读来源。

> [!NOTE]
> **搜索负责发现，fetch 负责深读**。不要只让模型凭记忆回答新库、新版本和新错误。

## 1. 搜索新资料

```text
Search for the React Router v7 loader API documentation and summarize the key changes.
```

适合：

- 新发布的库。
- 最近变动的 API。
- 报错信息。
- GitHub issue / StackOverflow / forum 线索。

Web search 返回的是基于搜索结果的综合答案，适合发现资料和建立初步方向。它不等于你已经完整读过目标页面。

更稳的提问方式是把目标、时间范围和来源偏好写出来：

```text
Search the official docs and recent release notes for Next.js 16 caching changes.
Prioritize primary sources over blog posts, then list the pages I should read first.
```

如果你只问“Next.js 缓存怎么用”，模型可能会混合不同版本的经验；如果你明确要求官方文档、release note 和最近版本，它更容易把搜索变成可核验的入口清单。

## 2. 读取指定 URL

```text
Read https://example.com/fixing-memory-leaks and explain how to apply it to my code.
```

适合：

- 已知官方文档页。
- 博客深读。
- 迁移指南。
- API reference。

Web fetch 适合你已经知道官方页面、issue、PR、release note 或迁移指南的 URL。它比“让模型自己搜”更可控，也更适合教程写作和代码迁移。

读取指定 URL 时，不要只让它总结网页。更好的做法是要求它把网页结论映射到当前任务：

```text
Fetch this migration guide, then compare it with my package.json and identify only the changes that apply to this repo.
```

这样输出会更接近可执行 diff，而不是泛泛的网页摘要。

## 3. 比较多个来源

```text
Compare the pagination patterns in https://api.example.com/v1/docs and https://api.example.com/v2/docs.
```

适合版本迁移和方案选择。

## 4. 判断来源可信度

联网能力的核心不是“能搜”，而是能不能把来源分层。建议按这个顺序处理：

| 来源类型 | 可用方式 | 适合结论 |
| --- | --- | --- |
| 官方文档 / API reference | 主依据 | 参数、限制、支持范围 |
| Release note / changelog | 主依据 | 版本差异、弃用、迁移步骤 |
| 源码 / schema / 类型定义 | 主依据 | 真实字段、默认值、边界行为 |
| GitHub issue / PR | 辅助依据 | 已知 bug、临时绕过、维护者态度 |
| 博客 / 论坛 / 问答 | 线索 | 问题复现、经验路径、排障方向 |

对教程写作来说，结论必须能回到官方页、源码或本地测试。社区内容可以帮助发现问题，但不应该单独成为最终说法。

## 5. 应用到代码

一条更完整的路径：

1. 先搜索官方文档。
2. 再 fetch 指定页面。
3. 要求 Gemini 解释适配点。
4. 让它给修改计划。
5. 看 diff 后再授权修改。

```mermaid
flowchart LR
    Search["Search"] --> Sources["候选来源"]
    Sources --> Official{"有官方来源?"}
    Official -->|有| Fetch["Fetch 官方 URL"]
    Official -->|没有| Community["社区来源只作线索"]
    Fetch --> Plan["生成适配计划"]
    Community --> Verify["继续找主来源或实验验证"]
    Plan --> Diff["授权小范围 diff"]

    style Fetch fill:#dcfce7,stroke:#22c55e
    style Community fill:#fef3c7,stroke:#f59e0b
    style Diff fill:#dbeafe,stroke:#3b82f6
```

## 6. 输出检查

让 Gemini CLI 联网后，最后还要检查输出是否满足三个条件：

- **有来源层级**：知道哪些是官方结论，哪些只是社区线索。
- **有适用版本**：标明库版本、CLI 版本、模型版本或发布日期，避免旧资料误用。
- **有本地验证点**：能转成命令、测试、最小复现或 diff 检查，而不是停在解释层。

如果输出里没有来源、没有版本、没有验证动作，就把它退回去重做：

```text
Redo the answer with source ranking, version scope, and local verification steps.
```

## 7. 风险边界

- 最新资料必须优先官方来源。
- 社区方案只能作参考。
- 不要让它把未验证博客方案直接写进生产代码。
- 涉及安全、支付、认证、云权限时必须二次核对官方文档。
- 搜索结果可能混入旧版本、镜像站、非官方博客和 AI 生成内容。
- 读取网页时要记录来源和访问日期，尤其是模型、价格、API、地区和弃用时间。

> [!WARNING]
> **联网不等于事实正确**：搜索结果能帮你发现资料，但不能替代官方文档、源码、release note、API schema 和本地测试。高风险修改必须回到主来源核验。

## 8. 接下来去哪

<Cards>
  <Card title="会话与历史" description="继续看搜索和修改后的会话如何保存、恢复和管理。" href="/docs/gemini-cli/official/01-cli-workflow/16-session-history" />
  <Card title="Web tools" description="继续看 Gemini CLI 官方 web search 和 web fetch 工具语义。" href="/docs/gemini-cli/official/03-tools-mcp/33-web-tools" />
  <Card title="GitHub Action" description="如果要把联网能力放进自动化，继续看 GitHub Action 的权限边界。" href="/docs/gemini-cli/official/07-integrations-automation/74-github-action" />
</Cards>

## 官方来源

- [Web Search Tool](https://google-gemini.github.io/gemini-cli/docs/tools/web-search.html)
- [Web Fetch Tool](https://google-gemini.github.io/gemini-cli/docs/tools/web-fetch.html)
- [Gemini CLI Tools Reference](https://github.com/google-gemini/gemini-cli/blob/main/docs/reference/tools.md)
