API key 与认证 header
大多数有用的 并不对全世界开放。公司需要知道是谁在提问，这样他们才能统计用量并向你收费。他们会给你一个 API key——一长串能标识你账户的密钥字符串。你把它附在每个请求上，通常放在一个叫 Authorization 的 header 里，就像上面那行 Bearer sk_live_...。
把 API key 完全当成密码来对待，因为它本来就是密码。任何拿到它的人都能以你的身份发请求——并刷爆你的账单或读走你的数据。这直接关联到安全那一章，而其中最重要的有一条规则：
- **绝不要把 API key 放进会发到浏览器里的代码。**你前端里的任何东西都是公开的——用户可以打开开发者工具读到它。AI 被要求"从页面里调用 API"时，会乐呵呵地把你的密钥直接贴在那儿。拦住它。密钥属于服务器。
- **绝不要把 key 提交进 。**就算你之后删掉它，它也会永远活在历史记录里，而机器人会在几分钟内扫描公开仓库里的 key。
- 把 key 存在环境变量里，而不是代码本身里——这和安全那一章讲的是同一个模式。
key 必须从一个安全的地方出发，绝不能从浏览器出发。设想一下这两条路——一条安全，一条泄露：
安全 ✓ 泄露 ✗
┌──────────┐ key ┌──────────┐ ┌──────────┐ key ┌──────────┐
│ 服务器 │ ───▶ │ API │ │ 浏览器 │ ──▶ │ API │
│ (你的 │保密 │ │ │ (任何人 │ │ │
│ 后端) │ │ │ │ 都能 │ │ │
└──────────┘ └──────────┘ │ 看到) │ └──────────┘
key 在环境变量里 └──────────┘
前端里的 key = 公开
如果你哪天看到一个真实的 key 出现在一段 diff 里、一个前端文件里、或一条聊天消息里，就把它当成已经泄露了：立刻轮换它（生成一个新的，停用旧的）。