Google Maps 抓取：Places API 还是页面列表？

Google Maps 抓取首先需要选择来源，而不是选择器。公开文档中的 Places API、页面结果列表和选定地点的面板，回答的是不同的地点问题。API 返回的字段与界面上可见的文字不是同一种观察，两种来源也都不授予无限制复用的权利。BotBrowser 提供用于获准页面观察的浏览器环境配置；它不提供地点数据，不免除 API 计费，也不改变 Google 的内容政策。先为所需字段选择获准来源，再保留该来源实际能够证明的信息。

摘要

• 当公开文档支持的字段和适用条款满足需求时，优先使用 Places API。页面界面不是 API 或服务限制的例外。
• Places API (New) 的 Place Details 需要字段掩码。请求字段影响响应和计费类别；没有请求的字段不是已测得的空值。
• API 资源名称与人类可读的地点名称是不同字段。仅凭可见标签不能建立可靠的身份键。
• Place ID 标识 Google 数据库中的地点，但文档明确说明标识可能变化，同一地点也可能有多个 ID。
• 仅在获准的保留范围内保存字段来源信息。Place ID 的存储例外不适用于全部地点内容。

目录

• 选择三种地点数据来源
• 请求之前定义所需字段
• 区分地点身份与显示文字
• 按实际用途应用存储和署名规则
• 将页面观察限定为界面问题
• 修改采集器之前区分缺失数据
• 实践结论

选择三种地点数据来源

Places API 概览描述了查找地点和获取详情的受支持服务。新集成应先明确文档中的 API 版本和操作，再选择字段。Place Details 响应涉及选定的地点引用；搜索响应则涉及该操作的搜索问题。不要把不同 API 版本的示例拼成一份假定的响应合同。受支持操作、请求字段与实际返回的表示形式必须放在一起解释。

来源	能回答的问题	必须保留的边界
文档定义的 Places API	这次获准操作返回了哪些受支持字段？	请求字段、操作和适用条款共同约束用途
获准的页面结果列表	此次观察的列表状态中有哪些条目或标签可见？	可见条目不是完整的地理总体
获准的选定地点面板	该选定界面状态为目标地点显示了什么？	面板内容不是通用 API 模式，也不是访问限制的例外

表中的页面来源描述的是有条件的观察，不代表当前 Google Maps 界面总会提供特定字段。这里没有实测 Maps 列表或面板采集。获准的界面测试可能需要检查标签、选定地点状态或本地化显示，这与通过 API 获取受支持商家字段不同。应明确界面问题，而不是把每段可见文字都视为替代数据服务。

共享观察流水线区分采集与解释。应用这种分工时，不能假定每家提供方都允许相同的保留方式。内部表示应区分 API 提供的数据、获准的界面观察和下游推断。字段传给另一个组件时，也不能抹去原始来源。把字段放进通用表，并不会扩大其含义或获准用途。

来源获准先于浏览器选择。如果文档定义的操作无法在适用协议下提供所需字段，结果可能是需求不受支持，而不是改查其他界面的理由。应重新核对受支持集成与获准用途。页面可以打开或浏览器完成配置，都不改变内容条款。不能把来源比较用作避开付费字段、配额或禁止采集用途的路径。

请求之前定义所需字段

Place Details 参考明确说明，Places API (New) 的这一方法没有默认返回字段列表。省略字段掩码会返回错误。因此，字段掩码属于请求合同，不是采集之后才补写的描述。解释响应成员缺失时，应保留应用实际请求了哪些字段。未请求的字段没有被观察为空、false 或零。

字段组	文档中的 API 字段示例	解释边界
地点引用	id 与 name	资源名称不是人类可读的商家标签
显示与地址	displayName 与 formattedAddress	显示文字不是不可变的身份键
营业状态	businessStatus	缺失值不构成关闭判定
评价摘要	rating 与 userRatingCount	摘要不是完整评论集合
营业时间	regularOpeningHours	字段缺失不表示持续营业

