关于本文
关于本文
本文采用结合生成式 AI 的自动化流程创建。我们查阅了 Google 官方产品列表和面向开发者的第一手资料，将 Google 众多的产品、服务、API 和认证基础设施整理为一个入口，帮助你从“想做什么”出发来理解它们。信息核实基准日：2026-09-18
Google 的名称、提供状态和链接可能会发生变化。本文已核实上述基准日时的官方信息。
首先一句话概括
Google 绝不仅仅是“搜索公司的应用列表”，寻找信息、协作办公、使用 AI、构建网络服务、分析数据、投放广告、嵌入地图、安全认证它是针对上述各种目的拥有众多组件的庞大服务群。 我们不应死记硬背各个产品的名称，而是先绘制一张整体地图。
从想做什么的视角看 Google
| 主要目的 | 代表性组件 | 主要使用者 |
|---|---|---|
| 寻找信息 | Search、Lens、News、Scholar、Trends | 普通用户与企业 |
| 用 AI 处理文本与信息 | Gemini、NotebookLM、AI Studio | 普通用户、企业与开发者 |
| 在公司协同办公 | Gmail、Drive、Docs、Sheets、Meet、Calendar | 普通用户、文职与管理员 |
| 构建网页/业务系统 | Cloud Run、Cloud SQL、Firebase、IAM | 开发者与 IT 管理员 |
| 收集并分析数据 | Analytics、BigQuery、Looker | 网站运营、分析与开发人员 |
| 改善网站 | Search Console、Analytics、Tag Manager | 网站运营与开发人员 |
| 使用地图与位置信息 | Maps、Places API、Routes API | 普通用户与开发者 |
| 安全地使用 API | Cloud Project、OAuth、Service Account、IAM | 开发者与 IT 管理员 |
整体 → 组件 → 使用者
flowchart TD GOAL[やりたいこと] --> W[共同作業] GOAL --> DEV[システムを作る] GOAL --> DATA[分析する] GOAL --> MAP[場所を扱う] GOAL --> AI[AIを使う] W --> WS[Google Workspace] DEV --> GC[Google Cloud / Firebase] DATA --> GA[Analytics / BigQuery / Looker] MAP --> GMP[Google Maps Platform] AI --> GEM[Gemini / AI Studio] GC --> AUTH[Cloud Project / IAM / OAuth] WS --> USER[一般利用者・事務職] GC --> ADMIN[IT管理者・開発者]
这里重要的一点是，不要把 Cloud Project 或 OAuth 这类东西看作和 Gmail 同类别的“应用”。前者是为了让其他服务能够安全运行的基础和机制。
本图鉴将“服务”与“机制”区分开来
| 类型 | 示例 | 面向初学者的含义 |
|---|---|---|
| PRODUCT | Gmail / Google Maps | 人们直接通过界面使用的产品 |
| SERVICE | BigQuery / Cloud Run | 在云端开展工作的组件 |
| PLATFORM | Google Cloud / Maps Platform | 整合多个组件的基础平台 |
| API | Search Console API | 供程序调用服务功能的入口 |
| IDENTITY | Service Account | 用于识别程序而非人类的 ID |
| PROTOCOL | OAuth 2.0 | 在不泄露密码的前提下授予权限的标准机制 |
| CONCEPT | Google Cloud Project | 整合 API、权限、计费等的管理单元 |
API是让程序代替人工操作界面，从而调用功能或数据的窗口。OAuth 2.0是一种机制，它不将密码本身交给应用，而是授予诸如“仅允许该应用读取日历”之类的权限。
具体示例：想要自动统计公司的日程
与其死记“Google Calendar API”这个名字，不如从处理流程的角度来看，这样更容易分清各自的角色。
sequenceDiagram participant U as 担当者 participant A as 集計アプリ participant G as Google認証 participant C as Google Calendar API U->>A: 来週の予定を集計 A->>G: 必要な権限を要求 G-->>A: 許可された認証情報 A->>C: 予定を読み取り C-->>A: 予定データ A-->>U: CSVや一覧として表示
在这个例子中，Calendar 是“拥有日程的组件”，API 是“程序的入口”，OAuth 是“安全授予权限的机制”，而 Cloud Project 则是“整合 API 和认证设置的管理单元”。
不同读者的关注点各不相同
普通用户与文职人员
以 Gmail、Drive、Docs、Sheets、Meet 等“直接推进工作的产品”为核心。不过，一旦尝试自动化日常作业，API 和 OAuth 就会变得十分亲近。
IT 管理员
谁能使用、数据可以共享到什么程度、是否可审计、如何隔离计费和权限至关重要。除了 Workspace 管理功能外，还涉及 Cloud Project、IAM、日志等内容。
开发者
通过组合 API、SDK、CLI、认证、Cloud Run、Firebase 等来开发应用或自动化处理。SDK是为了让各编程语言更轻松地处理 API 而提供的开发工具包集合。CLI是不通过界面、而是通过命令行来操作服务的工具。
熟悉 Microsoft 的人该如何看待？
| Google 侧 | Microsoft 侧相近的理念 | 需要注意的差异 |
|---|---|---|
| Google Workspace | Microsoft 365 | 产品构成、管理模型和许可证并不完全相同 |
| Google Drive | OneDrive / SharePoint 的部分用途 | 共享云端硬盘等组织共享的设计有所不同 |
| Google Cloud | Microsoft Azure | 服务名称、IAM 和资源层级各不相同 |
| Google Cloud Project | Azure Subscription / Resource Group 的部分概念 | 并非一一对应，而是 Google 独有的、用于整合 API 启用和 IAM 等的基本单元 |
| IAM | Azure RBAC / Microsoft Entra 权限控制的一部分 | 身份基础设施与资源权限的边界及术语有所不同 |
关键在于：将与 Microsoft 产品名称的对应关系作为理解的跳板，但不要认为它们完全等同。
图鉴的文章数量与“Google 官方总数”是两码事
Google 官方的产品页面列出了面向普通用户、企业和开发者的众多产品。另一方面，究竟把 API、认证方式还是 Cloud 的各个独立服务算作 1 件，数字也会随之改变。
因此，本图鉴的 GG 编号和管理数量只是文章管理上的数量而非 Google 公布的“服务总数”。切勿将固定数字当作官方数值来看待。
安全测试时的原则
在进行 API 实验时，切勿将 credentials、token、Service Account JSON、private key、Access Token、Refresh Token、真实账户 ID 等保存到 GitHub 中。最初的示例代码请尽可能采用读取类型，并在公开代码中使用虚拟值。
这究竟是一篇怎样的文章？
它是 Google 服务图鉴的入口。它不是靠死记硬背产品名称，而是让你通过“想做什么 → 使用哪个平台 → 哪个组件负责 → 谁来使用”的顺序来理解 Google 服务的地图。在单独的文章中，将会对这张地图上的某一个组件进行更深入的探讨。
通过 Papanda 动手体验：按“目的”筛选 Google 服务的图鉴
可见成果：在浏览器中点击“协同办公”“AI”“分析”“地图”“开发”后，仅保留对应的 GG 文章。比起勉强调用 API，这篇总论文章更适合采用 Daily Code 方案：将 GG01 到 GG160 的元数据汇总到 JSON 中，并通过静态 HTML + JavaScript 实现筛选。以能够按目的而非服务名称查找作为成功条件。
Google 官方信息
这究竟是怎样的服务？
《Google 有多少个服务？Google 服务图鉴：按用途分类整理》一文让你能够掌握本文整理的角色、使用场景和注意事项，并结合官方第一手资料进行小规模测试，从而轻松理解 Google 服务。
