New API

最开始是从One API迁移过来的，说点真实感受。 先说为什么换。One API用了挺久，功能够了，但界面确实老了点，而且有些新版模型兼容起来要自己改。New API是基于One API的二次开发，Star量到2026年4月已经接近2.5万，社区也成型了。换过去之后第一感觉是UI确实清爽不少，操作顺手。 最实用的改进是渠道加权随机调度。之前One API那边负载均衡比较简单，现在支持按优先级和权重分配请求，同一个模型配多个Key自动轮询，高峰期限流的情况少了很多。缓存计费也省了一笔钱，命中缓存的时候按比例收费，大模型的昂贵调用降了不少。还有个细节是支持按次数计费而不是单纯按token——某些固定调用量的场景下，这个设计更透明。 对团队来说，New API比较吸引人的地方是运营体系做得比One API深。支持在线充值，集成易支付，用户自己扫码付款就能用，不用手动发Key。令牌分组和模型限制很细，不同团队分不同的组、设不同的限流策略，用完额度自动熔断，不怕被人刷爆。数据看板也够用，调用量、消耗分布、用户活跃情况一眼能看清楚，不用再自己去拼Excel。群里见过有人拿来按部门分配，研发组一万美金、运营组五千美金，用完自动熔断，不超支。多语言支持中英法日，界面翻来翻去不用专门切系统语言，挺方便的。 多模态方面比One API多接了Midjourney Proxy和Suno，虽然我个人用得不多，但见过有人用它在团队内做统一的中转入口，不需要每个人都去折腾MJ订阅，接入的时候统一走/v1/接口就行。这部分在社区里呼声挺高的。 不过功能多了，坑也多。 稳定性的问题比较频繁。它本身是基于One API的二开，改动大，不像原版那么“稳如老狗”。更新激进是个双刃剑——修bug是修得飞快，但偶尔会引入新问题。社区里有人说主打“个人学习使用，不保证稳定性”，实际体验下来确实感受到了，半夜起来看日志发现请求报错，仔细一排查是某个新版引入的小问题。还有个大坑，Azure渠道的模型重定向功能有异常，本来应该做模型名称透明转换，实际直接把原始请求转发过去导致报错。踩过之后只好手动挡处理。 安全漏洞方面也有隐忧。前期0.9.0.5之前的版本存在SSRF漏洞，攻击者可以利用构造重定向绕过去打内网。后来虽然有补丁增强了SSRF防护，但社区里曝出过更严重的问题——支付漏洞，默认如果空着Stripe密钥不配置，支付回调可能被伪造任意金额充值。虽然文档有强调配置密钥，但作为开发者难免提心吊胆，毕竟业务里的数据直接挂在这上面。现在每次升级新版之前都要在测试环境先跑一遍，已经成了常规流程了。 社区里另一个人吐槽过的坑是模型名称超长直接导致整个系统崩溃循环，v0.4.5.2版本里添加超长模型名会触发数据库写入失败，然后缓存初始化panic，重启都救不回来。虽然官方很快修了，但崩溃过之后你敢不备份？ 再说部署和维护。Docker Compose一键跑起来没毛病，但是后续的权限配置、模型映射、令牌管理都得自己慢慢磨，不是点完就完事的那种。如果你是小团队，需要一个人从零摸着弄，还得准备文档给队友看，否则换个人就全抓瞎。特别是RBAC那套东西，配好的时候很爽，但如果没规划好分组策略，后面调整起来要改不少令牌，变更成本不小。 兼容性方面，它对OpenAI Realtime API和Claude Messages格式的支持还算到位，但遇到了几次新模型ID格式变了导致渠道报错的情况，得自己去社区群里问或者翻GitHub issue才知道要改哪里。 总结一下。如果你是个人开发者，手上渠道不多、主要是自己用，换New API可能意义不大——One API够用了。但如果你运营一个小平台或者团队里有好几个项目共用API资源，New API的运营能力是真的打中痛点，统一计费、分组配额、数据看板这些，能省下不少管理时间。 但生产环境用，心要细。备份要做好，升级前要先在测试环境验证，支付配置一定要走正规签名，别偷懒。最好配上监控和告警，万一网关挂了，手上要有备用方案——毕竟模型网关挂了，全线就跟着挂了。