[上游跟踪 #6510] 统一渠道权重语义（缓存原值 / DB +10）

[faithleysath]

上游来源

• Issue：[Bug] 内存缓存与数据库路径的渠道权重比例不一致（weight vs weight+10） QuantumNous/new-api#6510
• 标题：[Bug] 内存缓存与数据库路径的渠道权重比例不一致（weight vs weight+10）
• 上游基线：main@afe16c64cd73853da1eda3bf236f15d69637b4bf
• 记录时状态：Open

问题摘要

官方当前存在两套渠道权重语义：

• Redis / 内存缓存路径直接按原始 weight 比例选择。
• 非缓存数据库路径按 weight + 10 比例选择。

官方 FAQ 明确承诺同优先级渠道按填写的权重比例分配，例如 2:1 应得到 2:1。隐藏的 +10 会使 2:1 变成 12:11，并使部分显式权重为 0 的渠道继续获得流量。

本 fork 的目标语义应为：

sum(weight) > 0：按 weight / sum(weight) 分配
所有 weight == 0：候选渠道等量随机
部分为 0、部分 > 0：weight == 0 的渠道不接收新流量

当前本地边界

• 当前生产配置 Redis，因此实际走原始权重的内存缓存路径。
• 现有部分渠道权重曾按旧 weight + 10 语义设计，当前可见配置与原目标比例不完全一致。
• 用户已明确要求：本跟踪阶段暂不修改任何生产渠道权重、Redis、亲和、优先级、分组或售价配置。
• 生产权重迁移属于后续独立变更，必须重新回读渠道状态、保存脱敏快照、明确变更表并获得单独授权。

建议实现

• 将 DB 路径改为与缓存路径一致的原始权重语义。
• 抽取两条路径共用的加权选择 helper，避免再次漂移。
• 明确并测试全零与部分零权重行为。
• 如上游先修复，优先跟随上游实现；如长期未处理，再在本 fork 独立修复并向上游提交 PR。
• UI tooltip 或文档补充权重 0 的行为，但不引入隐藏偏移量。

验收条件

• 上游 issue 完成 triage，并在此同步结论、关联 PR 或关闭原因
• 缓存和非缓存路径对相同候选集使用完全相同的有效权重
• 2:1 配置在两条路径下都保持 2:1
• 全零权重在两条路径下都等量随机
• 1:0 配置在两条路径下都不把新流量分给权重 0 渠道
• 单元测试不依赖大样本随机统计，优先验证确定性的有效权重/区间构造
• 引入上游修复或本地修复后通过相关 Go 测试
• 生产权重调整另开变更步骤并单独授权；本 issue 关闭前不默认执行生产配置迁移

跟踪策略

• 关注 [Bug] 内存缓存与数据库路径的渠道权重比例不一致（weight vs weight+10） QuantumNous/new-api#6510 的维护者反馈
• 关联上游修复 PR 和首次包含修复的 release/tag
• 检查上游是否同时修改 DB、缓存、文档和测试
• 上游合并后评估与 nexus 分支冲突及回归范围
• 未获生产变更授权前保持现网配置不变

[faithleysath]

2026-07-29 上游复核

• 上游 Issue #6510 仍为 Open，除模板机器人外没有 maintainer 技术回复，未发现关联修复 PR。
• 最新 upstream/main@c27d1ef651c6 仍保留两套语义：DB 路径 model/ability.go 累加/扣减 weight + 10；内存缓存路径按原始权重比例，仅对全零权重做等量回退。

因此缺陷仍然存在，issue 中的目标语义与生产配置冻结边界不变。本次只更新事实，没有修改任何生产权重、Redis、亲和、优先级、分组或售价配置。

[faithleysath]

2026-07-30 Nexus 修复与上游 PR

已在最新上游基线 main@66ee6b8f 上完成通用修复，并同步落入 Nexus：

• Nexus commit：de51cc26
• 上游 PR：fix(channel): unify weighted selection across cache modes QuantumNous/new-api#6554
• 上游 PR commit：fd8beaf1

实现结果：

• DB 与内存缓存路径共用同一个半开区间加权选择 helper。
• 总权重大于 0 时严格使用原始权重；全零时等量回退；部分为零时零权重渠道没有选择区间。
• 同时修复 DB 路径 rand.Intn(total) 配合 <= 0 导致首项多一个随机票、末项少一个随机票的边界偏移。
• 使用确定性区间测试覆盖 2:1、全零和部分零，并用集成测试确认 1:0 在缓存开关两条路径下都只选择正权重渠道。

验证已通过：

• go test ./model
• PR 分支 go test -race ./model
• go test ./...
• 前端生产构建
• 上游 PR pr-quality

本次没有修改任何生产渠道权重、Redis、亲和、优先级、分组或售价配置。#34 继续保持 Open，等待上游 review/merge 以及首次包含该修复的 release/tag；生产权重迁移仍是独立授权步骤。

[faithleysath]

2026-07-30 生产部署

Nexus 修复已随 v1.0.0-rc.22-nexus.3 部署到 HK 生产：

• Source：de51cc26
• Manifest：sha256:cf150c367546e6a2f188dcd3f8fc9c002731fd34ed3c01eb33a867e6bd69f157
• Image workflow：https://github.com/NexusAgentX/new-api/actions/runs/30553854356
• Deploy workflow：https://github.com/NexusAgentX/new-api/actions/runs/30554343682

部署前四件套备份 20260730T150315Z 与 Compose 回滚副本 20260730T150323Z 已验证，备份已同步到 Tower 并逐文件核对哈希。部署后六个生产容器均为 healthy，回环、直接源站和公开 /api/status 均返回 .3，受保护 /v1/models 与真实 Responses 请求均为 200。

本次没有修改任何生产渠道权重、Redis、亲和、优先级、分组或售价配置。生产仍启用 Redis/内存缓存，因此活跃路径在升级前后都按原始权重选择；变化只是在 DB fallback 现在使用同一语义。#34 继续保持 Open，等待上游 PR QuantumNous#6554 的 review/merge 和首次包含修复的 release/tag。

[faithleysath]

2026-07-30 生产等价权重迁移

在 .3 部署之后，已按单独授权将历史 weight + 10 设计迁移为统一选择器可直接使用的原始权重：

Channel ID	Before	After
1	15	25
4	5	15
8	30	40
17	25	35
18	4	14
19	15	25
22	5	15
23	10	20
27	20	30
28	8	18

本次只通过管理 API 发送最小 {id, weight} 更新。变更前后结构化快照确认唯一差异为上述 10 个权重；渠道状态、优先级、分组、模型、Redis、亲和和售价均未变化。ID 4/28 继续保持自动禁用，ID 18 继续保持手动禁用。

验收结果：

• 管理 API 与 PostgreSQL 直查一致。
• 当前启用的目标渠道 1/8/17/19/22/23/27 指定渠道测试 7/7 成功。
• 六个生产容器继续 healthy，restart count 均为 0，近期应用日志无新增严重错误。
• 变更前四件套备份 20260730T153444Z 已通过 gzip/tar 校验，并同步到 Tower 后逐文件核对哈希。

因此当前缓存与 DB fallback 都按同一原始权重实现此前的 weight + 10 设计比例。Issue 仍保持 Open，继续等待上游 PR QuantumNous#6554 的 review/merge 与首次包含修复的 release/tag。