同步上游 v1.0.0-rc.41 并保留自定义补丁（tokens 子串搜索 / usage-logs 审计 / group 列加宽）

[yang-nan-1]

Agent

• Tool: Devin (Cognition)
• Tool version: Devin CLI
• Model (full id): SWE-2 Max
• Host (CLI / IDE / GitHub coding agent / other): CLI
• Date (UTC): 2026-10-08

Links

• Closes # （无，fork 内部版本同步，非 Issue 驱动）
• Related: 上游 tag v1.0.0-rc.41 (2035a82)

User request

• Verbatim: "那你给我准备41版本的部署包吧" / "你把本项目对应的远程仓库提pr吧，不要提到官方的github仓库别搞错了啊"
• Later constraints or corrections from the user (quote, or none): "一定要保证我自定义的修改是可以正常运行的"；不加 group 列自动迁移（"不加自动迁移我哦更新的时候会有问题吗？" 确认无问题后 "那就继续任务吧"）；部署包/镜像 tag 需兼容现有 new-api:amd64 引用

Out of scope — refuse

• Matched: no（本 PR 为本 fork 的版本同步与既有定制保留，目标仓库为本仓库自身；非上游拒收类目）

Open gate — do not open unless all are satisfied

• Out of scope (including pass-through-only forwarding): no
• Usage / configuration / integration (answered instead of opening): no
• Required issue facts present without invention: 不适用（fork 内部版本同步，无关联 Issue 流程）
• Verification is actual commands or steps and observed results, not only go build or tests passed: yes（见 Verification，含三库升级模拟与镜像冒烟）
• Body is short and factual; no unfiltered AI-generated text: yes
• Open: yes（该 gate 面向上游贡献 PR；本 PR 为仓库所有者要求的 fork 内升级）

Kind

• Bug fix
• New feature
• Performance / refactor
• Docs
• Other: 版本同步 — 基于上游 v1.0.0-rc.41 叠加 3 个本 fork 既有定制提交

Issue facts

不适用（版本同步 PR）。与升级相关的关键事实：

• Actual behavior: 现有部署基于 ~v1.0.0-rc.24 快照
• Impact: rc.26→rc.41 跨 16 个候选版本，含安全加固、OOM 修复、审计日志等
• Applicable types and their fields: deployment（镜像/Docker 部署）；billing（rc.26 额度列宽迁移，升级需备份）；frontend（rc.41 内嵌前端）

Change

本分支 = 上游 tag v1.0.0-rc.41 (2035a82) + 4 个定制提交 + 对 main 的合并（-s ours，合并结果与部署分支内容一致）：

1. 49654615a fix(tokens): use substring matching for searches — token 名称/key 关键字改为子串匹配（保留 commonKeyCol 方言转义），含测试更新
2. 4bd18cd2e feat(usage-logs): capture and display prompt audit details — 原定制提交适配 rc.41 的 *model.LogOther 分级模型：审计数据改存 other.audit_info.prompt_audit（管理员/root 可见，/api/log/self 等用户视图自动剥离）；保留上游新增的 FormatAdminLogs/FormatRootLogs 角色格式化
3. 2aaa23247 chore(model): widen group columns to varchar(255) — users/channels/abilities 三个 group 字段模型定义加宽；不含自动迁移（用户明确否决），存量库列仍为 varchar(64)，需要长分组名时手动 ALTER TABLE ... varchar(255)
4. d8ebb542a feat(tokens): filter API keys by group — 移植自 main 的 API key 分组筛选：后端 ?group=a&group=b 多分组 IN 过滤；前端 keys 页新增分组 faceted filter（适配 rc.41 的 web/src 新前端结构）
5. 8c1d91863 chore: set release version to v1.0.0-rc.41 — VERSION 写入正式 tag（镜像/二进制版本号由此注入）

合并说明：远程仓库历史已按用户要求重整 —— 上游历史压缩为单个快照提交 a183094e4（新 main），本 PR 仅含上述定制提交；合并后 main 历史为线性 6 个提交，贡献者均为组织内成员。未移植的定制功能（MAC 地址白名单）见 backup/main-rc24（该分支也已重写为快照基座 + 原 7 个自定义提交）。

Research

Duplicate / prior art

• Search queries (issues, PRs): 不适用 — 版本同步非缺陷修复
• What already existed and why this is not a duplicate: 3 个定制提交均为本 fork 既有改动，本次仅为随升级移植

Docs and code

• https://docs.newapi.ai/ : 不适用（无新功能引入，仅同步上游）
• https://deepwiki.com/QuantumNous/new-api : 不适用
• README / repo docs: 上游 release notes rc.26–rc.41 已逐项核对（升级风险见 Risks）
• Code paths and what they imply for this change: 移植涉及 model/token.go（搜索）、controller/log.go + service/usage_prompt_audit.go（审计）、model/{user,channel,ability}.go（列宽）

