API密钥和Token的区别

很多人第一次接大模型接口，拿到一串字符就当成「钥匙」，结果分不清哪个该写进配置文件、哪个只是这次请求的临时凭证；也有人把额度型 Token 当成身份凭证贴到前端，出事才发现问题。这篇把两样东西从定义到用法摆在一起对照，给出分配、存放、轮换和出事后的排查顺序。

第一次接大模型接口的人，拿到一串字符往往当成万能钥匙，分不清哪个该写进服务端配置、哪个只是这次请求的临时凭证。更麻烦的是，同一个词在不同平台指的不是一回事：有的把长期密钥也叫 Token，有的把用量计量单位也叫 Token。名字撞车，事故就出在把该藏的东西贴到了前端，或者把临时凭证写死了当长期配置。

这篇不讲概念史，只讲一件事：当你手里拿到某个平台的凭证时，怎么在三分钟内判断它属于哪一类、该放哪、能不能公开、过期了怎么办。下面按判断、落位、分配轮换、泄露排查、上线清单的顺序走一遍。

先分清两种东西：一个是长期身份，一个是短期凭证

API 密钥通常是你和平台之间的长期身份标识，回答的是「谁在调用」，一般放在服务端配置或密钥管理里，可以长期不变。Token 多数场景下是这次会话或这次请求的临时凭证，回答的是「这次调用是否被授权」，会过期、能刷新。判断方法就一条：会不会过期、能不能刷新。会过期能刷新的，基本是会话凭证，别当长期配置写进代码。

还有一种最容易误判的情况：对方说的 Token 其实是计费或上下文长度的计量单位，跟鉴权完全无关。看到这个词先问一句「你说的是鉴权凭证还是计量单位」。基础概念的对照，可以到站内 /ai-dict/category/basics 查当时的条目定义。

各自该出现在哪一层：浏览器、客户端、服务端

长期 API 密钥只应出现在服务端：后端服务、CI 的加密变量、本地开发机的环境变量文件，并且这个文件不能提交进仓库。任何会下发到用户浏览器、或被打包进 App 的代码，都不该带长期密钥。如果业务上非要在前端直连，也别把密钥塞进去，改走网关转发，把鉴权收在服务端一层。

客户端类工具（编辑器插件、聊天客户端）里填的 Key，实际多半存在本地明文或系统钥匙串里。单人机器问题不大，多人共用一台机器、或者录屏演示时，这一点必须先说清楚，否则一次截图就可能把身份凭证漏出去。

• 能在服务端发的请求就别在客户端发，前端只拿业务结果，不碰鉴权材料。
• 鉴权集中在网关或统一中间件，别散落在各个调用点，否则轮换时要改十几处。
• 开发机用单独一份密钥，和线上那份物理隔离，出事时能只停一个。
• 提交前扫一遍仓库改动，重点看配置文件、示例代码、README 和测试脚本里有没有长串字符。
• 录屏、截图、工单里贴请求时，把密钥字段替换成占位符再发。

怎么发给别人、怎么轮换、怎么不互相牵连

发密钥的原则是「一份只干一件事」。本地开发、测试环境、线上服务、临时试用各一份，按用途拆开；再按权限拆，能用只读或受限额度版本的就别发全权限的。这样某一份泄露或要重置时，影响面被限制在一小块，不用整条链路陪跑。

具体额度和并发上限这类信息各平台口径不同，到站内 /official-api 核对当时的数字，别拿记忆里的旧数值做容量规划。轮换要有周期也要有触发条件：定期换、人员变动换、怀疑泄露立刻换。

1. 先加新的生成新密钥并部署到服务端，配置里同时保留新的和旧的，确认新密钥能正常拿到响应。
2. 切流量把调用切到新密钥，观察一段时间，确认错误率没有上升。
3. 再删旧的确认没有残留调用后吊销旧密钥。反过来做最容易出现一波 401，还难判断是切换失败的还是旧密钥被停用导致的。
4. 记录时间点团队文档里写下轮换时间和下次计划时间，别靠某个人记着。

怀疑泄露了，按这个顺序查

先确认影响范围，再做处置，最后回头看流程。顺序反了容易一边说「我再观察观察」，一边被持续消耗额度。第一步查这份密钥能调哪些模型、有没有额度上限、有没有绑定来源限制；范围越小，处置越从容。

第二步看用量和调用日志，对照异常时间点，先判断是被人刷了还是自己跑批跑飞了。站内 /usage 和 /ai-status 可以帮你把时间线对齐，再决定是立刻吊销还是先限流观察。

1. 查范围确认这份密钥的权限、额度上限、来源限制，判断最坏情况下能被用掉多少。
2. 对时间线拿用量曲线和自家任务日志对照，看异常调用是不是自己发起的。
3. 先停用再换新确认不是自己跑的，直接吊销并生成新密钥，不要边观察边放着。
4. 找泄漏点依次检查仓库历史、前端打包产物、日志、聊天记录和截图，重点看有没有被提交过又删掉的提交。
5. 补流程把密钥挪进环境变量或密钥管理，加网关收口，再补一条提交前扫描。

上线前过一遍这张对照清单

这套清单不区分项目大小，五人的小团队和单人项目都适用。判断标准是：如果明天某一份密钥泄露，你能不能只停它、不影响到其他环境，并且知道去哪看用量、去哪停用。

不适用的情况也说清楚：如果只是本地跑个一次性脚本、密钥用完即弃，那上面关于轮换周期和网关收口的条目可以放宽；但只要这份密钥能长期访问计费资源，就按正式环境对待。团队规模很小、没有专职运维时，至少把「服务端存放」和「提交前扫描」这两条做到位。