React Native应用中客户端可直接使用Google Maps API密钥还是需先请求自有服务端？

客户端直接调用方案 #

优势 #

• 架构复杂度低，无需额外开发服务端转发接口，开发周期短
• 网络链路更短，少了一层服务端转发开销，请求响应速度更快，用户体验更好
• 无需承担服务端额外的带宽、算力成本，运维成本更低

劣势 #

• API密钥直接打包在APP安装包中，即使做代码混淆也存在被反编译提取的风险，密钥泄露后可能被恶意滥用，产生高额账单，甚至被Google封禁相关权限
• 仅能依赖Google Cloud后台的应用限制（包名、SHA-1签名绑定）降低盗用风险，无法完全避免被破解绕开校验的情况
• 无法统一做请求审计、限流，也不能缓存高频请求结果降低API调用成本
• 如果未在Google Cloud后台给密钥配置任何调用限制，泄露后产生的所有损失都需要你自行承担

自有服务端转发调用方案 #

优势 #

• API密钥仅保存在服务端，完全不会泄露到客户端，从根源上避免密钥被盗用的风险
• 可以灵活实现业务侧的权限管控：比如仅允许登录用户调用、单用户限流、异常请求拦截等，避免不必要的API成本消耗
• 可对高频重复请求（比如热门区域POI搜索、固定路线规划）做结果缓存，大幅降低Google API的调用量，长期来看能节省不少成本
• 可统一做请求日志审计、异常监控，故障排查效率更高
• 后续如果需要替换地图服务商、或者在返回结果中叠加自有业务数据，仅需修改服务端逻辑即可，无需发布客户端版本

劣势 #

• 开发成本更高，需要额外开发服务端转发接口、做参数校验、异常处理
• 多了一层服务端转发，请求延迟会有小幅提升，对实时性要求极高的场景会有轻微影响
• 服务端需要承担额外的请求压力、带宽消耗，运维成本更高

最终选型参考 #

• 如果你的应用是内部使用的小流量工具（用户量仅几十到上百人）、API调用量极低，或对成本完全不敏感，可以选择客户端直连方案，只要在Google Cloud控制台做好密钥的应用绑定、设置合理的日调用量上限，基本可以覆盖风险
• 如果你的应用是面向公网的C端产品、用户量较大，或者有明确的成本控制、安全合规要求，优先选择服务端转发方案，长期来看风险可控性和可扩展性都更好

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