官方字段表将字段与操作和计费类别关联起来。不能假定某方法提供的字段，在另一方法中具有相同类别或行为。应定义能够回答获准问题的最小受支持字段集合，并核对该方法的当前文档。上表不承诺固定价格或无限制可用性；它说明词汇与解释边界，而非计费估算。

name 与 displayName 的区别很具体。Place Details 文档将 name 定义为 places/PLACE_ID 形式的资源名称，地点的文字名称则使用 displayName，且列于不同计费类别。把资源值改名为商家名称列，会改变其含义。转而解析可见标签，也不构成规避该字段条款或费用的许可。

字段是否存在与字段含义需要分别检查。评分摘要不证明所有评论均已返回。格式化地址是提供方给出的表示，不证明附近结果的每个位置都有该商家营业。营业时间应保留对应字段的含义，而不能扩展为服务随时可用的承诺。需求若需要更强证据，就应返回限制，而不是从熟悉的标签制造确定性。

区分地点身份与显示文字

Place ID 指南说明，Place ID 标识 Google Places 数据库和 Google Maps 中的地点，同时也说明同一地点可能有多个不同 ID，ID 还可能随时间变化。比较观察时必须考虑这些限制。标识比相同商家名称更具体，但不保证存储的某个值永远不变。

应将实际提供方引用与来源、观察上下文放在一起。不能仅因标签相同就合并两个商家，也不能仅因提供方引用变化就宣布出现了新商家。标识变化提出的是需要核查证据的对齐问题。提供方文档、返回字段和获准用途决定可以建立什么结论。相似地址或标签可辅助调查，但不能独立证明同一个法律实体或地点。

指南建议刷新超过 12 个月的标识。这是标识维护建议，不是允许全部关联字段保存相同时长。应区分标识刷新、内容保留和实时商家观察的时间。重新验证引用，并不能证明旧评分、地址或营业时间仍然有效。每个接受字段都需要符合应用需求的来源与新鲜度含义。

招聘信息身份比较区分来源记录与现实实体。地点数据也需要这一区分，但应使用 Google 的标识指南，而不是套用招聘网站假设。同一品牌可能有多个地点，相似可见标签也可能属于无关地点。获准证据无法解决匹配时，应保留不确定性。不能静默合并记录，把标识变化表现成商家开业或关闭。

按实际用途应用存储和署名规则

Places API 政策限制超出允许例外的预取、缓存和存储，并单独将 Place ID 排除在缓存限制之外。这是特定例外，不会让地点响应的其他内容成为可无限保留的内容库。保留字段值或响应副本前，应确定适用协议及该用途对应的例外。来源追溯要求不能凌驾于提供方的内容存储限制。

若不能保留原始内容，应在允许范围内设计运行记录，而不是照样复制响应。请求结果、所选操作或获准标识可能足以回答诊断问题，无需保存每个内容字段。某一记录是否允许保存，仍取决于条款和实际包含的数据。工程要求是明确作出这个决定，而不是把内容缓存改名为日志就认为限制消失。

同一份政策参考还涵盖地图显示、Google 署名与第三方署名，分别说明在地图上和不使用地图时显示 Places 结果的要求。照片与评论另有作者署名要求。不能假定把字段移到另一个界面就免除义务。技术请求成功，与显示方式获准且署名正确，是不同的验收问题。

适用条款可能因计费地区不同而变化，包括文档说明的欧洲经济区区别。应核对实际账户和用途适用的条款，而不是把通用示例视为普遍法律许可。Maps 页面界面也不会因与 API 比较而获得无限复用权。若适用条款不支持某用途，应停止或选择获准的其他来源。浏览器配置不能改变这一决定。

将页面观察限定为界面问题

获准的页面测试可以回答结构化字段不表达的显示问题：哪个标签可见、选中了哪个地点，或者预期面板状态是否加载完成。观察受实际状态和该测试许可限制，不证明区域内全部地点、完整评论集或稳定排序。这些需要不同证据与适用的受支持来源，而不是更长的浏览器会话。

