背景

我用 New API 搭了个中转站（api1.lblb.eu），又给它套了个 Android App。App 里想要两个功能：每日签到领额度、余额显示。听起来很简单，对吧？结果折腾了一整天，踩了五个坑。

坑一：New API 根本没有签到 API

我一开始想当然地调 POST /api/user/sign_in，返回 404 Invalid URL。去翻 QuantumNous/new-api 的源码，router/api-router.go 里根本没有这个路由——管理后台的"签到开关"只控制网页上的签到按钮，没有对外提供 HTTP 接口。

余额接口 GET /api/user/self 倒是存在，但它用的是 UserAuth 中间件（session cookie），拿 API Key（sk- 开头）去调直接失败。两套鉴权体系不互通。

坑二：SSH 连不上，只能曲线救国

想直接改 New API 源码加接口，结果服务器 SSH 22 端口被我这边的网络代理墙了。于是换思路：不动 New API 本体，写个独立的 Python 小服务挂在旁边，直接读它的 SQLite 数据库：

• tokens 表：API Key → user_id
• users 表：quota、used_quota
• 自己实现签到和余额逻辑

纯标准库，一个文件，Nginx 反代一下就能用。

坑三：数据库里的 Key 没有 sk- 前缀

服务跑起来了，调余额返回"API Key 无效"。查 middleware/auth.go 源码才发现：

key = strings.TrimPrefix(key, "sk-")

New API 入库时就把 sk- 前缀去掉了。修复：查询前先 strip 前缀。

坑四：SQLite WAL 模式读到过期数据

修完前缀，能查到用户了，但余额和网站对不上（差 7.87）。网站 API 返回 quota: 854907873，我的服务算出来却是另一个数。

原因是 New API 用了 WAL 模式，数据大多在 -wal 文件里（576K），主库文件才 26K。我的 Python 进程读到了过期快照。修复：每次读之前执行 PRAGMA wal_checkpoint(TRUNCATE)，强制把 WAL 刷入主库。

坑五：余额公式搞错了

WAL 修完，数字还是对不上。网站显示 1709.82，我算出来 1701.95。

掐指一算：854907873 / 500000 = 1709.815746 ≈ 1709.82，和网站完全一致。也就是说 New API 的 quota 字段本身就是剩余额度（消耗时直接扣减），used_quota 只是累计统计，不用减。我之前用的 (quota - used_quota) / 500000 是错的。

坑六：自建签到表和网站不同步

一开始我自建了张 app_checkin 表记录签到，结果网站签到了 App 不知道，App 签到了网站不认。翻 model/checkin.go 发现 New API 原生签到用的是 checkins 表（user_id、checkin_date、quota_awarded）。改成读写同一张表，两边终于同步了。

最终形态

• 服务端：100 多行 Python，直读 SQLite，Nginx 反代到 api1.lblb.eu/app/ 下
• 签到：随机奖励 1~10 元，写入原生 checkins 表，和网站完全同步
• 余额：quota / 500000，和网站分毫不差
• App：v1.5，签到、余额、聊天、历史记录全通

总结

New API 是个好项目，但它的 /api/* 管理接口是给网页控制台用的，不是给第三方调用的。想在外面接签到、余额，要么改它源码（Go），要么像我这样直读数据库（适合 SQLite 部署）。MySQL 部署的话，思路一样，换个驱动就行。

最大的教训：别猜接口，先看源码。五个坑里有三个是看源码 5 分钟就能避开的。