 yml2213
|
f101414f5e
|
feat(accounts): 新增登录异常分型统计、多选/全量导出、筛选记忆及页面组件模块化拆分
- 新增登录失败异常分型统计：支持「必须绑定手机号」、「极验滑块」、「凭证错误」、「邮箱取码失败」、「邮箱配额已满」、「网络异常」分型识别、生命周期联动（待人工）与一键筛选；
- 新增账号名单与明细导出功能：支持勾选多选或按当前筛选条件全选，可导出纯用户名名单 (TXT) 或 UTF-8 BOM 结构化明细报表 (CSV)，并支持一键复制到剪贴板；
- 优化筛选条件记忆机制：支持页面切换/返回后自动保留所有筛选与排序状态，新增顶部「重置全部筛选」快捷按钮；
- 模块化拆分 AccountsPage：将 2100+ 行的大文件拆解至 pages/accounts/ 子目录（包含状态卡片、筛选面板、工具栏、操作弹窗与表格构建器），提升可维护性；
- 验证方式：新增 5 个后端自动化单测 (test_account_failure_and_export.py)，全量 694 个测试用例通过，前端 TypeScript 编译与 pre-commit 代码规范检查全部通过。
|
2026-10-07 17:23:39 +08:00 |
|
|
yml2213
|
44b762ea8c
|
fix(overview): 锁定核心高价值套装并修复未查询空值误判
- 高价值套装精确匹配「套装-兔兔白日梦」与「套装-狂战萌兔」，排除头盔/背包/手榴弹散件干扰
- 增加 is_suit_queried_expr，未查询或 NULL 账号严禁误判为双套均可兑换
- 修复前后端序列化空值保持，完善列表与详情页准入状态和判定依据展示
- 新增头盔排除与 NULL 统计防错回归单测，全量通过 689 个用例
|
2026-10-07 15:27:30 +08:00 |
|
|
yml2213
|
5405d4b1d1
|
fix(overview): 纠正高价值套装以商城 status==1 为最高准入裁判
- 根因：斗鱼官方商城接口 status==1 代表「已达兑换上限」，历史代码误以为商品列表全为全局字段而单纯依赖常被官方清空的 exchange_records，导致已兑换账号被误判为可兑换
- 修复：extract_high_value_goods 结合商城完整列表 status==1 现场判定已兑换，exchange_records 作为历史展示与兜底
- 前端：优化工作台与一键查询展示，明确展示「已达上限 N 个: ...」与「未达上限」，消除反向歧义
- 文档：沉淀坑 #9 到 AGENTS.md，并更正设计-账号一键查询.md
|
2026-10-07 14:51:51 +08:00 |
|
|
yml2213andCursor
|
f2157f67f7
|
feat(accounts): 账号列表按列排序，默认把还能换套装的排到前面
分页在服务端，点表头按全库排，不能只排当前这一页。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-10-05 18:50:43 +08:00 |
|
|
yml2213andCursor
|
998998c390
|
feat(automation): 巡检和重登优先保住高价值账号的 CK
价值按套装和积分现算，不看标签。第 1、2 档 6 小时巡检一次，并先占重登名额。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-10-05 17:51:04 +08:00 |
|
|
yml2213
|
27e9107e38
|
fix(accounts): 修复鱼翅筛选参数类型为浮点数并优化错误提示
1. 后端将 min_gold 与 max_gold 参数及 Schema 类型从 int 改为 float | None，支持小数鱼翅（如 >0 快捷筛选的 0.01）；
2. 修复前端 axios 拦截器在遇到 FastAPI 422 验证错误时未展开 detail 导致弹出 [object Object] 的问题；
3. 单元测试补充验证浮点数鱼翅过滤场景。
|
2026-10-05 11:36:46 +08:00 |
|
|
yml2213
|
512ea3db06
|
feat(accounts): 增加高价值资产一键筛选与高级自定义筛选功能
1. 后端新增高价值套装状态筛选（双套均可换/可换白日梦/可换萌兔/已拥有/高价值待救/未查资料），兼容 MySQL 原生 JSON 与 SQLite unicode 转义存储；
2. 后端新增多维资产与状态区间筛选（积分范围、鱼翅范围、宝典开通、电竞开通、角色绑定状态），并支持与批量打标签/删除联动；
3. 统计接口 accounts_summary 新增 high_value 聚合数据，毫秒级返回各类高价值资产数量；
4. 前端账号管理页面新增「高价值一键筛选」胶囊区（带数量徽标与激活状态，即点即滤）；
5. 前端新增可折叠「高级自定义筛选」面板，支持套装状态下拉、积分快捷区间（≥300、≥600）、鱼翅快捷区间（>0、≥6）、宝典与角色绑定状态多条件组合；
6. 补充 6 个高价值筛选与资产区间单元测试，全量用例通过。
|
2026-10-05 11:23:48 +08:00 |
|
|
yml2213
|
8f231e6edf
|
fix(binding): 角色绑定只看 is_bound_role —— 「是否开通」与「是否绑定角色」是两件事
用户明确指出：**精英/电竞是否开通，和是否绑定角色没关系**。
## 我确实混了（虽然这次没触发）
`derive_from_bind_info` 里有个兜底：
if bound_role is True or bound_act is True: return BOUND
`role_bind_status` 这一列问的是「**角色**绑没绑」，而 `is_bound_act` 是
「**活动**维度」的标志 —— 拿它兜底就是把两件事混起来。
一旦有账号 `is_bound_act=True` 而角色未绑，就会报出"角色已绑定"的**错结论**。
## 生产数据证实了用户的说法
查已查询的 196 个账号：
电竞 opened=False 且 bind=bound → **187 个**
也就是**187 个账号绑了角色、但电竞手册压根没开通** —— 两者完全独立。
同时数据也证明 `is_bound_role` 本身就够用（不需要那个兜底）：
判为 bound 的里面：精英 183 个全都有角色名（0 个没有）
电竞 187 个全都有角色名（0 个没有）
## 改法
去掉 `is_bound_act` 的参与，**只看 `is_bound_role`**：
is_bound_role 真 → bound
is_bound_role 假 → unbound
缺失 → None（保持 unknown，别把"没查到"写成"没绑定"）
语义上不再有"把活动当角色"的路径。
## 测试
把两条**编码了旧行为**的用例改掉，并补一条钉住领域事实：
- 只有 `is_bound_act` 没有 `is_bound_role` → **None**（推不出角色结论）
- `{"is_bound_role": True, "manual_type": 0, "expire_time": "0"}` → **bound**
（绑了角色+没开通，两者独立，不该因为"没开通"而变成别的）
## 验证（本地）
TZ=Asia/Shanghai **620 passed / 6 skipped**；ruff 全绿。
|
2026-10-04 21:01:42 +08:00 |
|
|
yml2213
|
ccd05cba9c
|
feat(overview): 关掉和平小店查询 + 修电竞「已开通」不落库
## ① 和平小店总开关（默认关）
小店目前是**关闭状态**，但不跳过的话一键查询仍会对每个账号发小店请求，
结果 100% 失败 —— 实测 200 个账号里 `exchange_records_peace` 失败 **195 次（100%）**：
Livelink登录态校验失败
100% 意味着不是账号问题。这既淹掉真错误、又让人以为出故障。
新增 `douyu_config.peace_enabled`（迁移 `0050`，**默认 False**）。
关着时**完全跳过**小店的所有请求（绑定 + 兑换记录），并且**不记 errors** ——
「配置成关的」和「查失败」是两回事，混在一起会让 errors 失去意义。
将来小店恢复，在后台打开这个开关即可；打开后小店失败仍会**如实暴露**
（有用例专门钉住这一点，别把开关当成遮羞布）。
## ② 修：电竞手册「已开通」不会被一键查询更新
用户问"电竞到期时间为什么拿不到"，查下去发现**两层**：
**第一层不是 bug**：那 200 个账号 `esports_opened` 全是 0（没开通电竞手册），
所以 `expireTime="0"`、没有到期时间可存。注意
**"电竞已绑定角色"≠"电竞手册已开通"**。实测 `opened_but_no_expire = 0`，没有异常。
**第二层是真 bug（不对称）**：
_refresh_elite_handbook → 写 account.elite_opened ✅
_refresh_esports_handbook → 不写 account.esports_opened ❌
`esports_opened` 只在"开通"任务里被设置，所以**详情页电竞的「已开通/未开通」
根本不会被一键查询更新**。已改成与精英对称（口径同 create_esports_qr：
`manual_type >= 1` 即已开通）。
## 测试（+2）
- 小店关着时：**不发**小店请求、**不查**小店绑定、**不记** peace 相关的 errors，
且结果里标明 `peace_skipped`
- 小店打开时：失败**仍然如实暴露**（反向用例，防止开关变成遮羞布）
## 验证（本地）
TZ=Asia/Shanghai **620 passed / 6 skipped**；ruff 全绿。
|
2026-10-04 20:59:17 +08:00 |
|
|
yml2213
|
631e33a4f6
|
fix(events): 撞唯一键是幂等命中，不该刷 WARNING + dump 整条 SQL
## 现象（用户从日志里发现的）
WARNING | 写入账号事件失败（account=60 exchange）：
(1062, "Duplicate entry 'official_exchange:elite:60:20260120QYOOB_bag360:...'")
[SQL: INSERT INTO account_events (...) VALUES (...)]
[parameters: {...}]
## 分析：**不是 bug，是幂等机制在工作，但日志级别错了**
`emit()` 刻意**不做预检查**，直接 INSERT，靠 `source_ref` 的唯一索引去重；
撞了就 catch（SAVEPOINT 只回滚这一条）。所以：
- **数据是对的** —— 重复的被挡住，`exchange_events_added` 只计新写入的
- **日志是错的** —— 撞唯一键被当成异常打 WARNING，还把整条 SQL + 参数 dump 出来
而"撞唯一键"在这里是**预期内的正常情况**：一键查询会把斗鱼官方兑换记录补成事件，
同一个账号会被反复查询 —— 第二次开始每条记录都会撞。一次查询能刷几十屏，
既淹掉真日志、又让人以为出事了（用户就是因此来问的）。
## 修法
区分「唯一键冲突」与「真错误」：
- 确认是 **1062**（并带 `Duplicate entry` 字样）→ 降为 **DEBUG**，一句话说明"已存在，跳过"
- 其它完整性错误（如非空约束 1048）→ **仍然是 WARNING**
刻意**不把 IntegrityError 整个静音** —— 那会把真问题一起藏起来。
新增 `_is_duplicate_entry()` 只在两种信号都对上时才降级。
## 测试（+3）
- 重复写入返回 False，且**不产生**任何 "写入账号事件失败" 的 WARNING
（用 loguru 的临时 sink 真的抓日志来断言，不是看代码）
- 重复写入不会写进第二条
- `_is_duplicate_entry` 只认 1062，1048（非空约束）仍然返回 False
|
2026-10-04 20:35:24 +08:00 |
|
|
yml2213
|
6b5271c983
|
feat(account): 一键查询补上「角色绑定状态」—— 以前从来没人查过，97% 显示"未知"
## 问题（用户："这个做了吗？我看好像都是未知"）
**只做了一半**：
- 列的拆分做了（S6）：三列存在、写入收敛到 set_bind_status、迁移映射与运行时对齐
- 但**没有任何一处真的去查绑定状态**（grep -c bind_info douyu_runner_overview.py = 0）
那三列的值从来不是查来的，而是 S6 迁移时从旧的垃圾场列 bind_status
**能推的推、推不出的留 unknown**。只把明确陈述了绑定事实的旧值映射过来
（bind_confirmed → bound、bind_qr_generated → pending、game_not_bound → unbound），
其余一律 unknown —— 因为旧列被"查限兑商品""送礼物"这类**无关动作**覆盖过，
从无关动作推绑定状态就是造假。当时留 unknown 是对的，但结果是：
真实生产分布（15182 个账号）
精英 unknown 14683 (96.7%) 电竞 14730 (97.0%) 小店 15045 (99.1%)
## 修法：真的去查，用唯一写入者写回
一键查询新增三个绑定查询（接口都已存在，活动别名走后台配置）：
bind_info / esports_bind_info / xpd_bind_info。
新增 derive_from_bind_info() 把返回推导成 4 态，**并做了实测校准**：
账号 列值(旧) is_bound_role 角色名 推导
51 unknown False (空) unbound
60 unknown True 唉清静的一生 bound
61 unknown True 柿子洋音 bound
62 unknown True FatalistIc bound
**4 个里 3 个其实已绑定，全被 unknown 盖住了。**
两个刻意的设计：
1. **推导不出来时返回 None，且不动原值** —— "没查到"和"没绑定"必须分开，
写 unbound 就是编造结论（小店未开通、返回里没有标志时实测就是这种情况）
2. **不产出 pending** —— 它描述"正在绑定/待确认"这种**进行中的动作**
（如刚生成过二维码），那是一次查询的副作用，不是查询能观测到的状态
3. need_bind_role **不是**"未绑定"的信号：实测**已绑定**的账号上它也是 1，
拿它当判据会把这 3 个已绑定的判成未绑
端到端实测（账号 51）：
查询前: 精英=unknown 电竞=unknown 小店=unknown
查询后: 精英=unbound 电竞=unbound 小店=unknown ← 推不出来，正确保持原值
## 显示：把"没查过"和"查了推不出"分开
三处都改了（用户要求）：全 unknown 时不再显示「精? 电? 店?」，
而是 **未查询**（点一键查询就有了）/ **未能判定**（斗鱼这次没给结论）。
## 验证（本地）
TZ=Asia/Shanghai **615 passed / 6 skipped**；ruff 全绿；前端 build 通过、lint 0 errors。
新增 9 条用例（含"need_bind_role 不是信号"的反向回归）。
|
2026-10-04 20:22:54 +08:00 |
|
|
yml2213
|
85a6186993
|
feat(account): 电竞手册到期时间落库与展示；迁移 0048 改名
## 背景（用户反馈）
「精英宝典和电竞手册已开通的话，应该增加时间展示，可以看到开通时间和过期时间」
- 精英宝典：开通时间来自事件；过期时间 `elite_expire_time` 本来就有
- 电竞手册：开通时间来自事件；**过期时间原来没有落库** ——
只在 `_refresh_esports_handbook` 的返回值里带着，界面上只能看到「已开通」
## 改动
- 新增 `accounts.esports_expire_time`（迁移 0049，与 `elite_expire_time` 对称），
刷新电竞手册时写回
- 详情页：**已开通才显示**「开通 x / 到期 x」两行小字；顺手删掉底部那段
重复的「开通时间」说明（已挪到每项旁边）
- 新增 `formatUnixSeconds()`：斗鱼的到期时间是**秒级时间戳**，
原 `formatTime()` 只收字符串；新函数对 `0`/空/负数一律显示 `-`
## 明确回答：历史开通记录**查不到**
实测官方兑换记录里**只有商品兑换、没有开通记录**（账号 61：精英 2 条都是套装）。
我们自己的 `elite_opened` / `esports_opened` 事件也只有上线后的。
所以历史上的开通时间拿不回来 —— 按用户说的「没有就算了」，
并把这点写进界面说明，别再让人去找。
## 测的时候抓出一个真 bug（又是 1970）
电竞到期时间的 `"0"`（斗鱼用它表示「没有到期时间」）被原样存成 `0`
→ 界面会显示 **1970/1/1**。已修（`0`/空 → `None`）并加回归用例 ——
这个坑在积分到期上踩过一次，这次差点重演。
## 迁移 0048 改名
`20261004_0048_overview_summary.py` → `20261004_0048_high_value_owned.py`：
上一轮把内容从「汇总」收敛成单一用途的 `high_value_owned`，文件名没跟着改。
revision id 不变、迁移状态不受影响；同时清了 `__pycache__`
（本仓库被过期 `.pyc` 咬过，症状是「改了没生效」）。
## 验证（本地）
`TZ=Asia/Shanghai` **608 passed / 6 skipped**；ruff 全绿；前端 build 通过、lint 0 errors。
|
2026-10-04 20:17:05 +08:00 |
|
|
yml2213
|
6865b916ba
|
test(account): 一键查询 / 官方兑换记录 / 生命周期用例
围绕这几轮改动补齐用例（本文件共 53 条）：
- **判定规则**：只看官方兑换记录；全局库存**永不**推出「该账号已拥有」
（回归用例 —— 正是第一版踩的坑）；字段缺失是 None（未知）而不是 False（没有）
- **失败隔离**：单项外部调用失败不影响其余，且如实写进 errors
- **只读性**：一键查询不发事件、不改生命周期状态
- **官方记录补成事件**：带**真实兑换时间**（不是"发现它的时刻"）、
幂等（重复查询不重复落）、无 commodityId 时跳过
- **排序回归**：「最近一次兑换」按事件时间，不是插入 id
- **时间归一化**：0 / "0" / 空 / 负数 → None（1970 那个 bug 的回归）
- **迁移安全**：不得在迁移里 commit(op.get_bind())；加列前必须有存在性检查
（扫代码时**跳过注释** —— 注释里正解释着"不要这样做"，第一版用例因此假红）
- **接口契约**：详情返回快照与查询时间、列表**不**带整份快照；
断言一律看 model_dump()（只看属性会假绿 —— AccountOut 有手写
@model_serializer，字段没列进去时属性有值、JSON 里没有）
另修两条**把 bug 当期望值**的既有用例：
1. 「最近一次兑换」原断言的是最后**插入**的那条（旧行为按 id 排），
改为真正最近的（按事件时间）；
2. 按用户名查找夹具不可靠（make_account("key") 每次建新账号、库里一直累积），
改为按 id 精确查找。
|
2026-10-04 20:04:11 +08:00 |
|
|
yml2213
|
aea05952af
|
refactor(account): 一键查询不该重复展示账号字段 —— 改成刷新它们，只留账号表里没有的
用户反馈：「一键查询也太重复了，直接更新账号信息不行吗？为啥很多都要再展示一次？
那建立账号信息表有啥用」——**说得对，是我设计错了**。
## 问题
面板把鱼翅 / 积分 / 钱包余额 / 精英宝典 / 电竞手册又原样列了一遍，
而这些账号表（`accounts`）本来就有对应列，账号详情也在显示同一批值 ——
同一屏出现两份，既冗余又让人分不清哪份是准的。
## 改法：查询 = 刷新，不是另开副本
| 内容 | 处理 |
| --- | --- |
| 鱼翅 / 积分 / 交易余额 / 开通状态 | 写回**账号表**（`_refresh_*` 本来就在写），由账号详情已有界面展示 —— **面板不再重复** |
| **积分到期时间** | 有 `accounts.points_expire_at` 列，但**查询漏了没写、界面也没显示** → 现在写回，并加到账号信息区展示 |
| **高价值套装是否已获得** | 账号表没有 → **只有这个该单独展示** |
| **官方兑换记录** | 账号表没有 → 单独展示 |
面板因此瘦身成只含「🎯 高价值套装」+「兑换记录」（+ 错误提示 + 查询时间），
标题也改成「高价值套装与兑换记录（一键查询）」，不再叫"账号信息"。
## 修了一个连带 bug
积分到期时间一直没被查询写回账号（只在快照里躺着），界面也没展示 ——
现在 `_parse_expire_at` 后写入 `accounts.points_expire_at`，
且斗鱼返回 `0` 时写 `None` 而不是 `0`（否则又显示 1970/1/1）。
## 测试（+3，共 41）
`TestOverviewRefreshesAccountFields`：资产/开通状态确实写回账号列、
**积分到期时间写回**、`willExpireTime="0"` 时清成 None 而非 0。
## 验证
`TZ=Asia/Shanghai` **593 passed / 6 skipped**；ruff 全绿；前端 build 通过、lint 0 errors。
|
2026-10-04 19:22:34 +08:00 |
|
|
yml2213
|
c2520613ca
|
fix(account): 修一键查询「一直循环」—— 快照字段加到了列表接口而不是详情接口
用户报：账号详情点「一键查询」会一直循环（Network 里刷一片 `overview` 请求）。
## 根因
上一轮我把 `overview_snapshot` / `overview_queried_at` 加到了**列表**接口
（锚点 `**bind_payload(acc),` 第一次出现的位置在列表构造器里），详情接口没有。
两层后果：
1. **详情不返回 `overview_queried_at`** → 前端 `marker !== before` 永远相等
→ 轮询到 120 秒超时。看起来就是"点一下一直转圈刷请求"。
2. **列表每个账号都带一整份 JSON 快照** → 15000 个账号的响应体积爆炸
（这个是我自己引入的回归，比第一个更隐蔽）。
## 修法
- 字段从**列表**移除、加到**详情**（列表刻意不返回，注释写明原因）
- 前端轮询**加自证**：第一次拿到响应时若没有标记字段，**立刻报错退出**，
而不是傻等 120 秒 —— 这类"字段没返回"的 bug 不该再以死循环的形式暴露
## ⚠️ 过程中我又踩了一个，被既有用例抓住
删那 4 行时**把 `**bind_payload(acc),` 一起删掉了**，导致列表不再返回绑定列
（`role_bind_status` 显示的是 Pydantic 默认值 `unknown`）。
`TestListViewKeyColumns::test_item_carries_key_columns` **立刻变红** ——
既有用例替我把这个真回归挡下来了。已恢复，并确认 diff 只剩预期的 3 行。
## 新增回归用例（+2，共 38）
`TestSnapshotExposedOnDetailOnly`：
- 详情**必须**返回快照与查询时间（不返回前端就会轮询到超时）
- 列表**不得**返回完整快照（每个账号一份 JSON，体积爆炸）
并做了**反向验证**：把"详情不返回字段"的 bug 注入回去 → 用例立刻红。
另外把 `TestListViewKeyColumns::_item` 按用户名查找改成按 id ——
`make_account("key")` 每次建新账号而库里一直累积，按用户名可能命中很早以前那个
（这次就让用例假红过一次）。
## 验证
`TZ=Asia/Shanghai` **590 passed / 6 skipped**；`TZ=UTC` 80 passed；
ruff 全绿；前端 build 通过、lint 0 errors。
|
2026-10-04 19:19:53 +08:00 |
|
|
yml2213
|
3866b49087
|
fix(account): 一键查询按反馈收敛 —— 只在账号管理展示、结果落账号、修 1970 显示
按用户反馈改了四处。
## ① 结果只在账号管理展示（不再出现在精英宝典/电竞手册页）
移除了工作台页的结果弹窗与导入。**类型集合保留**（三个工作台都有）——
因为账号页批量建任务要用 `handbook_scope` 过 `DOUYU_HANDBOOK_TASK_TYPES` 校验，
去掉会被「该任务不属于当前工作台」拦掉；去掉的只是**快捷操作按钮**。
## ② 不再每次弹出
原来任务跑完就自动弹面板，而且任务会被反复轮询到。现在整个弹窗机制去掉了：
结果落在账号上，打开账号就能看。
## ③ 结果写进账号（新增迁移 0047）
新增 `accounts.overview_snapshot`（JSON）+ `overview_queried_at`，覆盖式只留最新一份。
详情页直接读账号上的快照，不再轮询任务。
**为什么放账号而不是只留任务里**：任务会被保留策略清掉（长保留档 90 天），
而「这个账号现在什么情况」是**账号的信息**，不该依赖一条日志的寿命。
## ④ 修 1970/1/1 08:00:00（真 bug）
斗鱼用 `0` / `"0"` / 空串表示「没有这个时间」。原实现直接透传，
前端 `new Date(0)` → **1970/1/1 08:00:00** —— 运营会以为"到期时间是 1970 年"。
两端都修了：
- 后端新增 `_ts()`，把 `0`/`"0"`/空/负数 归成 `None`（积分到期、宝典到期、
电竞到期、商品活动时间四处都过一遍）
- 前端 `formatTime` 也把 `0`/负数显示成 `-`（上游再出错也不至于显示 1970）
## 测试（+14 条，共 36）
- `TestTimestampNormalisation`：`0`/`"0"`/空/负数 → `None`；真实时间戳透传
- `TestSnapshotIsWrittenToAccount`：快照与时间落到账号上、
**`willExpireTime="0"` 不能落库成 0**（1970 的回归用例）、覆盖式不追加
## 验证
`TZ=Asia/Shanghai` **588 passed / 6 skipped**；`TZ=UTC` 41 passed；
ruff 全绿；前端 build 通过、lint 0 errors。
|
2026-10-04 19:12:51 +08:00 |
|
|
yml2213
|
d285196287
|
feat(account): 账号「一键查询」（异步 + 批量）—— 含一次重要的判定修正
按 `docs/设计-账号一键查询.md` 实现。异步任务、支持批量（后端每账号一条任务）。
## 功能
- 新任务类型 `query_account_overview`：**只读**聚合查询，不改账号状态、不发事件
（纯查询不是「事实」，按既有设计例行查询不进时间线，否则会刷屏）
- 一次拉全：鱼翅 / 钱包兑换余额 / 积分（含到期）/ 精英宝典 / 电竞手册 /
**官方兑换记录** / 限兑商品，并**重点标出「兔兔白日梦」「狂战萌兔」是否已获得**
- **单项失败不整体失败**：账号没绑电竞手册是常态，失败只写进 `errors` 并在 UI
**如实展示** —— 避免「没查到」被读成「没有」
- 批量：`create_douyu_planned_tasks` 本来就是每账号一条任务，前端加「批量一键查询」
- 前端：详情页一键查询卡片 + 结果面板（两个套装单独高亮）；任务页结果自动弹面板；
三个工作台的快捷操作/类型集合都加了
## ⚠️ 修正：判定「是否已获得」用错了依据
设计文档第一版说「`storeStatus == 0` → 已拥有」，依据是
「账号 558（兑换过）count=0，账号 15407（没兑换）count=96982」。
**这是错的。** 那两条记录分别取自 **2026-08-01** 和 **2026-10-04**，相隔两个月 ——
我把**时间差异**当成了**账号差异**。
**同一时刻**同时查 558 / 607（都兑换过）和 15507（没有），
商品项的**所有字段完全一致**，`preExchange.isExists` 也都是 0；
`count` 的取值分布是 0/98746/103350/109832…，**随时间变化 = 全局库存**。
用它判「这个账号有没有」必然给错结论 —— 而对高价值资产给错结论是本功能最不能接受的。
**正确依据：`exchange_records(manual_id)`**（斗鱼官方的**账号级**兑换记录）。
真实斗鱼实测：
| 账号 | 官方兑换记录 | 判定 |
| --- | --- | --- |
| 558 | 破片手榴弹-兔兔白日梦 | **已获得 ✅** |
| 607 | 破片手榴弹-兔兔白日梦 | **已获得 ✅** |
| 15507 | （0 条） | 未获得 ✅ |
同时刻三者看到的兔兔白日梦库存**都是 96956**（全局），兑换记录却区分得干干净净。
顺带发现：同一件东西有多个商品名（`套装-兔兔白日梦`、`破片手榴弹-兔兔白日梦`），
所以按**核心词子串**匹配整个名字家族。
商品列表的 `score`/`count`/活动时间仍展示，但明确是**全局**信息
（「现在还能不能换、要多少分」），与「该账号是否已获得」分开。
## 测试
`tests/test_account_overview.py` 22 条，含**回归用例**：
`test_global_stock_never_implies_owned`（全局售罄不能推出账号拥有）——
正是第一版踩的坑。另有失败隔离、只读性（不发事件/不改状态）、
批量每账号一条任务、`missing` 不被静默丢弃。
## 验证
- `TZ=Asia/Shanghai` **574 passed / 6 skipped**；`TZ=UTC` 27 passed
- ruff 全绿；前端 build 通过、lint 0 errors
- **真实斗鱼端到端**：三个账号各跑一次真查询，8 项全部成功（`errors: []`），
已获得/未获得判定全部正确
|
2026-10-04 19:07:35 +08:00 |
|