sub2api 近一周更新：从能跑业务，到更懂经营的 AI API Gateway

上一篇写 sub2api，我更多是在讲一个 fork 项目怎样被改造成自己的产品：不是换 Logo，不是改几行配置，而是把一个成熟的 AI API Gateway 当作底盘，继续往支付、订阅、首页、运营闭环这些真正影响产品成立的地方推进。那篇文章的核心落点是 BenszAPI：我怎样基于 sub2api 做出一个能跑业务的 API 产品。过了差不多一周，再回头看 huangwb8/sub2api 这个 fork，会发现它已经不只是“我的部署版”了，而是在沿着一个更清晰的方向快速演化：从能用、能卖，继续走向更安全、更可运营、更懂成本，也更适合长期维护的 AI API 中转平台。

这 1 周的变化非常密集。按 Git 记录看，从 2026-04-17 到 2026-04-24，项目一路从 v1.0.13 推到了 v1.0.27，中间经历了十几个版本标记。这个节奏其实很能说明问题：它不是那种憋一个大版本、最后放一坨功能出来的开发方式，而是非常典型的 Vibe Coding + 小步快跑模式。每次改动都围绕一个具体问题：支付是不是更可靠？订阅是不是更公平？后台测算是不是更能指导运营？OpenAI / Claude 的兼容是不是更稳？文档是不是能解释清楚真实业务规则？这些问题看起来分散，但合起来，就是一个 API 产品从“工程可运行”走向“业务可经营”的过程。

先说最直观的：公开套餐页和订阅升级终于更像一个产品了

这一周里，我觉得最有产品感的一组变化，是围绕订阅售卖链路展开的。

项目新增了站内公开费用页 /pricing，未登录用户、自定义首页、后台配置的费用入口，都可以复用同一套公开套餐展示逻辑。以前很多自建 API 网关最大的问题是：后台能配套餐，用户也能买，但对外表达经常是散的。你要么自己写一个静态页，要么在首页里硬编码几档价格，要么干脆靠人工解释。这样一来，后台真实配置和前台宣传页面很容易漂移。

现在的思路明显更工程化：后台上线什么套餐，公开费用页就展示什么套餐；自定义首页也可以调用公开套餐接口 GET /api/v1/payment/public/plans 自动读取。这意味着首页不再只是一个漂亮壳子，而是能和后台业务数据联动。

更重要的是，订阅补差价升级也补上了。管理员可以给套餐配置 upgrade_family 和 upgrade_rank，用户已有活跃订阅时，可以按剩余价值折抵升级到同一升级族里的更高档套餐。这个功能在小系统里很容易被忽略，但如果真的做 API 套餐售卖，它非常关键。用户买了低档套餐后发现不够用，最自然的动作不是重新买一份，而是补差价升级。没有这个能力，产品体验就会显得很粗糙。

这组变化还顺手修了一些很真实的边角问题，比如通过 URL 直达套餐或升级目标时复用选择逻辑、目标套餐不可升级时给出明确提示、首页费用入口在严格 CSP 环境下脚本不执行的问题。它们都不是“炫技功能”，但都是线上产品真正会踩到的坑。

支付链路这一周明显更稳了

如果说公开费用页和订阅升级解决的是“怎么卖得更顺”，那支付链路的这一组修复，解决的就是“卖的时候别炸”。

比较关键的一点是：微信支付配置现在不再等到用户下单时才暴露问题，而是在后台保存启用中的服务商实例时就做结构化校验。比如缺少 publicKeyId/certSerial、APIv3 Key 长度错误、PEM 非法等问题，都会尽早暴露出来。这个改动我很喜欢，因为它把错误从用户侧前移到了管理员侧。用户准备付款时才发现配置有问题，是最糟糕的体验；管理员保存配置时就发现问题，虽然当下多一步排查，但对产品整体稳定性是巨大提升。

