很多人用着的中转站突然换了域名，第一反应是「我的 Key 是不是废了」。答案不绝对：看它换的是域名还是主体，看 Key 绑没绑白名单，也看你是直连还是走了自建转发。这篇不讲原理，给一套从确认身份到逐项重配的检查顺序，让你十分钟内判断出「原 Key 继续用」「要换配置」还是「必须重新申请」。
用着的中转站突然换了域名，第一反应基本都是「我的 Key 是不是废了」。答案不绝对：要看它换的是域名还是主体，要看你的 Key 绑没绑白名单，也要看你是直连还是走了自建转发。有人改一行地址就恢复了，有人折腾半天才发现得重新申请。
下面按环节给一套检查顺序，让你十分钟内判断出属于哪种情况：原 Key 继续用、只改配置、还是必须换 Key。全程别急着删旧东西，先确认再动手。
先确认：换的是域名，还是换了运营主体
第一步不是改代码，是确认对方身份有没有变。同一家做域名迁移，账号、余额、Key 一般原样延续；如果是站点被转手或主体变更，旧 Key 就该按作废处理，别抱侥幸心理继续调。
| 现象 | 大概率情况 | 怎么处理 |
|---|---|---|
| 旧域名自动跳转到新域名 | 同一主体迁移 | 账号能登、用量还在就继续用，改地址即可 |
| 旧域名打不开或被解析到别处 | 存在换手可能 | 先别调接口，核实站方公告和账号体系 |
| 同一账号能登进新站，历史记录在 | 账号体系延续 | 原 Key 多数可沿用，做小流量验证 |
| 账号登不进、余额查不到 | 旧体系已断 | 旧 Key 作废，按新站流程重新走 |
- 判断依据是账号体系是否延续（同一账号能登进去、历史用量还在），而不是新域名长得像不像
- 拿不准就去站内中转站目录核对这家站的当前入口与记录，别只信对方私聊发来的链接
- 公告含糊、客服口径前后不一、旧站数据不可见，这三种情况同时出现就别继续用旧 Key
Key 会不会失效，看它绑了什么
Key 本身只是一串凭证，能不能继续用取决于它绑了哪些校验项。只绑账号的，换域名后通常还能用；绑了来源、地址一类的，域名一变就对不上，得一起更新或者重发。
- 只绑账号的 Key
- 换域名后多数能继续用，你只需改代码里的 base_url
- 绑 IP 白名单的 Key
- 域名变了校验项大概率对不上，要在后台把白名单一起改
- 绑 Referer 或回调域名的 Key
- 这类字段和域名强绑定，必须逐个更新，漏一个就报错
- 地址写死在客户端的 Key
- Key 有效也没用，请求发到旧地址就是连不上
分不清就按最坏情况处理：先申请一把新 Key，旧 Key 留着观察，确认新域名正常后再决定要不要吊销。这样最多浪费一次申请，不会卡住线上。
要改的配置不止一处，按这个顺序过一遍
很多人只改了开发机上的项目，结果线上、CI、桌面工具轮流报错。建议按「从上游到下游」的顺序走一遍，每改完一层就标记一下，避免漏项。
- 代码与 SDK改 base_url 或 endpoint 变量、环境变量、写死在多个项目里的常量；改完搜一遍旧域名，确认没有残留
- 本地与云端工具桌面客户端、IDE 插件、命令行工具、CI 密钥库、服务器上的 .env 逐项对照，别只改开发机
- 中间层自建网关、反向代理、Nginx 转发规则、Webhook 回调地址，这些不改会让请求发不出去或回调落到旧域名
- 小流量验证发一次最小请求确认连通，再看延迟和错误率是否正常，确认无误后再全量切换
什么情况下别省事，直接换 Key
有些场景继续用旧 Key 省下的时间，远不够后面排查的成本。下面几条只要中一条，直接换 Key 更划算。
- 域名更换伴随公告含糊、旧站数据不可见、客服口径前后不一，风险已经超出「改配置」的范围
- 旧 Key 曾在公开仓库、聊天记录或第三方工具里出现过，换域名正好是一次免费重置机会
- 换域名同时换了运营方或计价口径，继续用旧 Key 等于把账单挂在一个你不了解的主体上
- 需要保留历史调用记录的，先导出账单与用量再动手，事后补证据很麻烦
判断「这家站还值不值得继续用」，光看接口能不能通不够。价格和口碑变化去站内价格追踪页面对照当时的数字，可信度变化去站内检测页面看当时的记录。
几个高频踩坑，提前避开
下面这几件事看着像捷径，实际都会把问题往后拖，而且拖出来的问题更难查。
- 直接把旧域名加 hosts 指向新服务器：能通也只是临时糊弄，证书和校验照样会出问题
- 以为「Key 能调通」就等于「这家站没问题」，连通性只说明接口活着，不代表可信度没变
- 一次性在多个环境同时切换且不做回滚方案，出问题时连对照基线都没有
- 切换前不记录旧配置，事后想排查是哪一步改错都无从下手
如果旧 Key 已经确认要作废，记得在旧后台吊销而不是直接删掉本地记录，留一段时间观察有没有遗漏的调用方在报错，确认干净了再清理。
下一步先确认这家站换域名后的主体有没有变，再决定是改配置还是换 Key。站内中转站目录整理了各家站点的当前入口与记录，对照一下比私聊链接靠谱。→常见问题
中转站换了域名，我原来的 API Key 还能直接用吗？
多数情况下能用，但要满足两个前提：一是同一运营主体的域名迁移，账号体系没断；二是你的 Key 没绑 IP 白名单、Referer 或回调域名。只要绑了其中任意一项，换域名后校验就对不上，需要在后台把相关字段更新，或者干脆重新申请一把新 Key。最稳的做法是拿最小请求实测一次，别靠猜。
除了改 base_url，还有哪些地方容易漏掉？
常见漏点有：CI/CD 里的密钥变量、服务器上的环境变量、IDE 插件与桌面客户端的自定义接口地址、自建网关或反向代理的转发规则、Webhook 回调地址。判断方法很简单——凡是出现过旧域名的位置都要搜一遍，包括文档和本地配置文件，改完再逐个服务发一次最小请求验证。
怎么判断这家站换域名是正常迁移还是风险信号？
看三点：旧域名是否做了正式跳转并有公告、账号登录后历史用量和余额是否还在、客服对换域名原因的解释是否一致。三点都清楚，基本属于正常迁移；如果公告含糊、旧数据消失、客服说法前后矛盾，就要按换主体处理，先导出账单和会话记录留证，再决定要不要继续用。
