很多大模型平台(不管是对话模型、文本生成、图像、语音)都会用 API Key 来识别“谁在调用接口、调用了多少、该记到谁的账上”。你可以把它理解成:云服务的“门禁卡 + 计费账号标识”。
1)API Key 的本质作用
身份识别:平台用它知道请求来自哪个账户/项目
权限控制:哪些接口能用、是否允许某些模型、是否可开流式输出等
计费与风控:每次调用都会累计用量,异常调用可能触发限流/封禁
✅ 关键结论:API Key = 资产,丢了就等于“别人刷你的额度/账单”。
2)API Key 通常怎么拿到?
不同平台入口不一样,但流程基本一致:
登录控制台
找到 API / 开发者 / 密钥管理(Key Management)
新建 Key(有的需要先建 Project/应用)
复制一次并保存(很多平台只显示一次)
建议你同时做两件事:
给 Key 命名:比如 prod-server、test-local
按环境分 Key:测试 / 生产分开,方便隔离风险
3)怎么“正确使用”API Key
原则A:只放后端,不放前端
❌ 不要把 Key 写进网页/小程序/APP 里(很容易被抓包拿走)
✅ 正确做法:前端请求你的后端,你后端带 Key 去调用大模型平台
原则B:用环境变量存 Key
❌ 不要写死在代码里,更不要提交到 Git
✅ 用环境变量(或密钥管理服务):
Windows(PowerShell):
setx LLM_API_KEY “你的密钥”
macOS/Linux(bash/zsh):
export LLM_API_KEY=”你的密钥”
4)调用大模型 API 的基本形态(通用)
大多数平台都遵循这类结构:
请求头带 Key:Authorization: Bearer
请求体包含:
model:模型名
messages 或 prompt:输入内容
temperature:发散程度(越高越随机)
max_tokens:输出长度上限
stream:是否流式返回
5)最小可用示例(curl + Python)
注意:下面是通用写法模板,不同平台的 URL、字段名会略有差异,你把它当“结构参考”。
示例1:curl(最直观)
curl https://api.example.com/v1/chat/completions \
-H “Authorization: Bearer $LLM_API_KEY” \
-H “Content-Type: application/json” \
-d ‘{
“model”: “your-model-name”,
“messages”: [
{“role”: “user”, “content”: “用中文解释什么是 API Key,并给出注意事项。”}
],
“temperature”: 0.2,
“max_tokens”: 500
}’
示例2:Python(后端最常用)
import os, requests
API_KEY = os.getenv(“LLM_API_KEY”)
url = “https://api.example.com/v1/chat/completions”
payload = {
“model”: “your-model-name”,
“messages”: [{“role”: “user”, “content”: “写一段产品介绍,语气专业。”}],
“temperature”: 0.3,
“max_tokens”: 400
}
resp = requests.post(
url,
headers={
“Authorization”: f”Bearer {API_KEY}”,
“Content-Type”: “application/json”
},
json=payload,
timeout=60
)
resp.raise_for_status()
data = resp.json()
print(data)
6)安全与风控:真正会踩坑的点 ⚠️(建议你当 SOP)
✅ Key 分环境:prod/test 分开
✅ 最小权限:能限制就限制(有的平台支持 Key 权限、白名单、配额)
✅ 限制来源:允许的话做 IP 白名单/域名白名单
✅ 设置预算/告警:防止被刷爆账单
✅ 定期轮换:每月/每季度换一次(或出事故立刻换)
✅ 日志脱敏:不要把 Key 打进日志、错误堆栈、截图
常见事故
把 Key 写进前端 → 被抓包 → 被刷
提交到 GitHub → 被爬虫扫到 → 秒刷
多人共用一把 Key → 无法追责、容易触发风控
7)排错速查
401/403:Key 无效、权限不足、项目未开通
429:请求太频繁(限流),需要降频/排队/加重试
400:参数不对(model 名、字段、token 限制)
5xx:平台临时故障,做重试与降级
输出为空/截断:max_tokens 太小、上下文太长、被安全策略拦截
8)如果你要做产品/对外服务,建议这样接:
前端(无 Key) → 你的后端(带 Key) → 大模型平台
后端额外做三件事就稳了:
鉴权:你的用户要登录/有 token
计量:记录每个用户用量,防滥用
缓存/重试/队列:降低成本与 429