GitHub 上大约有 2,000 个仓库 匹配“google maps scraper”。但其中大多数都已经坏了。
这话听起来可能有点夸张，但如果你曾经克隆过仓库、跟 Playwright 依赖项死磕过，还在凌晨 2 点盯着爬虫吐出空白 CSV，那你就知道这种感觉。Google 地图在全球有 超过 2 亿条商家信息——这是地球上最丰富的本地商家数据库之一。难怪从销售人员到代理机构老板，人人都想把这些数据提取出来。问题在于，Google 会以几周到几个月的节奏更新 Maps 的界面，而每次变化都可能悄悄搞坏你刚花一小时搭好的爬虫。正如一位 GitHub 用户在 2026 年 3 月的 issue 里说的那样，这个工具 “could not find search box on google maps.” 这不是小众边角问题，而是核心流程直接挂了。过去一年我一直密切跟踪这些仓库，我发现“GitHub 上看起来很活跃”和“今天真的能返回数据”之间的差距，比大多数人想得大得多。这篇指南是我尽量诚实地帮你分辨噪音和信号：哪些仓库还能用，哪些已经坏了，什么时候应该直接跳过 GitHub，以及在抓完数据之后该做什么。
GitHub 上的 Google 地图爬虫是什么？为什么大家都在用？
GitHub 上的 Google 地图爬虫通常是一个 Python 或 Go 脚本（有时会用 Docker 包起来），它会在无头浏览器里打开 Google 地图，运行诸如“芝加哥的牙医”之类的搜索，再提取出现的商家信息——名称、地址、电话号码、网站、评分、评论数、类别、营业时间，有时还包括经纬度坐标。
GitHub 之所以成为这类工具的默认栖身地，是因为代码免费、开源，而且理论上可以自定义。你可以 fork 仓库，调整搜索参数，加上自己的代理逻辑，然后导出成你需要的任何格式。
人们通常想提取的数据字段大致如下：
| 字段 | 在各仓库中的常见程度 |
|---|---|
| 商家名称 | 几乎都有 |
| 地址 | 几乎都有 |
| 电话号码 | 几乎都有 |
| 网站 URL | 几乎都有 |
| 星级评分 | 几乎都有 |
| 评论数 | 很常见 |
| 类别 / 类型 | 常见 |
| 营业时间 | 常见 |
| 纬度 / 经度 | 在更强的仓库中很常见 |
| 邮箱 / 社交链接 | 仅在爬虫也访问商家网站时才有 |
| 完整评论文本 | 在专门的评论爬虫中常见，但大规模爬取时可靠性较低 |
这些工具谁在用？销售团队用它们制作外呼线索名单；房地产从业者用它们绘制本地市场；电商团队用它们做竞品分析；营销人员用它们做本地 SEO 审计。共同点很简单：他们都需要结构化的本地商家数据，而且不想在浏览器里一条条复制粘贴。
为什么销售和运营团队会去搜 Google Maps Scraper GitHub 仓库
Google 地图之所以吸引人，原因很简单：本地商家信息本来就在那里。不在某个冷门目录里，也不在付费墙后面。它就摆在搜索结果里。
商业价值主要体现在三个方面。
线索生成与潜客开发
这是最核心的用途。一位为自由职业者和代理机构构建 Google 地图爬虫的创始人 直白地描述了工作流：在特定城市和细分行业里找线索，收集冷启动外联所需的联系信息，并生成包含名称、地址、电话、网站、评分、评论数、类别、营业时间、邮箱和社交账号的 CSV。最活跃的仓库之一（gosom/google-maps-scraper）甚至直接告诉用户，可以让它的 agent 去 “Find me all dentists in Berlin with their emails.” 这不是业余玩法，而是一条销售漏斗。
市场研究与竞品分析
运营和战略团队会用抓取到的 Maps 数据统计某个街区的竞争对手数量、分析评论情绪、找出空白市场。一位本地 SEO 从业者 报告称自己通过提取 Google 地图的公开数据 在单一细分领域里审计了 76,228 家本地商家。这种分析规模如果靠人工，几乎不可能完成。
本地 SEO 审计与目录站搭建
营销人员会抓取 Google 地图来审计本地搜索可见度、检查 NAP（名称、地址、电话）一致性，并搭建目录网站。有用户 描述了把抓取到的 Google 地图数据表格导入 WordPress 并借助 WP All Import 完成发布。
让抓取看起来“很值”的人工成本账
人工采集并不是因为用了浏览器窗口就免费。Upwork 上行政数据录入类虚拟助理的费用是 每小时 12–20 美元以上。如果一个人每家商家花 1 分钟抓基础信息，1,000 家商家大约要 16.7 小时——在质检前，人工成本大约是 200–334 美元。若每家花 2 分钟，同样的名单成本就会变成 400–668 美元。这才是每个“免费的 GitHub 爬虫”真正要面对的对照组。
用 AI 抓取 Google 地图数据 Get Started Free
Google Places API、GitHub 爬虫仓库、无代码工具：2026 年该怎么选？
在克隆任何东西之前，先选好路径。数据量、预算、技术能力和对维护工作的容忍度，都会影响决定。
| 判断标准 | Google Places API | GitHub 爬虫 | 无代码工具（如 Thunderbit） |
|---|---|---|---|
| 每 1,000 次查询成本 | 7–32 美元（常见 Pro 调用） | 软件免费 + 代理成本 + 时间成本 | 免费层，然后按积分计费 |
| 数据字段 | 结构化，但受 API 架构限制 | 灵活，取决于仓库 | 按网站由 AI 配置 |
| 评论访问 | 每个地点最多 5 条评论 | 如果爬虫支持，则可抓完整内容 | 取决于工具 |
| 频率限制 | 各 SKU 有免费额度，之后收费 | 需要自己管理（依赖代理） | 由服务商管理 |
| 法律清晰度 | 授权明确 | 灰色地带（有 ToS 风险） | 由服务商在运营层面处理合规 |
| 维护成本 | 由 Google 维护 | 由你维护 | 由服务商维护 |
| 搭建复杂度 | API Key + 代码 | Python + 依赖 + 代理 | 安装扩展，点击抓取 |
什么时候适合用 Google Places API
如果你只需要中小规模查询，并且希望有官方授权和可预测的计费，API 是最直接的选择。Google 2025 年 3 月的定价调整 用按 SKU 的免费额度取代了统一月度积分：很多 Essentials SKU 有 10,000 次免费调用，Pro 有 5,000 次，Enterprise 有 1,000 次。超过之后，Text Search Pro 的价格是 每 1,000 次 32 美元，Place Details Enterprise + Atmosphere 为每 1,000 次 5 美元。
最大限制是评论。API 每个地点最多只返回 5 条评论。如果你需要完整评论内容，这条路不够。
什么时候适合用 GitHub 爬虫
如果你要按关键词加地理范围批量发现数据，需要 API 字段之外的浏览器可见内容、完整评论文本，或者自定义解析逻辑，并且你有能力用 Python/Docker 维护爬虫，那么 GitHub 仓库是合适的选择。代价是，“免费”只是把账单转移到了时间、代理、重试和故障上。单是代理费就可能不低： Decodo 住宅代理从每 GB 1 美元起，Bright Data 数据中心按量付费每 GB 0.6 美元起，Oxylabs 住宅代理每 GB 6 美元起。
什么时候适合用 Thunderbit 这样的无代码工具
如果你不是技术背景，或者你只想快速把数据放进 Sheets、Airtable、Notion 或 CSV，那么无代码工具可以跳过整套 Python/Docker/代理配置。使用 Thunderbit，你只需要安装 Chrome 扩展，打开 Google 地图，点击“AI 建议字段”，然后点击“抓取”——接着就能 导出到 Google Sheets、Excel、Airtable 或 Notion。云端爬取模式会自动处理反机器人保护，可并发抓取多达 50 个页面，不需要配置代理。
免费试用 Thunderbit 进行 Google 地图抓取
简单决策流程： 如果你需要少于 500 家商家，而且有预算 → 用 API。 如果你需要上千家，而且会 Python → 用 GitHub 仓库。 如果你想快速拿到数据，不想做技术配置 → 用无代码工具。
2026 年新鲜度审计：哪些 Google Maps Scraper GitHub 仓库今天真的能用？
这正是我研究初期最希望存在的一节。大多数“最佳 Google 地图爬虫”文章只会列仓库、写一句简介，再放上星标数量。没有一篇会告诉你，这个东西这个月到底还能不能返回数据。
怎么判断一个 Google Maps Scraper GitHub 仓库还活着
在克隆任何仓库之前，先检查这份清单：
- 最近是否有代码提交： 看过去 3–6 个月内是否有真正的 commit，而不是只看 issue 评论。
- Issue 健康度： 看最近更新的 3 个 issue。它们是在说核心故障（空字段、选择器错误、浏览器崩溃），还是只是功能请求？
- README 质量： 是否说明了当前浏览器栈、Docker 配置和代理设置？
- Issue 里的红旗关键词： 搜索“search box”、“reviews_count = 0”、“driver”、“Target page”、“selector”、“empty”。
- Fork 和 PR 活动： 活跃的 fork 和已合并 PR 说明社区还在维护。
如果没有最近代码活动、核心抓取 bug 还没解决，也没有代理或浏览器维护说明，那这个仓库大概率不适合业务场景——即便星标数看起来很漂亮。
已评估的热门 Google Maps Scraper GitHub 仓库
我按上面的标准评估了星标最多的几个仓库。下面先给汇总表，再给单独说明。
| 仓库 | 星标 | 最近推送 | 2026 年还能用吗？ | 能应对界面变化吗？ | 代理支持 | 技术栈 |
|---|---|---|---|---|---|---|
| gosom/google-maps-scraper | 3.7k | 2026-04-19 | ⚠️ 核心提取还活着；评论字段偶有波动 | 持续维护 | 有，明确支持 | Go + Playwright |
| omkarcloud/google-maps-scraper | 2.6k | 2026-04-10 | ⚠️ 应用活跃，但有崩溃/支持问题 | 由厂商维护 | 未明确说明 | 桌面应用 / 二进制 |
| gaspa93/googlemaps-scraper | 498 | 2026-03-26 | ⚠️ 只适合窄范围评论爬取 | 证据有限 | 没有强有力的代理方案 | Python |
| conor-is-my-name/google-maps-scraper | 284 | 2026-04-14 | ⚠️ Docker 流程有前景，但 3 月出现选择器故障 | 有一些修复迹象 | 已容器化，但代理不清楚 | Python + Docker |
| Zubdata/Google-Maps-Scraper | 120 | 2025-01-19 | ❌ 过多过时 / 空字段问题 | 证据很少 | 不突出 | Python GUI |
| patxijuaristi/google_maps_scraper | 113 | 2025-02-24 | ❌ 早期 Chrome driver 问题信号明显 | 证据很少 | 没有强有力的证据 | Python |
gosom/google-maps-scraper
目前是最强的开源通用型选择。README 的成熟度非常高：CLI、Web UI、REST API、Docker 说明、代理配置、网格/边界框模式、邮箱提取以及多种导出目标。它声称支持 33+ 个数据点，并明确说明了代理，因为“对于更大规模的抓取任务，代理有助于避免频率限制”。
它的问题不是停更，而是边缘字段的准确性漂移。2026 年最近的 issue 显示：“reviews_count” = 0、user_reviews 返回空数组、以及 open_hours 只写入周三。所以它用于抓商家列表信息还是可信的，但在评论和营业时间这类富数据上，在修复落地前会比较不稳。
omkarcloud/google-maps-scraper
它的星标数和存在时间让它很显眼，但读起来更像一个打包好的提取产品，而不是透明的开源项目——支持渠道、桌面安装包、增值服务等都很明显。2026 年 4 月有用户说，应用启动后终端不断刷出 “Target page, context or browser has been closed” 错误，最后卡死。另一个未解决 issue 抱怨它 “Very slow and inefficient.” 它不是死掉了，但对想要可审查、可自己打补丁的 OSS 的读者来说，它也不是最干净利落的答案。
gaspa93/googlemaps-scraper
它不是通用批量搜索的线索生成爬虫，而是一个聚焦的 评论爬虫：从特定的 Google Maps POI 评论 URL 出发，抓取最新评论，并支持元数据抓取和评论排序。这个更窄的范围对某些工作流其实是优点——但它并没有解决大多数业务用户最关心的查询发现问题。
conor-is-my-name/google-maps-scraper
它的思路很适合现代运营团队：优先 Docker 安装、JSON API、适合业务的字段，而且在 r/n8n 里也有社区曝光。但 2026 年 3 月的 issue 很能说明这一类工具的脆弱性：某个用户更新了容器后，输出显示爬虫 “could not find search box on google maps.” 这属于核心流程失败，而不是外观上的小毛病。
Zubdata/Google-Maps-Scraper
从纸面上看，它提供的字段很多：邮箱、评论、评分、地址、网站、电话、类别、营业时间。但实际公开 issue 暴露出来的情况完全不同：用户报告 应用包里缺少资源文件、电话/地址/网站字段为空，以及 抓取限制。再加上它较早的推送历史，很难推荐给 2026 年使用。
patxijuaristi/google_maps_scraper
在 GitHub 搜索里很容易找到，但最强的公开信号只是一个 旧的 Chrome-driver 错误 issue，而不是活跃维护。本文把它收进来，主要是因为它很能说明“搜索里看起来活着，但实际用起来很危险”是什么意思。
分步教程：如何从 GitHub 搭建一个 Google Maps 爬虫
你已经决定 GitHub 仓库是正确路径了？下面就是实际搭建会经历什么。我会尽量保持通用，而不是按某个仓库单独展开——因为这些活跃方案之间的步骤惊人地相似。
步骤 1：克隆仓库并安装依赖
常见路径是：
- 用
git clone克隆仓库 - 创建 Python 虚拟环境（或者拉取 Docker 镜像）
- 通过
pip install -r requirements.txt或docker-compose up安装依赖 - 有时还要安装浏览器运行时（Playwright 用 Chromium，Selenium 用 ChromeDriver）
像 gosom/google-maps-scraper 和 conor-is-my-name/google-maps-scraper 这种优先 Docker 的仓库可以减少依赖问题，但并不会完全消除——你还是需要 Docker 正常运行，并且有足够磁盘空间存放浏览器镜像。
步骤 2：配置搜索参数
大多数通用爬虫会需要：
- 关键词 + 地点（例如“奥斯汀的管道工”）
- 结果上限（要提取多少条列表）
- 输出格式（CSV、JSON、数据库）
- 有时还会有 地理边界框 或半径，用于网格化发现
更成熟的仓库会把这些暴露成 CLI 参数或 JSON 请求体。老旧仓库可能要求你直接修改 Python 文件。
步骤 3：设置代理（如果需要）
只要不是很小的测试跑批，最好都上代理。gosom/google-maps-scraper 文档里说明了 HTTP/HTTPS/SOCKS5 代理轮换，并且明确把代理视为大任务的标准解法。没有代理的话，跑几十次请求后就很可能遇到验证码或 IP 封锁。
步骤 4：运行爬虫并导出数据
运行脚本，看浏览器遍历结果卡片，然后等待 CSV 或 JSON 输出。顺利的话只要几分钟。不顺利的话——而这比任何人愿意承认的都更常见——通常会出现：
- 浏览器意外关闭
- Chrome driver 版本不匹配
- 选择器 / 搜索框失败
- 评论数或营业时间抓取为空
步骤 5：处理错误和故障
当爬虫返回空结果或报错时：
- 去仓库的 GitHub Issues 里找类似报告
- 查看 Google Maps 是否发生了 UI 变化（新的选择器、不同的页面结构）
- 更新到最新提交
- 如果维护者还没修复，看看 fork 里有没有社区补丁
- 评估一下，花在调试上的时间是否比换工具更值得
现实中的首次搭建时间： 对于会用终端，但还没有现成可用的 Playwright/Docker/代理环境的人来说，30–90 分钟 才更接近第一次成功抓取的真实区间，不是 5 分钟。
如何在抓取 Google 地图时避免封禁和频率限制
Google 并没有公开一个“请求超过 X 次就会被封”的地图阈值。它刻意把这件事做得很模糊。有些用户报告，在服务器端 Playwright 环境下大约跑了 50 次自动请求 后就开始遇到验证码。另一个用户则声称，某个公司自建的 Maps 爬虫能从单个 IP 每天发出 10,000 个查询。阈值并不高，也不低，而是 不稳定且依赖上下文。
下面是一张实用策略表：
| 策略 | 难度 | 效果 | 成本 |
|---|---|---|---|
| 请求之间加入随机延迟（2–5 秒） | 低 | 中 | 免费 |
| 降低并发（减少并行会话） | 低 | 中 | 免费 |
| 住宅代理轮换 | 中 | 高 | 每 GB 1–6 美元 |
| 数据中心代理（适合容易目标） | 中 | 中 | 每 GB 0.02–0.6 美元 |
| 无头浏览器指纹随机化 | 高 | 高 | 免费 |
| 浏览器持久化 / 预热会话 | 中 | 中 | 免费 |
| 基于云的抓取（把问题外包出去） | 低 | 高 | 不同而定 |
在请求之间加入随机延迟
固定 1 秒间隔很容易暴露。最好用随机抖动——每次动作之间间隔 2 到 5 秒，偶尔再加长一点。这个方法最容易做，而且完全不花钱。
轮换代理（住宅代理 vs 数据中心代理）
住宅代理更有效，因为它们更像真实用户，但价格也更高。当前价格： Decodo 住宅代理每 GB 1 美元起，Oxylabs 住宅代理每 GB 6 美元起，Oxylabs 数据中心代理每 GB 0.59 美元起。数据中心代理适合轻量抓取，但在 Google 相关产品上更容易被标记。
随机化浏览器指纹
对于无头浏览器爬虫：轮换 user agent、视口大小和其他指纹信号。默认的 Playwright/Puppeteer 配置很容易被识别。这个方法实现起来更难，但免费且非常有效。
用云端抓取把问题外包出去
像 Thunderbit 这样的工具会通过云端抓取基础设施自动处理反机器人保护、IP 轮换和频率限制。Thunderbit 云端模式下 可并发抓取多达 50 个页面，不需要代理配置或延迟配置。对于不想兼职做反机器人工程师的团队来说，这是最实用的路径。
Google 的频率限制实际上会是什么样
你已经被限流的迹象包括：
- 抓取过程中突然出现验证码
- 之前能成功的查询突然返回空结果
- 临时 IP 封锁（通常持续 1–24 小时）
- 页面加载退化（更慢、内容不完整）
恢复方法：停止抓取、轮换 IP、等待 15–60 分钟，再以更低并发继续。如果你经常碰到限制，说明你的方案需要代理，或者需要完全不同的思路。
无代码逃生门：什么时候 Google Maps Scraper GitHub 仓库不值得你花时间
大约 90% 的 Google Maps 抓取文章都默认读者会 Python。但很大一部分目标受众——代理机构老板、销售代表、本地 SEO 团队、研究人员——只想把行数据放进表格里，而不是做一个浏览器自动化项目。如果你就是这种情况，这一节会诚实地讲清楚权衡。
“免费” GitHub 爬虫的真实成本
| 因素 | GitHub 仓库方案 | 无代码替代方案（如 Thunderbit） |
|---|---|---|
| 搭建时间 | 30–90 分钟（Python/Docker/代理） | 约 2 分钟（浏览器扩展） |
| 维护 | 手动（你来修故障） | 自动（服务商维护） |
| 自定义能力 | 高（完整代码权限） | 中等（AI 配置字段） |
| 成本 | 软件免费，但有时间 + 代理成本 | 有免费层，然后按 积分计费 |
| 规模化 | 取决于你的基础设施 | 云端扩展 |
“免费”的 GitHub 爬虫只是把账单转移到了时间上。如果你把自己的时间按每小时 50 美元估算，而你花了 2 小时搭建 + 1 小时排错 + 30 分钟配置代理，那在你抓到第一条列表之前，成本就已经是 175 美元了。再加上代理费用和 Google 改 UI 后的持续维护，“免费”很快就会显得很贵。
Thunderbit 如何简化 Google 地图抓取
使用 Thunderbit 的实际流程是这样的：
- 安装 Thunderbit Chrome 扩展
- 打开 Google 地图并运行搜索
- 点击 “AI 建议字段”——Thunderbit 的 AI 会读取页面并建议列（商家名称、地址、电话、评分、网站等）
- 点击 “抓取”，数据会自动结构化
- 使用 子页面抓取 功能，从抓到的 URL 进入每家商家的网站，提取更多联系信息（邮箱、电话号码）——把 GitHub 仓库用户手动做的事自动化
- 导出到 Google Sheets、Excel、Airtable 或 Notion——导出没有付费墙
没有 Python，没有 Docker，没有代理，没有维护。对做销售和营销线索生成的团队来说，这直接消除了 GitHub 仓库需要的整套搭建负担。
价格背景： Thunderbit 采用积分模型，1 积分 = 1 行输出。免费层每月覆盖 6 个页面，免费试用覆盖 10 个页面，入门方案为 每月 15 美元或每年 9 美元，可获得每月 500 积分。
抓完之后：清洗并丰富你的 Google 地图数据
大多数指南都止步于原始提取。但原始数据不等于线索名单。论坛用户经常报告 “很多格式问题，需要大量清洗数据” ，还会问：“这种方案怎么处理重复项？”下面就是抓取之后该做什么。
去重你的结果
重复数据通常来自分页重叠、在重叠区域重复搜索、网格 / 边界框策略覆盖到同一批商家，以及一家商家有多个列表。
最佳实践的去重顺序：
- 如果爬虫暴露了 place_id，优先用它匹配（最可靠）
- 对 规范化后的商家名称 + 地址 做精确匹配
- 对名称 + 地址做模糊匹配，再用电话或网站确认
简单的 Excel/Sheets 公式（COUNTIF、删除重复项）可以处理大多数情况。对于更大的数据集，用 pandas 写一个快速 Python 去重脚本也很好用。
规范化电话号码和地址
抓到的电话号码格式五花八门：(555) 123-4567、555-123-4567、+15551234567、5551234567。导入 CRM 时，最好统一成 E.164 格式——也就是“+ 国家码 + 本地号码”，例如 +15551234567。
Thunderbit 在抓取时会自动把电话号码规范化为 E.164，又少了一步清洗。
地址则应统一成一致格式：街道、城市、州、邮编。去掉多余空格，修正缩写不一致（St vs Street），如果准确性很重要，再用地理编码服务验证。
补充邮箱、网站和社交资料
Google 地图列表几乎总会包含网站 URL，但几乎不会直接给出邮箱地址。最有效的模式是：
- 先从 Maps 抓取商家发现信息（名称、地址、电话、网站 URL）
- 再访问每家商家网站，提取邮箱、社交链接和其他联系信息
这正是最好的 GitHub 仓库和无代码工具开始交汇的地方：
- gosom/google-maps-scraper 支持可选的邮箱提取，通过访问商家网站完成
- Thunderbit 的子页面抓取功能 可以从抓到的 URL 访问每家商家网站，提取邮箱和电话号码——并且全部追加回你的原始表格
对于没有内置丰富信息采集功能的 GitHub 仓库用户来说，这意味着你要么再写一个爬虫，要么手动访问每个网站。Thunderbit 把这两个步骤压缩成一个工作流。
导出到你的 CRM 或工作流工具
最实用的导出目标有：
- Google Sheets：方便协作清洗和共享
- Airtable：适合有筛选和视图的结构化数据库
- Notion：适合轻量运营数据库
- CSV/JSON：用于 CRM 导入或下游自动化
Thunderbit 支持 直接导出到以上所有工具。大多数 GitHub 仓库只导出 CSV 或 JSON——你还得自己处理 CRM 集成。如果你还想了解更多把抓取数据导入表格的方法，可以看看我们的指南：如何抓取到 Google Sheets。
Google Maps Scraper GitHub 仓库：完整横向对比
下面这张表可以直接收藏：
| 工具 / 仓库 | 类型 | 成本模式 | 搭建时间 | 代理管理 | 维护 | 导出选项 | 2026 年还能用吗？ |
|---|---|---|---|---|---|---|---|
| Google Places API | 官方 API | 7–32 美元 / 1K 次调用（Pro） | 低 | 不需要 | 低 | JSON / 应用集成 | ✅ |
| gosom/google-maps-scraper | GitHub 开源 | 免费 + 代理 + 时间 | 中 | 有，已说明 | 高 | CSV、JSON、数据库、API | ⚠️ |
| omkarcloud/google-maps-scraper | GitHub 打包工具 | 表面免费，实为产品化 | 中 | 不明确 | 中-高 | 应用输出 | ⚠️ |
| gaspa93/googlemaps-scraper | GitHub 评论爬虫 | 免费 + 时间 | 中 | 有限 | 中-高 | CSV | ⚠️（细分） |
| conor-is-my-name/google-maps-scraper | GitHub Docker API | 免费 + 时间 | 中 | 可能需要 | 高 | JSON / Docker 服务 | ⚠️ |
| Zubdata/Google-Maps-Scraper | GitHub GUI 应用 | 免费 + 时间 | 中 | 有限 | 高 | 应用输出 | ❌ |
| Thunderbit | 无代码扩展 | 积分 / 行 | 低 | 已抽象处理（云端） | 低-中 | Sheets、Excel、Airtable、Notion、CSV、JSON | ✅ |
如果你想进一步了解不同抓取方案之间的取舍，还可以看看我们的 最佳自动化网页抓取工具 汇总，或者 网页抓取与数据挖掘的区别 的对比。
法律与服务条款注意事项
这部分很简短，但很重要。
Google 当前的 Maps Platform 条款写得很明确：客户不得 “export, extract, or otherwise scrape Google Maps Content for use outside the Services,” 包括在许可服务使用之外复制和保存商家名称、地址或用户评论。Google 的服务特定条款还只允许对某些 API 进行有限缓存，通常 最多连续 30 个自然日。
法律层级很清楚：
- 使用 API 的合同基础最明确
- GitHub 爬虫 处在更模糊的地带
- 无代码工具 可以减轻你的运营负担，但不会消除你自己的合规义务
具体用例请咨询你自己的法律顾问。关于法律环境的更深入分析，我们另有一篇文章介绍 网页抓取的法律影响。
核心结论：2026 年该如何选择 Google Maps Scraper 方案
在翻了仓库、issue、论坛和定价页之后，结论如下：
-
在投入搭建时间之前，一定先检查仓库新鲜度。 星标数并不等于“今天能用”。看最近 3 个 issue，再看过去 3–6 个月有没有代码提交。
-
目前最好的开源选择是 gosom/google-maps-scraper——但它在 2026 年依然出现了新的字段回归问题。把它当成需要监控的活系统，而不是一次设置完就忘掉的工具。
-
Google Places API 是追求稳定性和法律清晰度的正确答案——但它有局限（最多 5 条评论、按次计费），也不太适合大规模发现。
-
对于非技术团队，无代码工具如 Thunderbit 是最实用的替代方案。 从搭建到拿到第一批数据只要几分钟，不用把自己变成兼职爬虫维护者。
-
原始数据只完成了一半。 你还需要预算去重、电话号码规范化、邮箱补全和 CRM 导出所需的时间。能自动处理这些步骤的工具（比如 Thunderbit 的子页面抓取和 E.164 规范化）往往比大多数人预想的更省时。
-
“免费爬虫”最好理解为带着未付维护费的软件。 如果你有技能，也享受这个过程，那完全没问题。但如果你只是个销售代表，星期五之前需要 500 条凤凰城牙医线索，那这就不是好买卖。
如果你想进一步探索商家数据提取方案，可以看看我们关于 用 Python 抓取 Google 地图、最佳 Google 地图评论爬虫 和 最佳数据提取工具 的指南。你还可以在 Thunderbit YouTube 频道 观看教程。
常见问题
在 GitHub 上使用 Google Maps 爬虫是免费的吗？
软件是免费的，但工作不是。你会投入 30–90 分钟搭建，之后还要持续花时间处理故障；如果数据量稍大，通常还要每月支付 10–100 美元以上的代理费用。如果你的时间有价值，“免费”这个说法并不准确。
使用 GitHub 上的 Google Maps 爬虫需要 Python 技能吗？
大多数热门仓库都需要基础的 Python 和命令行知识。优先 Docker 的仓库可以减轻负担，但不会完全消除——你还是得排查容器问题、配置搜索参数并处理代理设置。对非技术用户来说，像 Thunderbit 这样的无代码工具提供了一个只需 2 次点击、无需编程的替代方案。
Google Maps 爬虫 GitHub 仓库多久会坏一次？
没有固定时间表，但当前 GitHub issue 历史显示，核心故障和字段回归会以 几周到几个月 的周期出现。Google 会 नियमित更新 Maps 界面，这可能在一夜之间搞坏选择器和解析逻辑。活跃仓库会很快修复，停更仓库则会一直坏下去。
我能用 GitHub 爬虫抓 Google 地图评论吗？
有些仓库支持完整评论提取（gaspa93/googlemaps-scraper 就是专门为此设计的），而另一些只能抓评分、评论数这类汇总数据。评论也是 Google 改变页面行为时最先失真的字段之一——所以即便仓库支持评论，在 UI 更新后也可能只返回不完整的数据。
如果我不想用 GitHub 爬虫，最好的替代方案是什么？
主要有两条路：一条是 Google Places API，可获得官方、结构化的访问方式，但有成本和字段限制；另一条是 像 Thunderbit 这样的无代码工具，可以快速、由 AI 驱动地提取数据，而且无需编程。API 最适合需要合规确定性的开发者。Thunderbit 最适合需要快速把数据放进表格里的业务用户。
了解更多
