google_places函数next_page_token循环调用失效问题排查

这种手动分步调用正常、一用循环批量获取就报错的情况真的太磨人了！我之前处理Google Places API分页的时候也踩过几乎一模一样的坑，大概率是下面这两个核心原因导致的：

1. Next Page Token的延迟生效机制 #

Google Places API返回的next_page_token并不是拿到就能立刻用的——API后台需要1-2秒的时间同步这个token的有效性。如果你的循环在刚拿到token就立刻发起下一次请求，就会触发INVALID_REQUEST错误。而手动调用时，你中间有自然的操作间隔，token早就同步完成了，所以能正常返回结果。

修复方案：在循环里添加一个短暂的延迟，给API一点时间同步token。比如用Sys.sleep(2)让程序暂停2秒再请求下一页，示例代码如下：

library(googleway)

# 配置基础参数
api_key <- "你的Google API密钥"
# 圣保罗的大致经纬度
sao_paulo_loc <- c(-23.5505, -46.6333)
search_radius <- 50000  # 可根据需求调整搜索范围

# 首次请求获取第一页结果
first_page <- google_places(key = api_key,
                            location = sao_paulo_loc,
                            radius = search_radius,
                            keyword = "Starbucks",
                            place_type = "cafe")

all_starbucks <- first_page$results

# 循环获取所有分页
while (!is.null(first_page$next_page_token)) {
  # 关键：添加延迟，等待token生效
  Sys.sleep(2)
  
  # 用最新的page token请求下一页
  next_page <- google_places(key = api_key,
                             page_token = first_page$next_page_token)
  
  # 把新结果合并进去
  if (!is.null(next_page$results)) {
    all_starbucks <- rbind(all_starbucks, next_page$results)
  }
  
  # 更新token，准备下一轮循环
  first_page <- next_page
}

2. 请求速率超过API限制 #

Google Places API对请求频率有严格限制（免费版通常是每秒最多1-2次请求）。如果你的循环没有做速率控制，短时间内连续发起请求，会被API判定为违规操作，返回INVALID_REQUEST。手动调用时因为间隔足够长，不会触发这个限制。

修复方案：除了上面的Sys.sleep()，你可以根据自己的API配额调整延迟时间，确保请求频率不超过限制。哪怕是付费版，也建议保留适当延迟，避免意外触发API的风控机制。

额外排查小技巧 #

• 检查API配额：有时候配额用完也会返回类似错误，你可以去Google Cloud控制台确认一下自己的Places API配额剩余情况。
• 确认token传递正确性：循环里要确保每次都用最新返回的next_page_token，别不小心复用了之前的旧token。

总体来说，最可能的原因就是token延迟生效的问题，加个2秒的延迟应该就能解决你的问题。你可以试试在循环里加上Sys.sleep(2)再跑一遍，应该就能正常获取所有分页结果了。

内容的提问来源于stack exchange，提问作者Felipe Alvarenga