中转站是怎么搭起来的？聊聊 new-api / one-api
这是一篇技术科普向的文章，不是教人开一个中转站站点做生意，而是帮你了解市面上这些中转站背后的技术架构从哪来——知道了原理，你在用任何一家中转站的时候，都能更快看懂它后台的那些术语和设置项。
绝大多数中转站用的是开源项目
市面上能看到的中转站，后台架构大多不是站长从零写出来的，而是基于两个开源项目二次开发：one-api 和 new-api。one-api 是这个方向上比较早、影响力比较大的项目，new-api 则是在它基础上发展出来的一个活跃分支，功能和界面都做了不少扩展。正因为大家用的是同一套底层逻辑，你会发现不同中转站的后台，虽然品牌、配色、域名完全不同，但核心概念和操作逻辑却出奇地相似。
这些开源项目提供什么
多渠道聚合
可以同时接入官方 API、云厂商折扣渠道、订阅拆分等多种上游来源，在后台统一管理成不同的「渠道」。
用户 / 令牌管理
支持给不同用户发放独立的 API Key（令牌），设置额度上限、有效期，方便做多用户运营。
按 token 计费
自动统计每次调用消耗的输入输出 token 数，按预设倍率扣费，这也是「倍率」这个概念的来源。
分组与倍率
把不同渠道、不同模型划到不同「分组」，每个分组可以设置独立的计费倍率，这就是为什么同一个模型在不同分组价格不一样。
兑换码 / 邀请返利
内置生成兑换码、邀请注册返利这类运营工具，方便站长做促销和拉新。
了解这些架构，对普通用户有什么用
当你在中转站后台看到「渠道」「分组」「倍率」「令牌」这些词的时候，其实都是这套开源架构自带的术语——渠道指的是接入的某一路上游来源，分组是把不同渠道和模型划分到一起、设置独立计费倍率的单位，令牌就是你的 API Key。理解了这套逻辑，你就能看懂为什么同一个模型在不同分组价格不一样，也能理解为什么很多中转站的 /api/pricing 这类接口返回的数据结构长得都差不多——大家本来就是同一套骨架改出来的。
自建的现实门槛
如果你想自己动手部署一套 one-api 或 new-api，技术上的搭建过程本身并不复杂，官方仓库都有现成的部署文档。但真正决定一个中转站能不能稳定运营下去的，其实是开源项目本身不解决的那几件事：你需要有稳定的上游 API 来源（官方 Key 或者其它可靠渠道，这部分开源项目帮不了你）；需要处理服务的稳定性和风控（防止被恶意调用、被薅额度）；如果打算对外提供服务，还要考虑支付渠道接入和用户客服。开源项目解决的只是「管理后台」这一层，「货源」和「运营」这两件更难的事，仍然要自己想办法。
这篇文章适合谁看，和一个提醒
这篇内容比较适合两类人：一是想自建自用（比如给自己的团队或几个朋友统一管理 API Key）的开发者，二是单纯想理解中转站运作方式、看懂后台术语的普通用户。需要提醒的是，如果你搭建之后打算对外经营、公开售卖调用额度，会涉及经营资质、支付合规、税务申报等一系列问题，这些都需要你自行评估和处理，本文只做技术架构层面的科普，不构成任何经营建议。
常见问题
one-api 和 new-api 是什么关系？
new-api 是在 one-api 基础上发展出来的一个活跃分支（fork），在原有功能上做了界面和特性上的扩展，目前不少新搭建的中转站会选择 new-api。两者的核心架构和概念（渠道、分组、倍率、令牌）是相通的。
为什么各家中转站的后台界面、接口结构看起来都差不多？
因为很多站点用的是同一套开源项目改造而来，即便做了品牌换皮和界面定制，底层的路由结构、术语（渠道、分组、倍率）、接口约定往往是一致的，这也是为什么你会发现不同站点的 /api/pricing 这类接口结构相似。
我自己搭一个 one-api / new-api，就能像中转站一样对外卖 API 吗？
技术上部署起来不难，但这只解决了「管理后台」这一层。你仍然需要自己的上游 API 来源（官方 Key 或其它渠道）、要处理服务稳定性和风控、要接支付和处理客服，这些是开源项目本身不包含的部分，也是运营一个中转站真正的门槛所在。
了解这些开源项目的架构，对普通用户（不打算自建）有什么用？
知道了「渠道」「分组」「倍率」「令牌」这些概念是怎么来的，你在使用任何一家中转站的后台时都能更快看懂它的计费逻辑和设置项，也更容易判断一个站点的运营是否规范、价格逻辑是否说得通。