Google Places API中place_id保存与刷新最佳实践及字段问询

结合你使用AutocompleteService.getPlacePredictions的场景，再对照Google Places文档里的最佳实践要求，除了已经保存的place_id，你还得存好以下这些关键字段：

Google Places文档指出：“最佳实践是定期刷新存储的place_id，例如每100天刷新一次。一种策略是存储返回每个place_id的原始请求。若place_id失效，可重新发起该请求以获取最新结果，这些结果可能包含或不包含原地点。”

• 用户的原始输入查询文本：就是用户在Autocomplete输入框里输入的关键词（比如「上海陆家嘴西餐厅」）。毕竟getPlacePredictions是基于这个输入返回候选地点的，原place_id失效时，只有用这个原始查询再调用接口，才能拿到和当初场景一致的候选结果。
• 完整的Autocomplete请求参数：这些参数直接决定了当初返回的候选范围，缺一不可：
  • types：你当初指定的地点类型（比如establishment、geocode）
  • location和radius：如果当时设置了位置偏置和搜索半径，这俩参数会过滤出特定区域内的地点，必须保存
  • components：要是用了区域限制（比如只搜国内），这个参数也得留着
  • sessionToken：虽然它主要用于单次会话的请求去重，但如果是同一会话生成的place_id，保存下来能让重查的结果更贴合当初的上下文
• 选中预测结果的description字段：这个是Autocomplete返回的完整地点描述（比如「Wolfgang's Steakhouse, 上海市浦东新区」）。一来可以用来对比重查后的结果是否和原地点匹配，二来要是原place_id失效且重查没找到完全一致的，这个描述能帮用户快速确认或重新选择。
• place_id的存储时间戳：这是判断刷新时机的核心依据。你可以用它来跟踪每个place_id的存储时长，每到100天就触发一次刷新流程。

刷新流程大概是这么走的：

1. 检查存储的时间戳，判断是否到了100天的刷新周期
2. 用保存的原始查询+所有请求参数重新调用AutocompleteService.getPlacePredictions
3. 把返回结果的description和你保存的原描述对比，找到最匹配的候选地点
4. 更新存储的place_id为新ID，同时刷新时间戳

要是重查后找不到匹配的地点，大概率是原地点被移除或更名了，这时候可能得提醒用户重新确认地点信息。

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