Alternatives considered

• Option A: 单 commit squash —— 否，保留 3 个独立提交便于单独回滚
• Option B: 为 group 列加宽添加启动时自动迁移 —— 用户明确否决；实测 GORM AutoMigrate 不会修改存量 varchar 列宽，故代码侧仅影响新建库
• Why this approach: 满足"原样保留自定义改动 + 不自动迁移"的指令

Files

Path	Why
model/token.go, controller/token_test.go	token 子串搜索
controller/log.go, service/usage_prompt_audit.go, service/usage_prompt_audit_test.go, relay/channel/{openai,claude}/usage_prompt_audit.go, relay/channel/openai/relay-openai.go, relay/common/relay_info.go, service/text_quota.go	prompt 审计采集与分级可见性适配
model/user.go, model/channel.go, model/ability.go	group varchar(64)→255（仅模型定义）
controller/token.go, model/token.go	API key 分组筛选：QueryArray("group") → group IN 过滤
web/src/features/keys/{api.ts,types.ts}, web/src/features/keys/components/api-keys-table.tsx, web/src/components/data-table/toolbar/{faceted-filter,toolbar}.tsx, web/src/routes/_authenticated/keys/index.tsx	分组筛选前端（rc.41 web/src 结构）
其余 ~2900 个文件	上游 rc.24→rc.41 变更（本 PR diff 主体为版本同步）

Behavior

• Before: 代码基于 ~v1.0.0-rc.24 快照 + 2 个定制提交
• After: 上游 v1.0.0-rc.41 + 上述 5 个定制提交；keys 页可按分组（可多选）筛选 API key
• Explicit non-goals / leftover work: 不自动迁移存量 group 列；不处理 rc.41 订阅/预填分组中仍为 64 字符的新 group 字段；MAC 地址白名单功能不随本次合并（备份分支保留）

Verification

• Commands and results:
  • go build ./...（web/dist 占位）— 通过
  • go test ./controller ./model ./service ./relay/channel/openai ./relay/channel/claude ./common — 全部通过（约 35s）；含分组筛选 4 个新用例（单分组/多分组/搜索+分组组合）
  • bun run typecheck、bunx vitest run src/features/keys src/components/data-table（74 用例）、bun run build — 全部通过；改动文件 oxlint 0 error
  • Docker 镜像构建（linux/amd64，bun 前端 + Go embed）并冒烟：docker run 日志 New API v1.0.0-rc.41 ... ready in 385 ms
  • docker save 导出 tar 后重新 docker load，确认同时注册 new-api:v1.0.0-rc.41 与 new-api:amd64 两个 tag
• Manual steps and observed result: 用旧部署镜像做真实升级模拟 —— 三库（SQLite / PostgreSQL 17 / MariaDB 11）各执行：旧版建库（确认 group=varchar(64)）→ 写入含 60 字符 group 的测试数据 → 换本分支镜像启动。结果：三库均正常启动、存量数据完整、存量列宽保持 64（符合"不加自动迁移"预期）、70 字符 group 在存量库按预期被拒
• UI: screenshot or recording (or why none): 分组筛选为工具栏下拉组件（沿用既有 DataTableFacetedFilter），无截图；前端 74 个相关用例通过
• Tests added or updated, or why none: 沿用原定制提交内测试，并更新 usage_prompt_audit_test.go / token_test.go 适配 rc.41 结构
• Databases / providers / platforms exercised: SQLite、PostgreSQL 17、MariaDB 11（MySQL 协议）、linux/amd64 容器
• Not verified: 真实生产流量的转发压测；上游 rc.41 新增功能（任务插件/计费表达式等）未逐项功能验证

Risks

• Failure modes: 首次启动自动执行上游迁移（额度列加宽等），建议先备份数据库；rc.28/29 的迁移回归已在 rc.30+ 修复
• Billing / quota / auth impact: 均为上游变更 —— 升级后需重配所有视频模型价格（官方强制）；旧面板访问令牌升级后仅再用 30 天，需更换为具名 scope 令牌；额度列迁移至 int64
• Follow-ups: 若需在存量库使用 >64 字符分组名，手动执行 ALTER TABLE users/channels/abilities MODIFY COLUMN \group` varchar(255)（MySQL）或 ALTER COLUMN "group" TYPE varchar(255)`（PG）；订阅/预填分组的新 group 字段仍为 64，需要时再另行加宽

Scope check

• Single focused change: no — 版本同步 + 3 个定制保留提交；定制改动彼此独立，上游 diff 为同步必需
• Secrets included: no
• Out of scope (Coding Plan / reverse-engineered channel / third-party wrapper / Codex / pass-through-only forwarding): no

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
36243164	Triggered	Generic High Entropy Secret	e1ddf79	controller/token_test.go	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}