API 密钥怎么保管？把它当成一把有权限的钥匙

1. 密钥不是普通配置

API 密钥或访问令牌让程序使用某个服务，像一把能打开指定门的钥匙。拿到它的人，可能在授权范围内调用资源或产生费用。它和模型名字、网页标题不同，不能因为一段代码是“示例”就把真实密钥贴进去。学习时使用明显的占位符，真实凭据交给受保护的配置管理。

2. 钥匙留在服务端

浏览器要使用 AI 功能，可以请求你自己的后端，再由后端携带密钥调用上游。前端代码会被用户下载，把密钥藏进 JavaScript、页面源码或浏览器存储，都不能视为保密。受保护的服务端配置、访问控制和合理的调用限制，才是这个流程需要的基础；示意图里的服务端也不是自动安全的保险箱。

3. 不同用途，配不同钥匙

开发测试与线上服务最好分开使用凭据，权限只给当前任务需要的范围。例如只需读取资源，就不要同时赋予无关的写入能力。日志记录请求编号、状态与必要错误信息，避免输出完整令牌。排查问题时发截图，也先检查是否露出了密钥、Session 或其他登录凭证。

4. 泄露后，先让旧钥匙失效

发现密钥出现在公开仓库或网页，删除那行文字并不能让别人手里的副本失效。先在供应方撤销旧凭据，替换相关服务配置，再检查近期调用情况。一个简单练习是搜索自己的测试项目：凭据有没有进代码、截图或日志？别把搜索结果中的真实密钥再发给别人；只记录它出现的位置和处理状态。

可以给练习凭据准备一张管理清单：用途、授权范围、存放位置和撤销入口。清单只记名称与位置，不写完整密钥。换人维护项目时，也能知道哪些配置需要交接，避免把唯一一把钥匙留在某个人的聊天记录里。