另一个重要变化是订单创建时固化 provider 快照，记录 provider_instance_id、provider_key 和 provider_snapshot。这件事听起来偏底层，但它其实非常重要。支付系统最怕的一类问题，就是订单创建时用的是 A 配置，回调或补单时系统配置已经变成了 B，然后结果校验、手续费、商户信息全都对不上。现在订单自己保存当时的 provider 快照，支付结果页公开校验接口也补齐手续费和订单阶段信息，历史订单的可追溯性会明显更好。

这一周还修了 provider 串用和微信商户误认风险：后端会按订单绑定的 provider 做来源校验，并对微信支付回调 / 补单结果额外校验 appid、mchid、currency、trade_state 与订单快照是否一致。简单说，就是不要因为后台配置变化或多实例并存，就把不该履约的订单履约了。

支付 provider 配置的存储和读取也做了调整：新写入改为明文 JSON，读取端采用“JSON 优先 + 旧 AES 密文兼容回退 + 坏数据 fail-open 为空配置”的策略，避免支付配置依赖 TOTP_ENCRYPTION_KEY 才能在重启后读回。同时，管理端读取 provider 配置时会按类型剔除 privateKey、secretKey、apiV3Key、webhookSecret 等敏感字段，编辑时空敏感字段表示保持原值。这个地方其实是安全和可维护性的平衡：管理员要能编辑配置，但不应该让敏感字段在前端反复暴露。

订阅计费和盈利面板更接近真实经营

上一轮我已经提到，BenszAPI 这类产品最关键的不是“能不能转发请求”，而是能不能知道自己到底赚不赚钱。这一周 sub2api 在这方面推进得很明显。

首先，订阅类型 usage 增加了估算成本 estimated_cost_cny，并提供迁移回填历史订阅 usage。以前如果订阅请求成本统计一直为零，盈利趋势图就很容易变成一个看起来很美、但实际上失真的仪表盘。现在订阅和余额两类计费都复用同一套成本估算路径，至少数据口径开始往统一方向走。

然后是盈利面板的成本分摊逻辑被重构。/api/v1/admin/dashboard/profitability 不再依赖会持续漂移的账号历史累计分母，而是基于查询时间窗内账号 actual_cost_cny 与该账号窗口总 actual_cost 做比例分摊。这个修复很实用，因为经营面板最怕跨周期混淆：你看的是最近 30 天，结果成本分母却混进了很长历史周期，那最后算出来的利润率就会误导决策。

此外，项目还新增了“超售的数学原理”文档和 Dashboard 定价策略顾问面板。这里的思路是把用户需求分布、保本单价、用户池规模、安全缓冲这些因素放在一起算，而不是拍脑袋定价。后续 v1.0.25 和 v1.0.27 又继续重构这块 UI 和业务逻辑，把“定价策略建议 / 超售数学测算”改成更客观的推演模式：管理员指定用户数，系统展示保守成本、达标单价、当前定价利润与套餐折算结果。

这其实很符合 API 产品的真实运营场景。你不能只问“这个模型多少钱一百万 token”，还要问：用户到底会怎么用？不同套餐之间怎么分摊？闲时要不要便宜一点？目标利润率是多少？用户池多大时风险才可控？这一周的改动，就是在把这些问题逐渐变成后台里的可计算工具。

分组级闲时动态计费，是一个很有运营味道的新能力

v1.0.26 新增了分组级“闲时动态计费”能力，我觉得这是这一周最值得单独拿出来说的新功能之一。

管理员现在可以按北京时间配置精确到秒的闲时时间窗，并为这个时间窗单独设置闲时倍率与闲时额外盈利率。相关配置已经贯通后端分组模型、认证缓存快照、真实网关计费链路、管理端分组表单和测试。

这个功能背后的逻辑很简单：AI API 网关不一定所有时间段成本和资源压力都一样。高峰期和闲时的调度压力不同，运营策略也可以不同。闲时动态计费让平台可以在低峰期给用户更好的价格，或者通过额外盈利率控制不同分组的经营目标。

更重要的是，它不是一个只停留在配置表里的字段，而是已经进入实际网关计费链路。也就是说，用户请求真正结算时会感知这个时间窗策略。这类功能如果做好了，后面可以演化出很多玩法：夜间优惠、批量任务引导到低峰期、不同用户组差异化折扣、运营活动计费策略等等。

