provider 报错看起来很像，但根因经常完全不同。key 可能是对的，只是 endpoint 错了；endpoint 可能是对的，但 provider 选错了；也可能整套配置没问题，只是你还以为当前走的是另一条 backend 路线。
这页要帮助用户把 provider 问题拆成凭证、provider 选择、endpoint 路由和运行时继承四类。
先确认当前 key 是否真的属于你以为正在使用的 backend。
确认配置中的 provider 是否和你的 key、模型路线一致。
在怀疑密钥前，先确认 base URL 和后端路由假设是否正确。
确认当前运行时没有被旧环境变量或旧 shell 配置悄悄覆盖。
当你已经知道问题属于凭证、provider 选择、endpoint 路由，还是环境变量继承时，就可以离开这页了。
先拿可执行例子，再回头做更细的调整。
先核对 provider 名称、endpoint 和环境变量覆盖，再决定要不要动凭证。
# 先看配置里的 provider 块
# 再看当前 env 覆盖
# 最后才去测凭证更稳的 provider 排错，是把 auth、endpoint、provider 选择分层测试，而不是一次全改。
# 先测当前 key
# 再测 endpoint
# 最后再测 provider 选择先判断你卡在哪一层，再去对应分支，不要把所有问题都混成一个。
那通常不是 key 本身的问题，而是 provider 或 endpoint 层本来就错了。
先回去看环境变量和旧 shell export，不要立刻重写配置。