Google My Business API营业时间数据延迟与不一致问题咨询

其他开发者普遍遇到的同类问题特征 #

• 搜索前台与API后端的同步链路是完全独立的两套队列，不存在实时同源的机制：大量实测数据显示，Google搜索端的商家名片更新优先级最高，会优先把前台可展示的字段（含营业时间）同步到公开展示层，但API侧的结构化数据同步优先级更低，实测出现过的最长同步时差达到72小时，远超大家默认的24小时同步预期。
• 通过Google Maps端直接编辑更新的营业时间，同步优先级会进一步降低：如果商家没有通过GMB管理后台修改营业时间，而是直接在地图上编辑提交的更新，这类数据的API同步队列优先级会低于GMB后台操作的更新，很容易出现前台展示已经生效、API侧仍然拉取旧值的错位情况。

实际踩坑总结的排查与解决步骤 #

• 先排查本地调用链路的缓存逻辑：检查自身服务端是否对GMB API的返回结果设置了本地缓存，如果缓存TTL设置超过12小时，大概率是本地缓存没有及时刷新导致拿到旧数据。可以临时绕过本地缓存，直接发起locations.get调用，检查返回结果中regularHours字段的值是否为最新版本。
• 确认调用的API版本与权限配置：如果使用的是v3及更早的GMB API版本，本身就存在营业时间字段同步延迟的已知bug，需要切换到当前稳定版本的GMB API，调用时确认已申请https://www.googleapis.com/auth/business.manage全量权限，避免因为权限受限拉取到过期的字段快照。
• 触发全量同步队列：如果确认本地没有缓存、API版本和权限都没有问题，等待48小时后依然没有同步到最新数据，可以进入GMB商家后台，对任意非核心字段（比如商家简介）做一次无实际内容改动的微调保存，这个操作会触发对应商家资料的全量同步流程，大部分场景下2小时内API就能拉到最新的营业时间数据。
• 排除沙箱环境的同步逻辑差异：如果是在沙箱测试环境发起的API调用，沙箱环境的结构化数据同步本身就存在固定24-48小时的延迟，和线上生产环境的同步链路完全隔离，不能用沙箱环境的返回结果判断生产侧的同步状态。

有过同类踩坑经验的开发者统计，这类“前台已更新、API返回旧值”的场景中，90%以上的问题出在本地缓存或者旧版API的兼容bug上，只有不到10%的情况是真的触发了Google侧跨队列的同步时差。

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