这类问题我又碰上了一次。从 AI Studio 复制了 AIza 开头的 key，写进 .env 后调 gemini-1.5-pro，返回 400，原文 API key not valid. Please pass a valid API key，key 重新复制了两次，直接粘到 curl 里结果一样。
第一反应是「参数名写错 请求被当成匿名调用」，验证下来不成立。
排查方向其实有限，先把可能性排一排。复制时带进了引号或换行；key 属于另一个 Google 账号 项目没启用该 API；容器环境变量被空值覆盖。
上来先检查变量长度和首尾字符
python -c "import os;k=os.getenv('GEMINI_API_KEY','');print(len(k),repr(k[:6]),repr(k[-2:]))"再往下改用 header 传 key 再打一次
curl -s -o /dev/null -w '%{http_code}' https://generativelanguage.googleapis.com/v1beta/models/gemini-1.5-pro:generateContent -H "x-goog-api-key: $GEMINI_API_KEY" -H 'Content-Type: application/json' -d '{"contents":[{"parts":[{"text":"hi"}]}]}'然后列出可用模型确认项目已启用
curl -s -H "x-goog-api-key: $GEMINI_API_KEY" https://generativelanguage.googleapis.com/v1beta/models | jq -r '.models[].name'等前面都确认过，再重建容器排除空值覆盖
docker compose up -d --force-recreate api这次没动代码，只在配置和运行环境上找原因。
隔了一天再看，现象没变，说明不是偶发。
怎么算真的好了，看的是同一批现象。header 方式返回 200，模型列表非空，服务日志里的 key 尾号与 .env 一致。
Gemini 同时支持 query 和 header 两种传法，header 更不容易被日志和代理改写，排查时先用 curl 把变量因素排掉。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。