BotBrowser GeoIP 文档说明 profile 前提及代理路由下的地理查询。这些属于浏览器环境输入，不定义 Maps 搜索位置，不证明商家营业地点，也不保证服务的排序方式。需要特定观察位置的测试，应另行核实相关界面或文档定义的操作。预期浏览器环境与服务实际响应是不同证据。

入门文档涵盖 profile 优先启动、自动化集成与验证，浏览器设置本身应参考该文档。浏览器成功启动，不证明目标地点面板已经加载，也不证明可将其内容用于另一个目的。获准测试应先确认选定地点和所需可见状态，再解释标签；无法建立匹配时，返回未解决的观察。

浏览器故障应留在浏览器层。超时、未完整加载的面板或意外页面，不是商家字段的新值。应在保留规则允许范围内，将失败结果与上次接受的观察分开。拒绝之后更换浏览器身份、账户或路由，不是建立缺失字段的有效方式。访问或用途不被允许时，观察应停止，而不是扩大范围。

修改采集器之前区分缺失数据

数据缺失有多种可能：没有请求字段、所选操作不支持字段、响应省略字段，或根本没有观察到目标界面状态。这些解释对应不同处理。先检查记录的操作和字段请求，再在允许的诊断范围内检查实际结果。userRatingCount 缺失不是测得的零，businessStatus 缺失也不是关闭声明。

MDN Fetch 文档说明，即使 HTTP 状态是错误，fetch promise 也可能在响应头到达后兑现。因此，请求完成弱于应用响应成功。应区分传输、HTTP 状态、受支持的表示形式与所需字段验收。解析器返回对象，本身不能证明目标地点或字段已经建立。应按操作文档解释错误，而不是把所有失败变成空地点记录。

获准界面测试应区分标签不存在与面板尚未验证。如果未选定目标地点或相关状态不完整，就没有建立商家字段观察。如果在已验证状态中标签确实不可见，应保留这一较窄结论，而非推断全局 API 限制。这里没有实测当前 Maps 面板实现。这些是获准测试的验收规则，不是关于受保护服务行为的主张。

Places 字段参考可以解决词汇或操作不匹配，但不能修复不受支持的用途。后续行动应与证据对应：修正获准字段请求、处理文档定义的响应、检查获准界面状态，或返回不受支持的需求。不能仅为让缺失值看似可获取就切换来源。来源选择、字段解释与许可，在最终数据集或显示中都应保持一致。

常见问题

Places API 与 Google Maps 抓取相同吗？

不同。API 是有文档的服务，具有受支持操作、字段选择和适用计费及内容规则。页面列表或面板属于带上下文和许可条件的界面观察。两种来源都不会让另一种成为无限制替代方案。

字段缺失是否表示商家没有这个值？

不一定。字段可能未请求、不受支持、被响应省略，或者目标状态尚未观察到。应保留不确定性，不能把缺失信息变成零、关闭或持续营业。

可以将 Place ID 当作永久商家键吗？

官方指南说明 ID 会变化，同一地点可能有多个 ID。应按维护指南使用来源引用，并保留未解决的身份变化。相同的可见商家名称不能确定匹配。

BotBrowser 会改变 Maps 数据访问或 API 政策吗？

不会。BotBrowser 为获准观察提供浏览器环境输入，不提供地点内容，不免除计费，不改变存储或署名条款，也不保证排序和完整性。

来源

• Places API 概览
• Place Details (New)
• Place Data Fields (New)
• Place ID
• Places API 政策
• MDN Fetch API
• BotBrowser GeoIP 数据库
• BotBrowser 入门

实践结论

根据实际字段或界面问题选择获准的地点数据来源。区分操作、字段选择、提供方身份与显示文字，先解释缺失值再修改采集器。对保留或显示的内容应用相关存储和署名规则。浏览器配置支持获准界面观察，而来源及其文档条款决定该观察能建立什么结论，以及可以如何使用。