One API 和 New API 怎么选？按任务、许可证与迁移风险核对
对照官方资料区分项目能力与部署验收，固定候选版本，检查渠道、权限、计费和数据迁移，用任务矩阵决定是否切换并明确回滚条件。
选 One API 还是 New API，先写清你的客户端实际要完成什么任务，再核对目标版本的接口、权限、计费和维护方式。已经运行的网关如果满足需求，不应只因为另一个项目功能表更长就直接换镜像。
本文面向自行维护 API 网关的个人和小团队。资料核对日期为 2026-10-21，引用固定提交中的官方说明，区分“项目文档声明”与“部署验收通过”。没有做两款网关的性能对比，也不提供通用的生产数据库迁移命令。
1. 先把需求写成能验收的任务
“支持很多模型”不是足够具体的选型条件。同一个客户端可能同时使用普通聊天、流式输出、工具调用、文件或异步任务；只验证一句问候，无法覆盖完整工作流。
先为当前必需的功能填下面这张表。暂时不用的能力写“不适用”，不要让未来可能用到的功能压过现在的可靠性需求。
| 项目 | 要填的内容 | 通过条件示例 |
|---|---|---|
| 客户端 | 名称、版本、实际发出的请求路径与协议 | 原客户端无需丢失必需字段即可完成任务 |
| 上游与模型 | 授权接入来源、精确模型 ID、允许的别名映射 | 请求到达预期渠道，不意外换模型 |
| 输出方式 | 非流式、流式，是否包含工具或附件 | 结果完整，结束状态与错误可识别 |
| 权限 | 管理员、普通用户、应用密钥、分组 | 禁用密钥和越权模型被拒绝 |
| 费用记录 | 计量单位、价格来源、用量与扣额关联 | 一次逻辑任务的尝试和扣额能够解释 |
| 运维 | 数据库、备份、部署窗口、负责人 | 出错时能停止切换并恢复已验证的组合 |
这里的通过条件是你要执行的检查，不是本文已经取得的测试结果。渠道是否拥有上游权限、某个模型是否可用，也不能由开源网关的项目名称保证。
2. 两个项目的资料分别能证明什么
以下比较仅针对文末固定提交中的 README 和许可证。[1]—[4] 当前源码说明可能领先于正式发布版，也可能与旧版不同；正式选型要换成你准备安装的版本再核对一次。
| 维度 | One API 的官方说明 | New API 的官方说明 | 决策时怎样使用 |
|---|---|---|---|
| 基础管理 | 列出多渠道负载均衡、令牌管理、用户与渠道分组、模型映射、失败重试 | 列出路由、优先级与权重、访问控制、配额、用量与成本管理 | 先确认必需规则能否配置，不凭菜单数量打分 |
| 接口能力 | 以统一兼容格式接入不同上游；提醒模型映射可能重构请求体，影响未支持字段的透传 | 列出多种文本协议及转换，并明确功能依赖渠道、上游模型和转换路径，字段未必完全对应 | 对实际客户端请求做验证，不能把“兼容”理解为全部功能等价 |
| 配置与运行 | 提供部署、数据库、环境变量及多机部署说明 | 提供部署、数据库、环境变量及多节点配置说明，并提醒固定镜像版本、评估迁移兼容性 | 按目标版本逐项核对；不要把一边的默认值复制成另一边的事实 |
| 许可证 | LICENSE 为 MIT | LICENSE 为 AGPLv3；README 还列出署名与原项目链接等附加条款说明 | 二次开发、分发或对外提供服务前，核对所用版本的完整条款 |
这张表没有宣称 One API 缺少所有未列出的功能，也没有把 New API 文档中的接口支持等同于你的上游全部支持。某项能力没有查到可靠说明时，应标记为“待确认”，不能凭印象填“不支持”。
New API 的官方 README 将 One API 列为原始项目基础。[2] 项目渊源可以解释一些相似概念，但不能证明任意版本之间数据库双向兼容、密钥可直接沿用或旧程序能读取迁移后的数据。MIT 与 AGPLv3 也不能因为存在项目渊源就混用；需要阅读目标版本的许可证及相关声明，而不是只看仓库徽章。
3. 把候选版本固定下来，再决定是否值得迁移
为每个候选记录仓库地址、正式版本标签、镜像摘要、对应文档与发布日期。不要把不断变化的 latest 标签当成可复现的版本号，也不要把 main 分支 README 中刚加入的能力当成旧镜像的既有功能。
接着检查与你有关的发布说明和已知问题：你的数据库引擎、客户端协议、流式返回、模型映射或权限规则是否受影响；修复是否进入了你准备安装的发布版。问题被关闭、源码已有改动、镜像已包含修复，是不同状态。提交频率和 Star 数都不能替代这些检查。
选择可以按三种情况处理：
- 现有 One API 已通过必需任务，暂时没有明确缺口：保留当前可维护版本，记录后续触发迁移的条件。
- 某项必需工作流在当前版本无法满足，而 New API 的目标版本有相应说明：进入隔离验收，验证实际渠道和配置，再决定切换。
- 两边都能完成任务：比较自己能承担的维护步骤、故障定位方式、许可证要求和升级窗口，不替没有数据的性能或稳定性打分。
新建网关也应执行同样的验收，只是不需要搬迁旧账户数据。项目免费可获取源码，不代表服务器、数据库、维护和上游调用都没有成本。
4. 迁移前拆开五类配置，别直接共用生产库
如果决定评估迁移，先建立“原配置 → 目标配置 → 验证结果”映射。数据库备份方法可参考网关备份与恢复演练；这里重点检查跨项目语义，不重复备份命令。
- 渠道与模型映射。 记录渠道类型、目标地址、分组、优先级、权重、重试与回退策略。名称相同不表示枚举值或路由行为相同；必要时按目标版本文档重建。
- 用户与应用密钥。 核对角色、禁用状态、额度、模型范围、有效期等实际使用的限制。区分用户调用网关的密钥与网关调用上游的凭据；是否可保留旧令牌必须有对应版本的迁移证据，不能默认成立。
- 价格与账户资产。 对照原始计量单位、倍率、价格表、余额和未结算记录。界面显示的同一个数字，不一定采用同一单位或舍入方式；不要直接手改余额来抹平差异。
- 运行依赖。 核对数据库、日志库、缓存、挂载路径、环境变量和加密或会话密钥依赖。变量名相同不保证默认值、用途和生效范围相同；仅改容器名不能确保隔离。
- 外部集成。 若使用登录回调、支付通知、邮件、定时任务或管理 API，把调用方一起列入验收。复制一套网关后，不能让两套同时消费同一生产事件。
先把数据恢复到独立数据库和独立目录，保留一份未被新程序修改的原始恢复副本。启动演练实例前阻断生产数据库、付费上游及支付邮件等外连，关闭后台任务，再接入受控的本地模拟服务。原库继续供生产使用时，不要让候选程序连接它来“看看能不能启动”。
只有找到明确适用于源版本、目标版本和数据库引擎的官方迁移路径，并在副本上验证之后，才讨论复用数据。没有这样的证据，就把迁移方式标记为未确认；考虑新建实例后受控重建配置，不尝试把两个项目长期混跑在同一个数据库上。
5. 用验收矩阵区分文档支持与实际可用
先做本地模拟验收，再由维护者在明确预算下验证必要的真实上游功能。模拟可以检查网关的鉴权、路由和异常处理，不能证明模型质量、真实 Token 用量或实际供应商扣费。本文提供检查方法，没有运行真实网关迁移或付费 API 测试。
| 场景 | 在隔离环境怎么检查 | 失败后优先核对 |
|---|---|---|
| 权限边界 | 用普通用户的受限测试令牌，分别尝试允许、禁止和已禁用状态 | 用户角色、令牌限制、分组与模型映射 |
| 普通与流式响应 | 模拟正常结束、流式中断和错误响应；记录是否错误标记为成功 | 适配器、代理缓冲、超时及结束事件处理 |
| 路由与重试 | 让模拟上游按计划失败，记录每次尝试的渠道、模型及关联标识 | 权重、优先级、重试和回退配置 |
| 工具或异步任务 | 只在业务需要时，用无外部副作用的测试工具或任务检查完整往返 | 协议字段、任务 ID、状态查询及重复执行风险 |
| 用量与扣额 | 用固定的模拟用量核对本地计费规则，再单独核对真实账单 | 单位、倍率、舍入、失败请求和多次尝试 |
| 管理与审计 | 普通用户不能读取管理数据；脱敏记录能关联一次任务及其尝试 | 权限检查、日志字段和关联方式 |
固定模拟用量只验证本地计算规则，不证明上游会按这个数字计费。错误请求是否扣费也应按实际渠道条款和账单核对，不能由 HTTP 状态码推定。
例如团队只需要流式文本和受限密钥，工具与异步任务可以标记为“不适用”；若某个客户端任务必须经过工具调用再读取结果，就要完成整个往返。不要为凑齐所有功能主动扩大测试范围，但必需功能失败时不能用另一个成功的聊天样本抵消。
如果普通调用成功、关键参数失效，可继续看网关参数丢失排查。如果失败后切到别的模型，按模型回退验收核对，不能把不同结果都算作原任务成功。
6. 达到切换条件后，再开放真实流量
切换前写下三项条件：必需任务全部通过；数据与权限差异已经解释；停止切换和恢复旧环境的责任人与步骤明确。不能解释的余额差异、越权访问或意外模型回退，都是暂停条件。
约定切换截点，停止旧入口接收新任务，并等待在途请求与账务处理收敛。测试阶段只给明确的低风险应用分配目标实例；不要让同一个用户或交易随机落到两个各自记账的数据库，也不要把支付回调复制给两边。保持单一的账务权威来源。
如果数据库发生了迁移，回滚必须同时考虑程序版本和数据状态；切回旧镜像不保证旧程序能读新结构。新环境开放写入后产生的账户修改、扣额和任务结果也不能靠恢复旧快照自动保留。恢复方法与新增记录的处理应在切换前演练，而不是故障时临时拼接数据。
最后保存一页决策记录：选择的项目与固定版本、必需任务的结果、配置映射、未验证范围、切换截点和回滚条件。只有“文档写着支持”，结论应是“候选”；完成了对应版本与真实工作流的验收，才可以写“适合这套部署”。
7. 一手资料与版本边界
- [1] One API README，提交 8df4a26：基础管理、模型映射提示、部署与配置说明。
- [2] New API README，提交 206e0fa：能力范围与转换限制、固定版本建议、项目渊源及附加条款说明。
- [3] One API LICENSE，同一提交：MIT 正文。
- [4] New API LICENSE，同一提交：AGPLv3 正文。
以上为 2026-10-21 查阅的源码快照，不宣称它们就是最新稳定版。本篇没有比较报价、排名、吞吐量或具体模型的可用性；上线前请核对你实际选择的发布版本与上游授权。