Google 地图爬虫 GitHub：到 2026 年哪些能用，哪些会坏

GitHub 上大约有 匹配“google maps scraper”。但其中大多数都已经坏了。

这话听起来可能有点夸张，但如果你曾经克隆过仓库、跟 Playwright 依赖项死磕过，还在凌晨 2 点盯着爬虫吐出空白 CSV，那你就知道这种感觉。Google 地图在全球有 ——这是地球上最丰富的本地商家数据库之一。难怪从销售人员到代理机构老板，人人都想把这些数据提取出来。问题在于，Google 会以几周到几个月的节奏更新 Maps 的界面，而每次变化都可能悄悄搞坏你刚花一小时搭好的爬虫。正如一位 GitHub 用户在 2026 年 3 月的 issue 里说的那样，这个工具 这不是小众边角问题，而是核心流程直接挂了。过去一年我一直密切跟踪这些仓库，我发现“GitHub 上看起来很活跃”和“今天真的能返回数据”之间的差距，比大多数人想得大得多。这篇指南是我尽量诚实地帮你分辨噪音和信号：哪些仓库还能用，哪些已经坏了，什么时候应该直接跳过 GitHub，以及在抓完数据之后该做什么。

GitHub 上的 Google 地图爬虫是什么？为什么大家都在用？

GitHub 上的 Google 地图爬虫通常是一个 Python 或 Go 脚本（有时会用 Docker 包起来），它会在无头浏览器里打开 Google 地图，运行诸如“芝加哥的牙医”之类的搜索，再提取出现的商家信息——名称、地址、电话号码、网站、评分、评论数、类别、营业时间，有时还包括经纬度坐标。

GitHub 之所以成为这类工具的默认栖身地，是因为代码免费、开源，而且理论上可以自定义。你可以 fork 仓库，调整搜索参数，加上自己的代理逻辑，然后导出成你需要的任何格式。

人们通常想提取的数据字段大致如下：

这些工具谁在用？销售团队用它们制作外呼线索名单；房地产从业者用它们绘制本地市场；电商团队用它们做竞品分析；营销人员用它们做本地 SEO 审计。共同点很简单：他们都需要结构化的本地商家数据，而且不想在浏览器里一条条复制粘贴。

为什么销售和运营团队会去搜 Google Maps Scraper GitHub 仓库

Google 地图之所以吸引人，原因很简单：本地商家信息本来就在那里。不在某个冷门目录里，也不在付费墙后面。它就摆在搜索结果里。

商业价值主要体现在三个方面。

线索生成与潜客开发

这是最核心的用途。一位为自由职业者和代理机构构建 Google 地图爬虫的创始人 ：在特定城市和细分行业里找线索，收集冷启动外联所需的联系信息，并生成包含名称、地址、电话、网站、评分、评论数、类别、营业时间、邮箱和社交账号的 CSV。最活跃的仓库之一（gosom/google-maps-scraper）甚至直接告诉用户，可以让它的 agent 去 这不是业余玩法，而是一条销售漏斗。

市场研究与竞品分析

运营和战略团队会用抓取到的 Maps 数据统计某个街区的竞争对手数量、分析评论情绪、找出空白市场。一位本地 SEO 从业者 在单一细分领域里审计了 76,228 家本地商家。这种分析规模如果靠人工，几乎不可能完成。

本地 SEO 审计与目录站搭建

营销人员会抓取 Google 地图来审计本地搜索可见度、检查 NAP（名称、地址、电话）一致性，并搭建目录网站。有用户 并借助 WP All Import 完成发布。

让抓取看起来“很值”的人工成本账

人工采集并不是因为用了浏览器窗口就免费。Upwork 上行政数据录入类虚拟助理的费用是 。如果一个人每家商家花 1 分钟抓基础信息，1,000 家商家大约要 16.7 小时——在质检前，人工成本大约是 200–334 美元。若每家花 2 分钟，同样的名单成本就会变成 400–668 美元。这才是每个“免费的 GitHub 爬虫”真正要面对的对照组。

Google Places API、GitHub 爬虫仓库、无代码工具：2026 年该怎么选？

在克隆任何东西之前，先选好路径。数据量、预算、技术能力和对维护工作的容忍度，都会影响决定。

