低成本地图接口怎么选
「安全」这个词，在接口选型时被说得太多、落得太少。这篇不谈结论，谈实现：一个地图接口的安全，从密钥到故障隔离，中间要做哪六个决定。key 在系统里干三件事：说明你是谁、决定你能用什么、记录你用了多少。三件事都绑在同一个字符串上，所以这个字符串怎么隔离，决定了很多后续能力。二是独立额度，用量上限跟调用方一一对应，不跟别人分。三是按主体的限流和告警，阈值按你这一家算，触发了通知你这一家。四是按主体隔离的记录，出了问题能按你这一家检索，不跟别人的混在一起。这四层不只是安全问题，还是运维问题。一旦共用，故障范围会放大到所有共用方，而且出事时分不清是自己异常还是被别人牵连，排查时间完全看对方什么时候有空。另外三个常被省掉的点：密钥分级（测试、预发、生产分开，别让测试 key 带上生产流量）、轮换机制（要支持双 key 并行过渡，否则轮换等于停服）、吊销时效（泄露后多久失效，应该是分钟级）。基础是全程加密，包括 SDK 内部发起的请求，不存在退回明文的路径。真正要设计的是签名。key 放在网址参数里，会留在网关日志、代理日志、访问日志里，等于把凭证写在门牌上。合适做法是：key 走请求头，请求体做签名，签名带上时间戳和随机数，服务端校验时间窗口——这样同时解决凭证暴露和重放攻击。第二个高频缺口是回调。很多系统把出去的请求加密做得很严，异步通知、状态回传却是明文还不签名，攻击面反而在这一侧。这三个概念经常被混着说，其实作用不同：额度是商务约定，限流是保护机制，熔断是故障应对。工程上要有三样：按主体的令牌桶（保证限流按调用方独立算）、超出额度后的明确行为（拒绝、降级还是排队，要事先定义，不能临时决定）、下游异常时的熔断（避免地图服务抖动把主链路拖垮）。还有一条常被忽略：降级路径。地图通常是强依赖，但没必要是硬依赖——定位失败可以回退到上次成功位置，路径规划失败可以回退到直线估算并标注精度，检索失败可以回退到缓存。降级不是降低标准，是把不可用变成可用但降级。采不采：默认不落库，只做计算管道。业务需要的轨迹由业务自己存，服务商不留副本，这是最干净的设计。留多久：必须留存的话，按数据类型设 TTL（原始轨迹、聚合结果、日志各不相同），到期自动清理，不靠人工。怎么删：合同终止后的删除时限和删除证明。这一项不写进协议，执行时基本等于没有。两个实现细节：留存数据加密存储、敏感字段脱敏（手机号、精确地址）、访问要有审计记录。出问题时第一个问题永远是「是不是我们自己的问题」。要能回答，靠三样：请求标识（每次调用返回 request id，可以反查）、按主体的指标（成功率、P95 延迟、限流触发率分开统计）、调用审计（谁在什么时候调了什么，可追溯）。缺任何一样，故障都会变成扯皮：你说有问题，他说没问题，各拉一份日志对不上。架构层的四个判断：多节点部署、就近接入、单节点故障是否影响整体、切换是否自动。这一层和第一层是一对：密钥隔离解决「别人的事不牵连你」，故障隔离解决「自己的事多久恢复」。合起来才是完整的安全边界。按依赖排：密钥设计 → 传输与签名 → 流量治理 → 数据生命周期 → 可观测性 → 故障隔离。前两项不过，后面做得再好也没意义。交叉压测验证密钥隔离（A 打到限流，看 B 会不会慢）；抓包验证传输（有没有明文路径、key 在不在网址里）；我们的实现，按上面六条列：一客一 key，密钥和额度独立，限流告警和记录按 key 隔离，异常能定位到具体请求；全程加密，key 走请求头不进网址，回调同样做校验；业务数据不留存、不用于其他用途，可写进协议；可用率承诺入合同，多节点容灾。费用在小几千一年这个量级，按用量评估。后台回复「接口文档」，可以先看文档，也可以约一次免费的联调评估。
