将 Zapier 或 Make 自动化流程迁移到新的地理编码主机
基于地理编码步骤构建的无代码自动化流程，需要与自定义代码不同的迁移方法。下面介绍如何完成这种切换。
切换服务商后重新映射缓存结果
缓存是地理编码中一种合理且常见的优化手段，因为同样的地址经常被反复查询，没有多少理由每次都为全新查询付费或等待。但是，基于某一服务商的结果、经过数月或数年积累起来的缓存，会在迁移期间带来一个特定的问题：一旦背后的服务商发生变化，所有这些缓存数据该怎么办。
最稳妥的总体立场是：与特定服务商的坐标精度、地址格式约定或匹配置信度绑定的缓存结果，不应被默默视为等同于新服务商的结果，即使新服务商总体上是准确的。坐标精度尤其可能在服务商之间存在细微差异，一个把缓存的纬度和经度存储到小数点后若干位的应用，可能依赖于最初生成该数字的那家服务商所特有的精度特征。
以下是几种实用的做法，大致按彻底程度由低到高排列：
- 为缓存条目标记来源服务商。如果您的缓存尚未记录某个缓存结果是由哪个服务商生成的，请在迁移之前添加该字段，这样今后就能区分新旧条目，而不是把整个缓存当作一个不加区分的整体
- 为旧的缓存条目设置过期时间。不要一次性使整个缓存失效，那样可能导致发往新服务商的实时请求突然激增；而是让旧条目按照缓存已有的 TTL 自然过期，从而逐步过渡到来自新服务商的新结果
- 有选择地重新验证高价值的缓存条目。对于格外重要的地址，例如主要营业地点或常用的收货地址，值得主动针对新服务商重新查询，而不是等待缓存自然过期，因为这些条目中的细微差异最容易被注意到
由于正向地理编码的结果尤其可能在不同服务商之间存在确切格式和精度上的差异，在这种情况下，在完全切换之前，用您实际缓存地址中有代表性的样本来测试新服务商，比用合成的或精心挑选的测试地址更有价值。真实的缓存数据反映了您真实的使用模式，包括所有边缘情况。
My Geocode 的兼容主机通过与原服务商相同的字段结构返回数据，因此任何按字段名读取和存储缓存条目的代码，在迁移期间都无需重构，只是对于同一地址，不同服务商返回的值本身可能略有不同。每个响应中都有的配额响应头（其中包括 X-Quota-Used 和 X-Credits-Remaining，文档见 /docs/rate-limits/）也值得纳入缓存失效计划，因为突如其来的一波缓存未命中会直接转化为请求量的激增，而根据配额控制这波请求的节奏，是迁移规划中虽小却真正有用的一环。
把缓存迁移当作一个独立的小项目，而不是在服务商切换上线后自动发生的附带事项，可以避免一类细微的数据质量问题，这类问题事后诊断要比事先规划困难得多。