什么时候适合用 Google Places API

如果你只需要中小规模查询，并且希望有官方授权和可预测的计费，API 是最直接的选择。Google 用按 SKU 的免费额度取代了统一月度积分：很多 Essentials SKU 有 ，Pro 有 5,000 次，Enterprise 有 1,000 次。超过之后，Text Search Pro 的价格是 ，Place Details Enterprise + Atmosphere 为每 1,000 次 5 美元。

最大限制是评论。API 每个地点最多只返回 。如果你需要完整评论内容，这条路不够。

什么时候适合用 GitHub 爬虫

如果你要按关键词加地理范围批量发现数据，需要 API 字段之外的浏览器可见内容、完整评论文本，或者自定义解析逻辑，并且你有能力用 Python/Docker 维护爬虫，那么 GitHub 仓库是合适的选择。代价是，“免费”只是把账单转移到了时间、代理、重试和故障上。单是代理费就可能不低： ，，。

什么时候适合用 Thunderbit 这样的无代码工具

如果你不是技术背景，或者你只想快速把数据放进 Sheets、Airtable、Notion 或 CSV，那么无代码工具可以跳过整套 Python/Docker/代理配置。使用 ，你只需要安装 Chrome 扩展，打开 Google 地图，点击“AI 建议字段”，然后点击“抓取”——接着就能 。云端爬取模式会自动处理反机器人保护，，不需要配置代理。

简单决策流程： 如果你需要少于 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 仓库

我按上面的标准评估了星标最多的几个仓库。下面先给汇总表，再给单独说明。

gosom/google-maps-scraper

目前是最强的开源通用型选择。README 的成熟度非常高：CLI、Web UI、REST API、Docker 说明、代理配置、网格/边界框模式、邮箱提取以及多种导出目标。它声称支持 ，并明确说明了代理，因为“对于更大规模的抓取任务，代理有助于避免频率限制”。

它的问题不是停更，而是边缘字段的准确性漂移。2026 年最近的 issue 显示：、、以及 。所以它用于抓商家列表信息还是可信的，但在评论和营业时间这类富数据上，在修复落地前会比较不稳。

omkarcloud/google-maps-scraper

它的星标数和存在时间让它很显眼，但读起来更像一个打包好的提取产品，而不是透明的开源项目——支持渠道、桌面安装包、增值服务等都很明显。2026 年 4 月有用户说，应用启动后终端不断刷出 ，最后卡死。另一个未解决 issue 抱怨它 它不是死掉了，但对想要可审查、可自己打补丁的 OSS 的读者来说，它也不是最干净利落的答案。

gaspa93/googlemaps-scraper

它不是通用批量搜索的线索生成爬虫，而是一个聚焦的 ：从特定的 Google Maps POI 评论 URL 出发，抓取最新评论，并支持元数据抓取和评论排序。这个更窄的范围对某些工作流其实是优点——但它并没有解决大多数业务用户最关心的查询发现问题。

conor-is-my-name/google-maps-scraper

它的思路很适合现代运营团队：优先 Docker 安装、JSON API、适合业务的字段，而且在 里也有社区曝光。但 2026 年 3 月的 issue 很能说明这一类工具的脆弱性：某个用户更新了容器后，输出显示爬虫 这属于核心流程失败，而不是外观上的小毛病。

Zubdata/Google-Maps-Scraper

从纸面上看，它提供的字段很多：邮箱、评论、评分、地址、网站、电话、类别、营业时间。但实际公开 issue 暴露出来的情况完全不同：用户报告 、，以及 。再加上它较早的推送历史，很难推荐给 2026 年使用。

patxijuaristi/google_maps_scraper

在 GitHub 搜索里很容易找到，但最强的公开信号只是一个 ，而不是活跃维护。本文把它收进来，主要是因为它很能说明“搜索里看起来活着，但实际用起来很危险”是什么意思。

分步教程：如何从 GitHub 搭建一个 Google Maps 爬虫

你已经决定 GitHub 仓库是正确路径了？下面就是实际搭建会经历什么。我会尽量保持通用，而不是按某个仓库单独展开——因为这些活跃方案之间的步骤惊人地相似。

步骤 1：克隆仓库并安装依赖

