# 企查查与DeepSeek代理Token自动恢复

版本1.0.1，优化时间2026-10-27（Asia/Shanghai）。正式企查查三接口、DeepSeek普通JSON/流式调用及复用它们的部署检查均支持此流程。

## 处理流程

1. 先使用现有URL中的`proxyToken`。有效时直接调用，不登录DMS，也不要求新增配置。
2. 仅在代理返回外层JSON业务码`212`时确认Token失效；支持HTTP成功响应及401/403响应中的同一业务码。权限码201、企查查Status 115、无明确212的HTTP错误、网络错误和生成中断均不触发刷新。
3. 复用项目现有DMS认证配置和登录实现，获取短期Token。配置为主机加`AUTH_PORT`和`DMS_PORT`时，使用认证端口的`/oauth/api/user/login`；显式`/proxy_dms`及`DMS_LOGIN_URL`沿用现有规则，不猜测新的登录地址。登录表单仍为项目已使用的`userName/password/clientId/serviceId`，不执行栏目、模型或业务数据操作。
4. 新Token仅保存在进程内，同一配置路径、同一代理协议/主机/端口的企查查和模型请求可复用。并发失效请求共用一次刷新；不同代理地址不共享缓存Token。只替换URL中的Token值，其余query原始编码/顺序、QCC签名和时间戳、业务参数、模型payload及Bearer头保持。
5. 当前请求最多重放一次。登录失败或新Token仍被拒绝时，30秒内不再重复登录；后续请求可重新尝试。Token没有已验证的过期时间契约，因此不猜测TTL，后续明确失效再刷新。重启进程会清空缓存，恢复从配置Token开始。

## 配置及故障边界

无需改写现有`.env`，也没有新的必填环境变量。刷新复用已有`DMS_BASE_URL`、`AUTH_PORT`、`DMS_PORT`、`DMS_USERNAME`、`DMS_PASSWORD`及可选`DMS_LOGIN_URL`。实际生效值仍按现有配置加载优先级确定；仅有静态`DMS_TOKEN`而没有可登录账号/密码时，不能自动生成新Token。现有Token有效时，缺少DMS登录信息不会影响正常代理请求。

刷新失败报告`proxy_token_refresh_failed`，刷新后再次被拒绝报告`proxy_token_invalid`；模型包装层可能带`model_`前缀。日志和部署检查仅保留固定错误码，不输出Token、账号密码、完整URL或响应正文。DMS登录拒绝重定向并沿用有限超时，失败不会伪造成空政策或正常回答。

DeepSeek流式请求只在输出模型内容之前识别代理拒绝并重试。正常SSE仍按原字节增量读取；一旦已收到正文，后续断流、格式错误或取消不会触发认证重放，避免重复输出或拼接两次回答。普通模型JSON严格解析结果在本次传输内复用，避免刷新检测增加第二次解析。

## 已验证范围

本地回环HTTP和合成凭据覆盖有效初始Token、明确失效、短Token再次失效、两类服务共享、并发单次登录、失败冷却、权限/供应商错误、401/403、重定向拒绝、参数/签名保持、分片JSON、流式首段及时送达、断流和取消不重放。测试逐次核对临时`.env`字节不变。

本轮未调用线上代理或DMS，未改实际`.env`，没有验证生产账号权限、短Token对各代理服务的授权或实际有效期。生产联调、打包和部署须在用户核对全部优化清单后另行进行。配置连接契约见[DMS配置](dms-schema.md)，已有检查命令见[部署操作指南](deployment.md)。