API 密钥本质是访问凭证，相当于接口的 “门禁卡”，服务端通过密钥识别调用方，做身份、权限、计费、风控管控。
1. 身份识别：知道是谁在调用
HTTP 接口本身默认是无状态的，普通请求只有 URL、参数，没有身份信息。
没有密钥：任何人拿到接口地址就能调用，服务端分不清请求来自哪个用户 / 哪个项目。
有密钥：每个开发者 / 项目分配唯一密钥，服务端一眼识别出「这个请求属于 A 客户」。
对比：用户名密码适合人登录；API Key 适合程序、脚本、服务之间调用，不需要人参与登录。
2. 权限控制：能干什么，不能干什么
服务端根据密钥绑定权限：
密钥 A：只能调用查询接口，不能修改、删除数据
密钥 B：可以读写全部接口
密钥 C：只能访问部分数据资源
即使接口地址泄露，别人没有合法密钥，就无法使用接口能力。
3. 计费与用量统计
大部分开放 API 是按量收费：调用次数、QPS、流量。
通过密钥统计每个调用方的调用量，做账单、配额限制。
例：大模型 API、短信、地图、支付接口，都是按 key 统计次数。
可以给每个 key 设置最大调用配额，防止滥用。
4. 限流、风控、防滥用
按密钥做 QPS 限流：每个账号每秒最多多少次请求，防止单用户打垮服务器。
异常监控：某个密钥短时间大量调用，可以直接封禁该 key，保护服务。
如果接口完全公开无凭证，很容易被爬虫、恶意请求打崩。
5. 安全隔离，可撤销，不用改密码
密钥的一大优势：可以单独作废，不影响账号本身。
如果密钥泄露，直接在后台删除 / 重置 API Key 即可，不用修改账号密码。
可以多环境多密钥：开发环境一套 key、生产环境一套 key，泄露哪一个就废掉哪一个。
常见密钥传递方式
请求头
Authorization: Bearer xxxkey（最常用）请求头
X‑API‑Key: xxxURL 参数
?api_key=xxx（不推荐，会留在访问日志，容易泄露）
密钥不是万能的，常见误区
API Key 只是凭证，不等于加密：如果 HTTP 明文传输，密钥会被抓包窃取，必须搭配 HTTPS。
不要把密钥写死在前端 JS、小程序：前端会泄露密钥，密钥应该保存在后端服务，由后端转发调用。
API Key ≠ 签名：简单密钥只做身份识别；签名（如 HMAC）还会对参数做防篡改，安全性更高。
简单总结
API 密钥解决核心问题：服务端怎么确认 “这个请求是谁发的，允许做什么，调用了多少次”。
没有密钥，接口任何人都可以访问，无法鉴权、计费、限流、追责。