常见路径是：

1. 用 git clone 克隆仓库
2. 创建 Python 虚拟环境（或者拉取 Docker 镜像）
3. 通过 pip install -r requirements.txt 或 docker-compose up 安装依赖
4. 有时还要安装浏览器运行时（Playwright 用 Chromium，Selenium 用 ChromeDriver）

像 和 这种优先 Docker 的仓库可以减少依赖问题，但并不会完全消除——你还是需要 Docker 正常运行，并且有足够磁盘空间存放浏览器镜像。

步骤 2：配置搜索参数

大多数通用爬虫会需要：

• 关键词 + 地点（例如“奥斯汀的管道工”）
• 结果上限（要提取多少条列表）
• 输出格式（CSV、JSON、数据库）
• 有时还会有 地理边界框 或半径，用于网格化发现

更成熟的仓库会把这些暴露成 CLI 参数或 JSON 请求体。老旧仓库可能要求你直接修改 Python 文件。

步骤 3：设置代理（如果需要）

只要不是很小的测试跑批，最好都上代理。，并且明确把代理视为大任务的标准解法。没有代理的话，跑几十次请求后就很可能遇到验证码或 IP 封锁。

步骤 4：运行爬虫并导出数据

运行脚本，看浏览器遍历结果卡片，然后等待 CSV 或 JSON 输出。顺利的话只要几分钟。不顺利的话——而这比任何人愿意承认的都更常见——通常会出现：

• 浏览器意外关闭
• Chrome driver 版本不匹配
• 选择器 / 搜索框失败
• 评论数或营业时间抓取为空

这四种模式都出现在 中。

步骤 5：处理错误和故障

当爬虫返回空结果或报错时：

1. 去仓库的 GitHub Issues 里找类似报告
2. 查看 Google Maps 是否发生了 UI 变化（新的选择器、不同的页面结构）
3. 更新到最新提交
4. 如果维护者还没修复，看看 fork 里有没有社区补丁
5. 评估一下，花在调试上的时间是否比换工具更值得

现实中的首次搭建时间： 对于会用终端，但还没有现成可用的 Playwright/Docker/代理环境的人来说，30–90 分钟 才更接近第一次成功抓取的真实区间，不是 5 分钟。

如何在抓取 Google 地图时避免封禁和频率限制

Google 并没有公开一个“请求超过 X 次就会被封”的地图阈值。它刻意把这件事做得很模糊。有些用户报告，在服务器端 Playwright 环境下大约跑了 后就开始遇到验证码。另一个用户则声称，某个公司自建的 Maps 爬虫能从单个 IP 每天发出 。阈值并不高，也不低，而是 不稳定且依赖上下文。

下面是一张实用策略表：

在请求之间加入随机延迟

固定 1 秒间隔很容易暴露。最好用随机抖动——每次动作之间间隔 2 到 5 秒，偶尔再加长一点。这个方法最容易做，而且完全不花钱。

轮换代理（住宅代理 vs 数据中心代理）

住宅代理更有效，因为它们更像真实用户，但价格也更高。当前价格： ，，。数据中心代理适合轻量抓取，但在 Google 相关产品上更容易被标记。

随机化浏览器指纹

对于无头浏览器爬虫：轮换 user agent、视口大小和其他指纹信号。默认的 Playwright/Puppeteer 配置很容易被识别。这个方法实现起来更难，但免费且非常有效。

用云端抓取把问题外包出去

像 这样的工具会通过云端抓取基础设施自动处理反机器人保护、IP 轮换和频率限制。Thunderbit 云端模式下 ，不需要代理配置或延迟配置。对于不想兼职做反机器人工程师的团队来说，这是最实用的路径。

Google 的频率限制实际上会是什么样

你已经被限流的迹象包括：

• 抓取过程中突然出现验证码
• 之前能成功的查询突然返回空结果
• 临时 IP 封锁（通常持续 1–24 小时）
• 页面加载退化（更慢、内容不完整）

恢复方法：停止抓取、轮换 IP、等待 15–60 分钟，再以更低并发继续。如果你经常碰到限制，说明你的方案需要代理，或者需要完全不同的思路。

无代码逃生门：什么时候 Google Maps Scraper GitHub 仓库不值得你花时间

