LiblibAI API使用Secret Key鉴权，需通过HTTPS Header传Authorization: Bearer {Secret Key}，配合对应环境Base URL（正式/测试不可混用），密钥须从环境变量加载且仅显示一次，轮换为人工操作而非协议强制。
PHP调用文生图类接口（比如LiblibAI）时，鉴权不是靠JWT或Session，而是直接使用API密钥（Secret Key）+ HTTPS Header传参。所谓“密钥轮换法”，本质是避免长期硬编码单个密钥、降低泄露风险的运维实践，不是协议层标准机制。
LiblibAI API密钥怎么用？别漏掉Base URL和环境隔离
LiblibAI的鉴权方式极简：每个请求必须带 Authorization: Bearer {Secret Key}，且请求地址必须匹配对应环境的 Base URL。
-
Base URL不能混用：正式环境是https://api.liblib.ai/v1，测试环境是https://test-api.liblib.ai/v1；用错会导致 401 或 404，且错误响应不提示具体原因 -
Secret Key生成后只显示一次，关闭页面即不可查——丢密钥 ≠ 重置，只能新建密钥再更新服务端配置 - 不要把
Secret Key写死在代码里，应从环境变量加载，例如用getenv('LIBLIB_AI_SECRET_KEY')或$_ENV['LIBLIB_AI_SECRET_KEY']
为什么叫“密钥轮换”？它和JWT过期逻辑完全不同
JWT的 exp 是 Token 自身携带的时间戳，由签发方控制；而 LiblibAI 的密钥本身无有效期，轮换是人为操作：停用旧密钥、启用新密钥、更新服务端配置。它的驱动力是安全策略，不是技术强制。
- 轮换前必须确保新密钥已在 LiblibAI 控制台「启用」状态（部分平台默认创建后需手动启用）
- 轮换期间建议双密钥并行：先用新密钥发请求验证通路，再下线旧密钥，避免请求中断
- 旧密钥一旦禁用，所有持该密钥的请求立刻返回
401 Unauthorized，不会降级或缓存
PHP请求示例：cURL里怎么塞密钥才不出错
常见错误是 Header 格式不对、空格/换行混入、没设 Content-Type。LiblibAI 要求明确指定 application/json，否则可能返回 415。
立即学习“PHP免费学习笔记（深入）”；
$url = 'https://api.liblib.ai/v1/generate';
$secretKey = getenv('LIBLIB_AI_SECRET_KEY');
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode([
'prompt' => 'a cat wearing sunglasses',
'model' => 'sd-xl-base'
]));
curl_setopt($ch, CURLOPT_HTTPHEADER, [
'Authorization: Bearer ' . $secretKey,
'Content-Type: application/json',
'Accept: application/json'
]);
$response = curl_exec($ch);
curl_close($ch);
- 注意
Bearer后必须有一个英文空格，不能写成Bearer{$secretKey} - 如果用 Guzzle，
headers数组里同样要严格保持空格格式：['Authorization' => 'Bearer ' . $secretKey] - 响应体是 JSON，但出错时可能返回纯文本（如密钥错误时返回
Unauthorized字符串），需先检查curl_getinfo($ch, CURLINFO_HTTP_CODE)
密钥轮换真正容易被忽略的点，是下游依赖服务——比如你用 Redis 缓存了某次文生图结果，并把 Secret Key 拼进了缓存 key，轮换后这些缓存就永远失效且无法刷新。这类隐式耦合，比代码里的硬编码更难排查。