OpenAI / Claude 兼容也在继续补洞

作为 AI API Gateway，模型兼容性永远是核心问题。这一周项目在 OpenAI 和 Claude 相关兼容上也补了不少细节。

OpenAI 这边，v1.0.27 新增了 gpt-5.5 的全链路支持。它不是只在前端下拉框里加一个名字，而是补齐了默认模型暴露、OAuth / Codex 归一化、动态 / 静态计费兜底、兼容层 prompt_cache_key 自动注入，以及前端白名单和常用映射。这个“全链路”很关键，因为模型支持如果只补一半，就很容易出现后台能选、网关不能算，或者测试能过、真实请求失败的情况。

这一周还修了 OpenAI API Key 自定义 base_url 的 Responses 端点拼接策略。官方 api.openai.com 根地址继续走 /v1/responses，第三方兼容上游在未显式填写 /v1 时，则按字面 base_url + /responses 组装。这个修复解决的是一个非常典型的“后台测试通过但真实网关请求失败”的坑：测试链路和真实链路如果 URL 构造不一致，管理员会被假阳性结果骗到。

另外，OpenAI ctx_pool 模式在前端也被恢复为完整的 off / ctx_pool / passthrough 三态选项，并补了回归测试。Claude 侧则补齐了 Messages output_config.effort=xhigh 的识别与归一化，前端展示也统一成 XHigh。

这些看起来都是小修小补，但 API 网关的稳定性就是由这些细节决定的。你支持的不是一个模型名字，而是一整条从账号配置、请求解析、调度、计费、记录、前端展示到回归测试的链路。

法律文档、汇率文档和管理员教程也在补齐

这一周的另一个明显趋势，是文档开始跟着产品能力一起长。

项目新增了服务条款与隐私政策公开页面。管理员可以在“系统设置 - 用户默认值”里维护两份 Markdown 文档，站点自动生成 /legal/terms 和 /legal/privacy。默认首页页脚也会在配置了内容后自动展示入口。对于一个准备对外售卖 API 套餐的系统来说，这不是装饰，而是基本设施。

汇率系统也补了很多说明，包括人民币余额、美元 usage、订阅套餐和汇率波动之间的关系，默认汇率缓存 TTL 从 600 秒调整到 86400 秒，并在后台系统设置里提供入口。这里的取向很明确：汇率策略不是用来“坑用户”的，而是为了让平台在汇率波动下保持长期运营稳定。

另外还有 docs/关键模型参数设置.md、docs/管理员参数设置最佳实践.md 等文档，开始把账号管理、分组管理、OpenAI /v1/messages 调度、错误处理参数、池模式、自定义错误码、临时不可调度等内容讲清楚。一个项目如果只是代码能跑，维护者自己还能靠记忆撑一段时间；但一旦要交给管理员长期运营，就必须把这些知识沉淀成文档。

我的总体感受

如果只看版本号，从 v1.0.13 到 v1.0.27，好像只是修修补补。但如果把这一周的 commit 和 release 串起来看，会发现 huangwb8/sub2api 的方向已经非常清楚：它正在从一个 fork 出来的 AI API Gateway，变成一个围绕“支付可靠性、订阅经营、成本测算、模型兼容、运营文档”持续加固的产品化分支。

我最喜欢的一点是，这些改动大多不是为了炫技，而是围绕真实运营问题展开。支付配置别到用户付款时才炸，订单要能追溯，套餐要能公开展示，订阅要能补差价升级，闲时计费要能进入真实结算，盈利面板要尽量接近真实成本，模型兼容要从前端到后端走完整链路。

这也是我最近越来越喜欢的开发状态：不是闭门造车幻想一个宏大系统，而是让产品在真实问题里一点点长出来。每一个看似琐碎的修复，背后都对应一个用户会遇到、管理员会头疼、平台会亏钱或会失信的具体场景。把这些场景一个个补上，项目才会从“能部署”变成“能经营”。

项目 GitHub 地址：

https://github.com/huangwb8/sub2api