大约 90% 的 Google Maps 抓取文章都默认读者会 Python。但很大一部分目标受众——代理机构老板、销售代表、本地 SEO 团队、研究人员——只想把行数据放进表格里，而不是做一个浏览器自动化项目。如果你就是这种情况，这一节会诚实地讲清楚权衡。

“免费” GitHub 爬虫的真实成本

“免费”的 GitHub 爬虫只是把账单转移到了时间上。如果你把自己的时间按每小时 50 美元估算，而你花了 2 小时搭建 + 1 小时排错 + 30 分钟配置代理，那在你抓到第一条列表之前，成本就已经是 175 美元了。再加上代理费用和 Google 改 UI 后的持续维护，“免费”很快就会显得很贵。

Thunderbit 如何简化 Google 地图抓取

使用 的实际流程是这样的：

1. 安装
2. 打开 Google 地图并运行搜索
3. 点击 “AI 建议字段”——Thunderbit 的 AI 会读取页面并建议列（商家名称、地址、电话、评分、网站等）
4. 点击 “抓取”，数据会自动结构化
5. 使用 子页面抓取 功能，从抓到的 URL 进入每家商家的网站，提取更多联系信息（邮箱、电话号码）——把 GitHub 仓库用户手动做的事自动化
6. 导出到 ——导出没有付费墙

没有 Python，没有 Docker，没有代理，没有维护。对做销售和营销线索生成的团队来说，这直接消除了 GitHub 仓库需要的整套搭建负担。

价格背景： Thunderbit 采用积分模型，。免费层每月覆盖 6 个页面，免费试用覆盖 10 个页面，入门方案为 。

抓完之后：清洗并丰富你的 Google 地图数据

大多数指南都止步于原始提取。但原始数据不等于线索名单。论坛用户经常报告 ，还会问：“这种方案怎么处理重复项？”下面就是抓取之后该做什么。

去重你的结果

重复数据通常来自分页重叠、在重叠区域重复搜索、网格 / 边界框策略覆盖到同一批商家，以及一家商家有多个列表。

最佳实践的去重顺序：

1. 如果爬虫暴露了 place_id，优先用它匹配（最可靠）
2. 对 规范化后的商家名称 + 地址 做精确匹配
3. 对名称 + 地址做模糊匹配，再用电话或网站确认

简单的 Excel/Sheets 公式（COUNTIF、删除重复项）可以处理大多数情况。对于更大的数据集，用 pandas 写一个快速 Python 去重脚本也很好用。

规范化电话号码和地址

抓到的电话号码格式五花八门：(555) 123-4567、555-123-4567、+15551234567、5551234567。导入 CRM 时，最好统一成 E.164 格式——也就是“+ 国家码 + 本地号码”，例如 +15551234567。

，又少了一步清洗。

地址则应统一成一致格式：街道、城市、州、邮编。去掉多余空格，修正缩写不一致（St vs Street），如果准确性很重要，再用地理编码服务验证。

补充邮箱、网站和社交资料

Google 地图列表几乎总会包含网站 URL，但几乎不会直接给出邮箱地址。最有效的模式是：

1. 先从 Maps 抓取商家发现信息（名称、地址、电话、网站 URL）
2. 再访问每家商家网站，提取邮箱、社交链接和其他联系信息

这正是最好的 GitHub 仓库和无代码工具开始交汇的地方：

• ，通过访问商家网站完成
• 可以从抓到的 URL 访问每家商家网站，提取邮箱和电话号码——并且全部追加回你的原始表格

对于没有内置丰富信息采集功能的 GitHub 仓库用户来说，这意味着你要么再写一个爬虫，要么手动访问每个网站。Thunderbit 把这两个步骤压缩成一个工作流。

导出到你的 CRM 或工作流工具

最实用的导出目标有：

• Google Sheets：方便协作清洗和共享
• Airtable：适合有筛选和视图的结构化数据库
• Notion：适合轻量运营数据库
• CSV/JSON：用于 CRM 导入或下游自动化

Thunderbit 支持 。大多数 GitHub 仓库只导出 CSV 或 JSON——你还得自己处理 CRM 集成。如果你还想了解更多把抓取数据导入表格的方法，可以看看我们的指南：。

