JellyToken 的 API 密钥管理核心只有三件事：让每个调用方拥有独立密钥、把密钥放进环境变量而不是代码仓库、在控制台定期撤销和查看日志。团队共用同一个密钥看似省事，实际上一旦泄露或超量调用，很难定位是谁的责任，也无法按项目限制影响面。下面按团队场景、生成密钥、环境变量引用、轮换撤销、日志审计五个步骤整理一套可直接落地的做法。

适用场景：团队共用 JellyToken、需要为多个项目或成员分配独立访问凭据。操作动作：在 JellyToken 控制台为每个项目/成员生成密钥，按统一规则命名，通过环境变量注入应用，并设置定期轮换提醒。验证方式：在控制台观察每个密钥的调用日志和错误率，确认可疑请求后立即撤销对应密钥。风险边界：JellyToken 的权限粒度取决于账号本身的角色体系，当前只讨论密钥数量的隔离，不假设平台支持细粒度权限策略；若后续平台开放权限分组，建议再叠加使用。

梳理团队使用场景

先别着急生成密钥。建议按下表把实际调用方列出来，每行对应一个独立密钥。这里的“独立”是指：不同的项目、不同的部署环境（开发/测试/生产）、不同的外部合作方，都应当使用不同密钥。

规划时注意：如果同一个项目里有多个开发者在各自的电脑上调试，可以按人再拆一层，例如“订单服务-张三-本地”。但不要拆到每次请求一个密钥，那样日志会变得零碎，控制台也不好管理。

在JellyToken控制台生成多个密钥

登录 JellyToken 控制台后，一般可以在“API 密钥”或“访问令牌”页面找到创建入口。建议的路径是：控制台 → API 密钥 → 创建新密钥。创建时通常需要填写名称和备注，部分版本还会要求选择过期时间。

命名规则建议采用三段式：项目-环境-用途，例如：

order-prod-backend
order-dev-local-zhangsan
data-test-cron
partner-callback-prod

备注里写明负责人、创建日期、使用的具体服务名称。比如“订单服务后端专用，2025-06 创建，负责人李工”。这些信息在日志审计时会非常有用。创建成功后立即复制密钥值，因为关闭页面后通常无法再次查看完整内容。

在应用中使用环境变量引用密钥

不要直接把密钥粘贴到代码里，也不要提交到 Git。规范做法是在部署平台（如 Docker、Kubernetes、云服务器环境变量配置）或本地 .env 文件中设置环境变量，然后在代码中读取。下面给出十种常见语言加载环境变量的方式，替换其中的 JELLYTOKEN_API_KEY 为你的变量名即可。

# Bash / Shell
export JELLYTOKEN_API_KEY="sk-xxxx"

echo $JELLYTOKEN_API_KEY

# Python
import os
api_key = os.environ["JELLYTOKEN_API_KEY"]

# Node.js
const apiKey = process.env.JELLYTOKEN_API_KEY;

# Go
import "os"
apiKey := os.Getenv("JELLYTOKEN_API_KEY")

# Java
String apiKey = System.getenv("JELLYTOKEN_API_KEY");

# Ruby
api_key = ENV["JELLYTOKEN_API_KEY"]

# PHP
$apiKey = getenv("JELLYTOKEN_API_KEY");

# C#
string apiKey = Environment.GetEnvironmentVariable("JELLYTOKEN_API_KEY");

# Rust
use std::env;
let api_key = env::var("JELLYTOKEN_API_KEY").expect("missing env var");

# Kotlin / JVM
val apiKey = System.getenv("JELLYTOKEN_API_KEY")

在 Docker 或 K8s 中，同样通过环境变量注入。如果使用 Docker Compose，可以在 environment 段引用宿主环境变量：JELLYTOKEN_API_KEY: ${JELLYTOKEN_API_KEY}。注意 .env 文件不要提交到代码仓库，建议加入 .gitignore。

定期轮换与撤销

密钥不能长期不换。建议为每个密钥设置 90 天或 180 天的过期时间。如果控制台支持“过期提醒”，可以在创建时绑定通知邮箱；如果不支持，可以在日历或内部运维系统里添加定时任务，每月提醒一次检查到期密钥。

撤销步骤如下：

1. 进入 JellyToken 控制台的“API 密钥”列表。
2. 找到要撤销的密钥，点击“禁用”或“删除”。
3. 确认该密钥不再被任何运行中的应用引用。
4. 生成新密钥，并更新对应环境变量。
5. 观察应用日志确认新密钥生效后，再彻底删除旧密钥。

如果某个密钥泄露，不要只改代码，要立即在控制台禁用该密钥，然后按上述流程轮换涉及的所有密钥。禁用后旧密钥会立即失效，未替换的应用会报 401 或 403，这正是验证替换是否彻底的方式。

审计调用日志

JellyToken 控制台通常会在密钥列表或“调用日志”页面展示每个密钥的请求量、错误率、最近调用时间等信息。建议每周查看一次，重点看两件事：一是某个密钥的调用量是否突然暴增，二是错误率是否异常升高。

识别可疑请求时，可以对照之前规划的密钥用途：如果订单服务的密钥在凌晨 3 点密集调用而业务上不应存在该时段任务，那就需要查看来源 IP 或 User-Agent；如果某个密钥原本只应该在测试环境出现，却出现在生产环境的日志里，说明配置串了，应立即撤销该密钥并重新分配。

控制台日志一般无法直接做聚合分析，建议定期导出或通过 API 拉取后再用内部日志系统过滤。但无论如何，密钥列表上的“用量”和“错误率”已经足够帮助判断异常。不要把日志只留在故障排查时才看，日常巡检是权限隔离有效性的基础。