将 Zapier 或 Make 自动化流程迁移到新的地理编码主机
基于地理编码步骤构建的无代码自动化流程，需要与自定义代码不同的迁移方法。下面介绍如何完成这种切换。
迁移后安全停用旧的 API 密钥
停用旧服务商的 API 密钥，感觉像是迁移结束时一个微不足道、近乎行政性的步骤，但时机无论过早还是过晚，都会带来真实的代价。停用得太早，在所有依赖系统真正迁移之前就停用，某个仍在调用旧密钥的东西就会意外出错。停用得太晚，或者从不停用，一个不再使用但仍然有效的凭据就会一直存在，成为没有人在主动留意的安全隐患。
最稳妥的流程是把密钥停用当作一个有明确步骤顺序的独立小项目，而不是附加在主要迁移工作末尾的附带事项：
- 首先确认旧密钥上的流量为零，而不仅仅是相信迁移已经完成。大多数服务商都会提供某个密钥的用量信息；请直接查看，而不是以为迁移清单被标记为完成，就意味着旧密钥在实际中已经没有流量。
- 在您认为迁移已经完成之后，让旧密钥在一个明确的观察窗口内保持有效但不使用，而不是在新服务商上线的那一刻就将其停用。这个窗口通常为几周，具体取决于您的流量模式和发布周期，它能发现任何被遗忘的调用点、延迟的移动应用更新，或者仍在引用旧凭据的不常运行的批处理任务。
- 如果您的服务商支持区分停用和删除，请先停用而不是删除旧密钥。一个已停用但仍作为记录存在的密钥，在出现意外情况时比完全删除的密钥更容易临时重新启用，从而在观察窗口期间为您提供安全余量，而不会无限期地延长它。
- 在确定的具体日期删除或彻底吊销旧密钥，并记录这一操作。一个无限期停用的密钥仍然是一个安全暴露面，一旦账户本身遭到入侵，就可能有人将其重新启用；一个真正退役的凭据最终应当被永久移除，而不是一直处于悬而未决的状态。
- 审查旧密钥曾经存放的位置，包括配置管理系统、密钥管理器、环境变量文件，以及任何可能引用它的文档或入职资料，因为一个已经退役却仍在某处被写作“API 密钥”的密钥，会在密钥本身早已失效很久之后，给下一个阅读该文档的人造成困惑。
对于迁移到 My Geocode 的情况，新密钥从第一天起就可以借助每个响应中都有的配额响应头来界定范围和进行监控，包括 X-Quota-Used、X-Key-IPs-Used 以及 /docs/rate-limits/ 中记录的其他响应头，因此在开始为停用旧密钥计时之前，可以很方便地确认新密钥确实承载了您预期的流量。以这种审慎程度对待凭据停用，只需增加少量额外流程，就能显著降低运营风险和残留的安全暴露。