Google Maps Scraper GitHub 仓库：完整横向对比

下面这张表可以直接收藏：

如果你想进一步了解不同抓取方案之间的取舍，还可以看看我们的 汇总，或者 的对比。

法律与服务条款注意事项

这部分很简短，但很重要。

Google 当前的 Maps Platform 条款写得很明确：客户不得 包括在许可服务使用之外复制和保存商家名称、地址或用户评论。Google 的服务特定条款还只允许对某些 API 进行有限缓存，通常 。

法律层级很清楚：

• 使用 API 的合同基础最明确
• GitHub 爬虫 处在更模糊的地带
• 无代码工具 可以减轻你的运营负担，但不会消除你自己的合规义务

具体用例请咨询你自己的法律顾问。关于法律环境的更深入分析，我们另有一篇文章介绍 。

核心结论：2026 年该如何选择 Google Maps Scraper 方案

在翻了仓库、issue、论坛和定价页之后，结论如下：

1. 在投入搭建时间之前，一定先检查仓库新鲜度。 星标数并不等于“今天能用”。看最近 3 个 issue，再看过去 3–6 个月有没有代码提交。

2. 目前最好的开源选择是 gosom/google-maps-scraper——但它在 2026 年依然出现了新的字段回归问题。把它当成需要监控的活系统，而不是一次设置完就忘掉的工具。

3. Google Places API 是追求稳定性和法律清晰度的正确答案——但它有局限（最多 5 条评论、按次计费），也不太适合大规模发现。

4. 对于非技术团队，无代码工具如 是最实用的替代方案。 从搭建到拿到第一批数据只要几分钟，不用把自己变成兼职爬虫维护者。

5. 原始数据只完成了一半。 你还需要预算去重、电话号码规范化、邮箱补全和 CRM 导出所需的时间。能自动处理这些步骤的工具（比如 Thunderbit 的子页面抓取和 E.164 规范化）往往比大多数人预想的更省时。

6. “免费爬虫”最好理解为带着未付维护费的软件。 如果你有技能，也享受这个过程，那完全没问题。但如果你只是个销售代表，星期五之前需要 500 条凤凰城牙医线索，那这就不是好买卖。

如果你想进一步探索商家数据提取方案，可以看看我们关于 、 和 的指南。你还可以在 观看教程。

常见问题

在 GitHub 上使用 Google Maps 爬虫是免费的吗？

软件是免费的，但工作不是。你会投入 30–90 分钟搭建，之后还要持续花时间处理故障；如果数据量稍大，通常还要每月支付 10–100 美元以上的代理费用。如果你的时间有价值，“免费”这个说法并不准确。

使用 GitHub 上的 Google Maps 爬虫需要 Python 技能吗？

大多数热门仓库都需要基础的 Python 和命令行知识。优先 Docker 的仓库可以减轻负担，但不会完全消除——你还是得排查容器问题、配置搜索参数并处理代理设置。对非技术用户来说，像 这样的无代码工具提供了一个只需 2 次点击、无需编程的替代方案。

Google Maps 爬虫 GitHub 仓库多久会坏一次？

没有固定时间表，但当前 GitHub issue 历史显示，核心故障和字段回归会以 几周到几个月 的周期出现。Google 会 नियमित更新 Maps 界面，这可能在一夜之间搞坏选择器和解析逻辑。活跃仓库会很快修复，停更仓库则会一直坏下去。

我能用 GitHub 爬虫抓 Google 地图评论吗？

有些仓库支持完整评论提取（gaspa93/googlemaps-scraper 就是专门为此设计的），而另一些只能抓评分、评论数这类汇总数据。评论也是 Google 改变页面行为时最先失真的字段之一——所以即便仓库支持评论，在 UI 更新后也可能只返回不完整的数据。

如果我不想用 GitHub 爬虫，最好的替代方案是什么？

主要有两条路：一条是 Google Places API，可获得官方、结构化的访问方式，但有成本和字段限制；另一条是 像 这样的无代码工具，可以快速、由 AI 驱动地提取数据，而且无需编程。API 最适合需要合规确定性的开发者。Thunderbit 最适合需要快速把数据放进表格里的业务用户。

了解更多