Token是服务器签发的自包含授权信封，由Header、Payload（含权限与过期时间）和Signature三部分组成，通过签名与时效校验实现无状态鉴权，支持细粒度scope权限控制，区别于静态无权限的API Key。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
API中的Token是调用方访问受保护接口时必须出示的数字身份凭证，它不是密码的替代品，而是服务器签发的、自带权限声明和时效约束的加密信物；缺少它，绝大多数业务接口会直接返回401错误，且无法通过反复重试绕过。
Token的本质：一个自包含的授权信封
它不是一个随机字符串，而是一个结构化数据包——以JWT为例，由Header（算法声明）、Payload（用户ID、角色、scope权限列表、exp过期时间戳、iat签发时间）和Signature（服务端私钥签名）三部分组成。服务器收到后只校验签名和时间，【不查数据库就能完成鉴权】，因此支撑高并发无状态服务。
如果Payload里写着"scope": ["order:read", "user:profile"]，那这个Token就只能查订单和读用户资料，哪怕请求头里硬塞上DELETE /api/v1/user，也会被网关拦截并返回403。
Token与API Key的关键区别
方法一：API Key是静态长密钥，通常由管理员在控制台手动创建，绑定到某个应用或项目，没有内置过期机制，一旦泄露必须人工轮换；它只做身份标识，不携带具体操作权限。
方法二：Access Token是动态短时效凭证，由认证服务（如OAuth 2.0的Authorization Server）颁发，每次调用前需先用Client ID/Secret或用户名密码换取，本身含scope字段，天然支持最小权限原则。
注意：有些平台把两者混用，比如GitHub的Personal Access Token实际是带scope的Access Token，而Twilio的API Key仍是传统静态密钥——看文档里是否允许设置scope或expires_at字段，就能立刻区分。
权限落地的三道闸机
第一步：传输层校验 → 检查Authorization: Bearer xxx是否格式正确，Token是否为空或明显截断。
第二步：签名与时效校验 → 用公钥解出Header.Payload，验证Signature是否匹配，再比对当前时间是否小于exp值；【过期Token即使签名正确也立即拒收】。
第三步：作用域匹配 → 提取请求路径（如POST /v2/invoices）和HTTP方法，对照Token中scope数组逐项检查权限项是否存在；例如scope含"invoice:write"才放行该POST，否则返回403 Forbidden。
这三步缺一不可，跳过任何一步都会导致越权访问风险。网关或中间件通常按此顺序执行，中途失败即终止后续流程。
