DS2API鉴权模式全解：托管账号 vs 直通token，到底该怎么选
【免费下载链接】ds2apiDeepSeek-Compatible Middleware Interface: A technical exploration project in Go, focusing on high-concurrency protocol adaptation. It serves as a reference implementation for converting diverse web protocols into standardized formats.项目地址: https://gitcode.com/GitHub_Trending/ds/ds2api
DS2API 是一个将 DeepSeek Web 对话能力转换为 OpenAI、Claude、Gemini 兼容 API 的中间件项目，它的鉴权模式只有两种：托管账号模式和直通 token 模式。本文用一张对照表 + 一个真实场景，帮你快速判断哪种模式更适合你的部署方式。
两种鉴权模式，一句话看懂 🔑
DS2API 判断依据非常简单：你传入的 token 在不在config.json的keys列表里。
| 模式 | 触发条件 | 实际行为 |
|---|---|---|
| 托管账号模式 | token 命中config.keys | 服务端自动登录托管的 DeepSeek 账号，轮询选用、自动刷新 token |
| 直通 token 模式 | token 不在config.keys中 | 直接把你传的 token 当作 DeepSeek 上游 token 使用 |
判断逻辑的入口在 request.go 的Determine方法：先取出调用方凭据，再查config.keys是否存在，命中与否决定走哪条链路。
托管账号模式：让 DS2API 帮你管账号
工作原理
你在配置里填入邮箱/手机号 + 密码（见 config.example.json 的accounts段），DS2API 会：
- 自动登录并持久化 DeepSeek 会话 token（request.go 的
loginAndPersist） - 按
token_refresh_interval_hours（默认 6 小时）周期性强制刷新 - 账号失效时自动重新登录；遇到上游空输出 429 还会自动切换到下一个可用账号重试
账号池与并发控制 📊
多个托管账号由账号池统一调度（pool_core.go）：
每账号并发上限 = account_max_inflight（默认 2） 建议并发值 = 账号数 × 每账号并发上限 等待队列 = account_max_queue（默认 = 建议并发值）- 槽位满时请求先进等待队列，不会立即 429
- 超出总承载上限才返回
429 Too Many Requests GET /admin/queue/status可实时查看队列状态
指定账号：X-Ds2-Target-Account 请求头
想让某个团队固定使用某个账号？加一个请求头即可：
X-Ds2-Target-Account: <email 或 mobile>注意：指定账号后不再自动切号，目标账号不可用时直接返回429。账号标识规则见 account.go 的Identifier方法（邮箱优先，其次归一化后的手机号）。
直通 token 模式：自带 token，零配置接入
如果你手里已经有一个有效的 DeepSeek 会话 token，直接当x-api-key传入即可：
curl http://localhost:5001/v1/chat/completions \ -H "x-api-key: <你的DeepSeek token>" \ -d '{...}'特点：
- 不占用账号池，不做轮询、不做自动刷新
- token 过期后由你自己负责更新
- 适合调试、临时压测、或已有固定 token 的场景
凭据提取的完整优先级（Authorization: Bearer→x-api-key→x-goog-api-key→?key=→?api_key=）见 request.go。
选型对照表：到底怎么选？🎯
| 维度 | 托管账号模式 | 直通 token 模式 |
|---|---|---|
| 配置成本 | 需填账号密码 | 只需一个 token |
| 多账号轮询 | ✅ 自动 | ❌ 无 |
| token 自动刷新 | ✅ 内置 | ❌ 自理 |
| 429 自动切号 | ✅（未指定账号时） | ❌ |
| 并发队列保护 | ✅ | ❌ |
| 多用户共用一个服务 | ✅ 每用户一个 key 隔离 | ⚠️ 各自带 token |
| 适用场景 | 团队共享、生产部署 | 个人调试、临时使用 |
经验法则：多人共用、长期运行 → 托管账号模式；自己快速验证 → 直通 token 模式。两者可共存，互不冲突。
上手配置 3 步走 🚀
- 复制示例配置：
cp config.example.json config.json - 编辑 config.example.json：
keys：生成调用端 API key（每个客户端一个，建议用api_keys附加备注）accounts：填入邮箱+密码 或 手机号+密码runtime：按账号数调整account_max_inflight、token_refresh_interval_hours
- 客户端把 Base URL 指向 DS2API，API key 填
keys中任一项即可
部署细节见 docs/DEPLOY.md，接口全表（含鉴权列）见 API.md 的「鉴权规则」章节。
常见问题 FAQ ❓
Q：两种模式可以同时混用吗？可以。命中keys的调用走托管池，未命中的 token 直通上游，同一实例内并行工作。
Q：直通 token 会享受账号池的并发保护吗？不会。直通请求不进入 account 包的队列，高并发下直接压向上游，请自行控制节奏。
Q：托管账号登录失败返回什么？返回对应的401或上游错误；若全部账号耗尽则返回429（无Retry-After头）。
写在最后
DS2API 的鉴权设计核心就是「一个 key 决定两种命运」：托管账号模式把登录、刷新、轮询、重试全部托管给服务端；直通 token 模式则把上游凭据原样透传。读懂 internal/auth 与 internal/account 两个目录，你就能完全掌握这套机制 —— 更多模块边界可查阅 docs/ARCHITECTURE.md。
【免费下载链接】ds2apiDeepSeek-Compatible Middleware Interface: A technical exploration project in Go, focusing on high-concurrency protocol adaptation. It serves as a reference implementation for converting diverse web protocols into standardized formats.项目地址: https://gitcode.com/GitHub_Trending/ds/ds2api
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
