我在广泛阅读 Google 推荐的方法后提出这个问题，但我对所有这些方法都有疑问，让我解释一下情况。

我使用地理定位和地理编码 API 的组合来了解大致的状态位置，然后显示相关内容。地理定位 API 显然需要从浏览器中调用，以获取用户的适当地理定位。 Google 为此 API 提供了基于 HTTP Referrer 的限制。我知道有人可以轻松欺骗引荐来源网址并使用相同的 API 密钥进行调用。即使 Google 推荐这样做，我也没有看到巨大的优势。

另一方面，Google 不允许将 HTTP Referrer 用于地理编码 API，但它允许用于 MAPS JavaScript API。但同样，如果您不使用 Google 地图，那么使用该 API 将违反 Google 的条款。现在 google 建议将使用地理编码网络服务 API 的代码移动到后端，以便保护您的密钥。但由于最终我需要将结果传递给可公开访问的前端 Web 应用程序，并且我只能进行基于浏览器的 Ajax 调用以首先获取地理定位以提供给地理编码，因此我最终需要进行 Ajax 调用以获取我的地理编码信息。然后，有人可以轻松地锁定我的端点以搭载并尽可能多地调用地理编码 API。因此，对于这种情况，我想知道什么是理想且安全的处理方式。可能还有其他 API 可能是这种情况的理想情况。

在我的例子中，我没有做任何地图，所以它完全是在服务器端获取纬度、经度和两点之间的行驶距离。今天来自 Google 的支持可能会有所帮助，如果您正在使用地图，那么这些链接可能会提供进一步的见解。

Regarding API restrictions, please note that HTTP referrers will not
work on Geocoding API since HTTP referrers can only be used for client
side services. In other words, Geocoding is a web service API and
should only be used on server-side implementation. IP address
restrictions should be used for web service APIs. However, if you are
using the Geocoding API in a website, IP address restriction would not
work. Please check the suitable restrictions for each API in the
following link:

https://developers.google.com/maps/api-key-best-practices#api_key_table

To make this work, you should create a separate key and use the new
one in your Geocoding API request URL. You may add a restriction to
this key by using an"API restriction", and restrict it to Geocoding
API only. If you don't want to create another key, you may keep using
your current one but make sure to change your implementation and use
the client side Geocoding service from the Maps JavaScript API. In
that case, please refer to this documentation:

https://developers.google.com/maps/documentation/javascript/geocoding

Another suggestion would be to get a static IP address from your ISP,
especially if you are planning to use it on a public website. For
development purposes, a sound solution would be to get three separate
keys: one for the staging and tests, another for server-side requests
and a third one for client-side requests. That way, you are making
sure your API key is protected.