dachui/live-hub-py
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
571 Commits 3 Branches 0 Tags
5405d4b1d16a14a2120f425ad533695d230c3804
Commit Graph
306 Commits
Author SHA1 Message Date
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
yml2213 d11fa1032d feat(login-tasks): 按状态导出 CSV + 登录失败写进账号生命周期 
一、失败入账号一生（此前完全缺失）
生产实测：`login_ok` 1,456 条、`relogin_failed` 73 条，但**没有 login_failed**，
而 login_tasks 里 attempt_status='failed' 有 247 条 —— 这 247 次失败在账号时间线上
一条痕迹都没有，「这账号为什么一直登录不上」在账号页上无从回答。

- 新增事件类型 login_failed，在 `_mark_attempt_failed` 里写入
- **被停止 / 被中断不写**：分型把「已停止/中断/服务重启」归到 interrupted，
  那不是账号的问题 —— 否则运营按一次停止就能给几十个账号刷满假失败
- 事件带分型（captcha/credential/email_code/email_quota/network），
  同时落进 detail.kind，以后可直接按「验证码失败」筛账号
- 幂等键 login_task:{id}:failed:{ts}，与成功路径同构

二、失败分型下沉成共用 service
`classify_failure` 原在 automation/jobs/ck_relogin.py，手动登录也要用。
挪到 services/login_failure.py（job 改为 import，`ck_relogin.classify_failure`
这个名字保留，旧调用方与用例不受影响），并提供型别中文标签与
`is_account_fault` 判据 —— 与仓库既有的「service 不该依赖 job」分层一致。

三、按状态导出 CSV
- 新增 GET /api/login/tasks/export：不分页，导出当前筛选的**全部**匹配记录；
  列：账号/状态/失败原因/失败分型/批次/最近尝试时间(UTC)/标签/归属客服
- 权限与筛选与列表**完全共用**，客服只导出自己名下账号
- 带 UTF-8 BOM（不加 Excel 打开中文表头是乱码），导出动作写审计

四、修一个口径不一致的真 bug
页面「失败 N」= failed + error 之和，但筛选只认 failed ——
所以截图里「失败 389」点进去只有 386 条（差的就是那几条 error）；
「清空失败」同样漏删 error。现在把状态组收敛成一份 `_apply_status_filter`，
列表 / 导出 / 批量删除三处共用。

测试：684 passed, 6 skipped（本次新增 13 个）；三条关键断言做了反向验证
（去掉 stopped 判断 / 失败组去掉 error / 去掉 BOM，对应用例均变红）。
 2026-10-07 12:54:57 +08:00
yml2213 281769b440 feat(accounts): 账号列表按归属筛选，批量分配支持按筛选全选 
原来只有 assigned_only（已分配），筛不出「未分配」，也看不到账号归谁。
新增 assign_status/assigned_user_id 可与标签、CK、搜索等叠加；
BatchAssign 支持 all_matching，「筛出未分配 → 一键分给某人」不必先勾选。
 2026-10-07 09:13:54 +08:00
yml2213 5da12df16b feat(account-check): 登录接口可选 wgapi / iframe 
账号检测原来把 WgapiLoginAPI 写死在执行器里，收不到邮箱验证码时只能干等；
登录任务早就可选 iframe（邮箱验证走 iframe 接口）。默认仍 wgapi，旧行为不变。
 2026-10-06 20:19:26 +08:00
yml2213andCursor 39388c56b5 fix(permissions): 收回客服的 CK 检测重登和自动巡检入口 
客服默认不再有 cookie:operate；自动巡检菜单改按 automation:view 显示。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-10-06 12:20:30 +08:00
yml2213andCursor f2157f67f7 feat(accounts): 账号列表按列排序，默认把还能换套装的排到前面 
分页在服务端，点表头按全库排，不能只排当前这一页。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-10-05 18:50:43 +08:00
yml2213andCursor ab4c0a5422 fix(login): 重登成功后把 CK 检测结论写回账号 
登录凭据快照盖掉了 ORM 账号，on_ck_verdict 读不到 ck_check_status，新 Cookie 被丢掉。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-10-05 18:20:10 +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 19f1cbceba fix(automation): 修复作业完成状态回写崩溃、统计字段对齐及表单布局挤压 
1. 修复 DouyuBatchRunner 在 run 结束时私自关闭外部 Session 导致作业状态无法回写并死锁在 running 的问题（增加 close_db 参数）；
2. 修复资料补全作业返回值映射，将 succeeded/failed 对齐到 valid/invalid，并在全库暂无待查账号时给出清晰说明；
3. 增强调度器 _run_one 边界防御：支持字段名兜底与 Session 崩溃时独立连接兜底回写，防止作业无限重复发起；
4. 修复巡检作业在全库无到期账号时的说明信息，如实展示最久检测时间与重检间隔；
5. 修复 AutomationPage 布局：移除外层 Form 的 layout=inline，Card 恢复 100% 满宽纵向排列，内部字段横向弹性自适应；
6. 修复未启用作业因残留历史 next_run_at 而错误显示「排队中」的问题。
 2026-10-04 22:11:44 +08:00
yml2213 e5f2d2d5d2 fix(automation): 修回被我上一处改动挤坏的布局（5 张卡横排、无间距） 
## 是我引入的回归

上一轮为了修「保存时存错作业」，我把各卡自己的 `<Form layout="inline">`
提到了外层统一包一层。但 `layout="inline"` **会把直接子元素排成一行** ——
于是 5 张 Card 横着挤在一起，还把原有的间距吃掉了（用户截图：一点间隔都没有）。

**同一个改动同时修了一个 bug、引入了一个 UI 回归** —— 说明我当时只验证了
"能存对作业"，没看渲染结果。

## 修法

- 外层 Form 里加 **`<Space direction="vertical" size={16}>`** 纵向容器，
  Card 恢复竖排、16px 间距
- 每张 Card `width: 100%`（不再由内容决定宽度）
- 字段行用 `<Space wrap size={16}>` 显式撑开，按钮组单独一段 `marginLeft: 16`

保留上一轮的关键修复：**仍然只有一层 Form**（`Form.Item` 靠 `[job.key, 字段]`
区分），保存按钮仍是显式 `onClick={() => saveJob(job)}` —— 不再依赖
"哪个 Form 的 onFinish 生效"。

并用注释把两个坑都写清了（各自包 Form 会存错作业；直接放 inline 子元素会挤成一行），
避免下次再踩。

## 验证

前端 build 通过。
 2026-10-04 21:43:38 +08:00
yml2213 bb767bb84a fix(automation): 保存配置时存错作业 —— 5 张卡共用一个 form 实例 
## 现象（用户报的）

点「账号资料定时补全」的保存，提示却是**「积分到期补记 配置已保存」**。

## 根因：不是提示文案错，是**真的存错了作业**

`jobs.map()` 里**每张卡各包一个 `<Form form={forms}>`，但它们共用同一个
`Form.useForm()` 实例**。React 里多个 `<Form>` 绑同一实例时，
**`onFinish` 会被最后挂载的那个覆盖** —— 于是：

    点第 1 张卡的「保存」→ 触发的是**最后一张卡**（积分到期补记）的 onFinish
                        → saveJob(积分到期补记)

## 实际影响（不涉及数据损坏）

- `saveJob(job)` 读的是**那个 job 自己的**字段值 → 所以「积分到期补记」
  只是被用它自己的值**重存了一遍**（无副作用）
- 而用户真正想保存的「账号资料定时补全」**根本没被保存** —— 静默失败

## 修法

把 Form **提到外面只包一层**（`Form.Item` 靠 `[job.key, 字段]` 天然区分各自的值），
保存按钮从 `htmlType="submit"` 改成显式的 `onClick={() => saveJob(job)}` ——
不再依赖"哪个 Form 的 onFinish 生效"这种隐含约定。

并在原处留了注释说明为什么**不能**各自包 Form（否则下一个人很可能又这么写）。

## 说明

前端这类"共用实例"的错误没有自动化测试兜住（仓库没有组件测试），
所以这次是靠用户点出来的。已在代码注释里写清原因，降低复发概率。

## 验证

前端 build 通过、lint 0 errors。
 2026-10-04 21:40:46 +08:00
yml2213 9ac98dad89 fix(automation): 补全作业改用界面上的「同一账号多久重检」—— 之前那个字段对它无效 
用户问「同一账号多久重检是啥意思」，顺着查发现**我的作业没在用它**。

## 「同一账号多久重检」是什么

**每个账号的体检周期**：一个账号这轮被查了，多久之后才重新进入候选。
批量扫描类作业的通用参数，配合另外两个决定"扫不扫得过来"：

    需要的能力 = 总账号数 ÷ 重检间隔
    实际的能力 = 每轮条数 ÷ 运行间隔

**实际 < 需要 → 永远扫不完**（队列越来越长）。

按这个口径核对「CK 自动巡检」的默认值（生产 14,574 个持有 CK 的账号）：

    需要 14,574 ÷ 6 小时 = 2,429 个/小时
    实际   200 条 ÷ 5 分钟 = 2,400 个/小时

**几乎精确匹配** —— 那两个默认值是校准过的，不用动。

## 但我的作业读的是 config 里的 refresh_days

于是界面上那个「同一账号多久重检」**对本作业是死的**（改了没反应）——
正是用户上一条批评过的同一类缺陷：「看起来能配、其实配的是不相干的东西」。
我在同一个问题上连着栽了两次（上一次是拿 `interval_seconds` 当调度频率算吞吐）。

改成 `job.interval_seconds`，与其它批量作业**同一套口径**；
默认 7 天（查过的账号 7 天后再查）。config 里的 `refresh_days` 整个去掉。

## 顺带

- 注册处显式写明两个参数：`interval_seconds=7 天`（重检）+ `run_interval_seconds=5 分钟`（调度）
- 用例改名并加注释，钉住"重检间隔必须来自界面那个字段"

## 验证

TZ=Asia/Shanghai **639 passed / 6 skipped**；ruff 全绿；前端 build 通过。
 2026-10-04 21:33:50 +08:00
yml2213 55f899c615 feat(automation): 拆开「多久跑一次」与「同一账号多久重检」—— 调度频率终于可配 
用户反馈：「单账号重检间隔(小时) 很别扭，直接设置多久跑一次、一次跑多少个更符合直觉」。

**对，而且比"别扭"更严重：调度频率以前根本改不了。**

## 问题：两个概念挤在一个字段里

`_run_one` 里原本写着：

    job.next_run_at = finished + timedelta(seconds=JOB_INTERVAL_SECONDS)   # 硬编码 300 秒

也就是不管界面上填什么，下一轮永远是「跑完 + 5 分钟」。
而界面那个「单账号重检间隔(小时)」对应的是 `interval_seconds` ——
它只被作业**自己的选行逻辑**使用（"这行多久该重检"），**完全不参与调度**。

于是出现最坏的情况：**看起来能配调度，其实配的是一个不相干的参数**。
上一轮我还拿它算过吞吐（"10 分钟一轮"），算错了 —— 已在调度器注释里纠正。

## 拆法

| 概念 | 字段 | 界面 |
| --- | --- | --- |
| **多久跑一次** | `run_interval_seconds`（迁移 0051，默认 300）| 「多久跑一次(分钟)」|
| 同一账号多久重检 | `interval_seconds`（不变）| 「同一账号多久重检(小时)」|

- `next_run_at = finished + run_interval_seconds`（有下限 30 秒，避免忙轮询）
- 接口：`GET` 返回新字段、`PATCH` 可改
- 前端：两个输入框分开，并把原来那段绕口的 tooltip
  （"它不决定调度频率 —— 调度周期见页面顶部说明"）改掉 ——
  那句话本身就是这个设计缺陷的自白

## 默认 300 秒

与改动前**实际行为一致** —— 不会因为这次迁移让已有作业突然变快或变慢。
想调快就自己填（比如「账号资料定时补全」填 5 分钟 + 每轮 400 条 ≈ 3 小时补完）。

## ⚠️ 顺带说明一个你截图里可能看到的现象

截图里「账号资料定时补全」显示的是 **0.5 小时 / 30 条** —— 那是我**最初的默认值**。
因为 `ensure_jobs` **只创建不更新**，我后面改成 10 分钟/400 **不会作用到已存在的行**。
这是刻意的（否则会覆盖运维的手工调整），但意味着**默认值改了要手动在界面上改**，
或者删掉那行让 `ensure_jobs` 重建。现在有了「多久跑一次」这个框，直接填就行。

## 测试（+3）

- 下一轮按**运行间隔**排，不是按「同一行重检间隔」（两个值刻意设成不同来钉住）
- 不填时默认 300 秒（保持旧行为）
- 过小的间隔被夹到下限

## 验证

TZ=Asia/Shanghai **639 passed / 6 skipped**；ruff 全绿；前端 build 通过、lint 0 errors。
 2026-10-04 21:30:13 +08:00
yml2213 aea8e4f73d perf(automation): 调度器改为**作业之间并发**，慢作业不再挡住快作业 
用户要求做这条（原本串行）。串行的代价现在很明显：新加的「账号资料定时补全」
一轮要 4 分钟以上，而源码注释里写的是「目前只有 CK 巡检，单轮约 20~40 秒」——
那 4 分钟里 CK 巡检/重登只能干等。

## 两处保护（缺一不可）

**① 在途守卫**（并发化之后最容易出的事故）

`next_run_at` 是作业**跑完之后**才更新的，所以一个跑得比 tick 还久的作业，
下一个 tick 看它仍然是「到期」状态 —— 没有守卫就会被**再派发一次**，
等于把速率翻倍（对斗鱼接口就是"并发放开"，正是风控最敏感的地方）。
所以用 `_IN_FLIGHT` 记录在跑的作业 key，且**成功/失败都必须清标记**
（否则该作业以后再也不跑了）。两条都有用例钉住。

**② 独立 session**

SQLAlchemy 的 Session **不是线程安全的**。作业现在真的并行了，
所以每个作业在自己的 `SessionLocal()` 里跑，按 key 重新取行
（调度线程里那行可能已经过期）。共用 session 会互相踩事务。

## tick 不再被拖住

调度循环改用 `run_due_jobs(db, wait=False)`：**派发完就返回**，
tick 保持 5 分钟一轮，不再等作业跑完。

`wait=True`（默认）保留原语义：顺序执行、用调用方的 session 并返回 outcomes ——
测试与手动触发走这条，所以既有的 33 条调度器用例**一条没改**。

## ⚠️ 顺带纠正我自己上一轮的一个错误说法

我上一条说「interval_seconds=10 分钟」会生效 —— **不对**。`_run_one` 里写着：

    下一轮固定在一个 tick 之后；interval_seconds 是「同一行多久重检」，
    由作业自己在选行时用，**不参与调度**。

也就是下一轮永远是「跑完 + 5 分钟」。所以「账号资料定时补全」的真实节奏是
`4.4 分钟跑 + 5 分钟等 ≈ 9.4 分钟一轮` ≈ 2,553 个/小时 ≈ **3.05 小时**，
和之前估的 3.2 小时吻合。

## 测试（+4）

- `wait=False` 立刻返回、作业在后台真的开始了
- **在途作业不会被重复派发**（速率翻倍那个事故的守卫）
- 失败后仍会清在途标记、作业能再跑（别被永久卡死）
- `_release` 即使对不存在的 key 也不炸

## 验证

TZ=Asia/Shanghai **636 passed / 6 skipped**；ruff 全绿。
 2026-10-04 21:24:35 +08:00
yml2213 0d60cfbec9 perf(automation): 账号资料补全提速到 ~3.2 小时（原默认值要 5 天多） 
用户反馈「几个小时补充完成就行吧，几天也太慢了」——**对，是我把调度设得太保守**。

## 算一下原默认值有多离谱

    30 个 / 30 分钟 = 60 个/小时  →  7,784 个要 **130 小时（5 天多）**

（我上一条说"3 天"还算乐观了。）

而**试水实测的吞吐**是 200 个 / 131 秒（并发 3）= **1.53 个/秒 ≈ 5,500 个/小时**。
**瓶颈根本不在查询速度，在我把调度频率设低了。**

## 新默认值：10 分钟一轮 × 400 个

    400 个 × 0.65 秒 ≈ 4.4 分钟/轮
    10 分钟一轮 → 2,400 个/小时 → 7,784 个约 **3.2 小时**

## ⚠️ 为什么不是更激进

查调度器源码发现一条**架构约束**（`run_due_jobs` 的注释写明）：

    作业串行执行 —— 目前只有 CK 巡检，单轮约 20~40 秒，远小于 tick

也就是**我的作业跑着的时候，CK 巡检/重登都得等着**（tick 5 分钟）。
所以一轮时长必须**明显小于间隔** —— 4.4 分钟 / 10 分钟是刻意留的余量。
一轮跑 6.5 分钟以上会把其他自动化作业饿住。

想更快有两条路（都需要你定）：
1. 调大 `batch_size` —— 但**跑得越快越容易被风控**，而风控是全部账号一起受影响
2. 让调度器**并发跑作业**（目前是串行）—— 属另一处改动

## 验证

TZ=Asia/Shanghai **632 passed / 6 skipped**；ruff 全绿。
 2026-10-04 21:17:02 +08:00
yml2213 fd578683b6 feat(automation): 新增「账号资料定时补全」作业 —— 分批慢跑，不撞风控 
## 为什么不能一次性跑全量

生产约 **8,000 个**「CK 有效但没查过」的账号。一次性发起 ≈ **8 万次斗鱼请求**，
很容易触发风控 —— 而风控一旦触发是**所有账号一起受影响**。试水 200 个时
0.65 秒/账号看着很香（全量 86 分钟），但那正是危险的地方：**跑得越快越容易被封**。

## 新作业 `account_overview_refresh`

照「自动巡检」（`ck_health`）那套做，并复用它的两道保护。

| 项 | 默认 | 说明 |
| --- | --- | --- |
| `interval_seconds` | 30 分钟 | 多久一轮 |
| `batch_size` | 30 | 每轮查多少（约 20 秒跑完）|
| `concurrency` | 3 | 并发 |
| `refresh_days` | 7（config 可调）| 查过的多久后再查 |
| `enabled` | **False** | 默认关，由运维手动开 |

按默认值：8,000 个约 **3 天**补完，全程不打满斗鱼接口。

## 两类账号**分开**（用户明确要求）

- **没查过的**（`overview_queried_at IS NULL`）**优先**
- 查过的只在超过 `refresh_days` 后重新入选

否则"周期性刷新老账号"会永远挤掉"从没查过的新账号"。
MySQL 没有 `NULLS FIRST`，用 `ORDER BY overview_queried_at IS NULL DESC` 等价实现。

## 只查有效 CK

`ck_check_status == 'valid'`。失效的查了也是白查（只会多一条失败记录），
交给「CK 检测与重登」处理。另外沿用 `cookie_operable_filter()`（有 CK 且无在途尝试）、
排除人工状态（停用/归档）与「不参与自动化」的账号。

## 风控熔断（沿用巡检口径）

一轮里失败率 > 50%（且样本 ≥ 10）就**自己把自己关掉**，交给人确认。
消息里写明可能原因，否则运维只看到"失败率高"会一头雾水：

    失败率过高，已自动关闭作业（大面积失败通常是**被风控**或接口抖动，请先确认再重开）

样本 < 10 不熔断 —— 1 个失败就是 100%，比例没意义。

## 查询记录

每轮都建真实的 `douyu_tasks` 行（payload 标 `source=scheduled_refresh`），
「哪个账号、什么时候、查出来什么」都有据可查，也能在任务列表里
区分「定时巡检」与「人工点查询」。账号上的 `overview_queried_at`
则是"下次该不该再查"的依据。

## 验证

- **镜像库实测**：`本轮查 3 个：成功 3 / 失败 0（剩 7784 个待查）`
- 本地 `TZ=Asia/Shanghai` **632 passed / 6 skipped**；ruff 全绿
- 新增 11 条用例：选择口径（只查有效 CK、没查过优先、refresh_days 可调、
  人工状态排除、batch_size 限流）+ 熔断（高失败率关闭、正常不关、小样本不熔断）
  + 一条回归：计数不能走带 LIMIT 的查询（作业第一版就是这么挂的）
 2026-10-04 21:14:16 +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 b199428619 feat(account): 一键查询展示「角色绑定明细」—— 不只一个"已绑定" 
用户看到绑定状态后问：「是不是在详情中增加详细的绑定信息啥的」。

`bind_info` 的返回里本来就有明细（`_parse_bind_info` 会解析出来），
之前只取了 `role_name` 一项。现在把运营真正要看的都带上：

- **角色名**（`role_name`）
- **区服 / 平台**（`area_name` / `plat_name`）
- 换绑冷却（`change_role_wait_time`）与可换绑时间（`can_change_time`）

实测（账号 61）：

  精英: 柿子洋音 / 微信 / 安卓(android)
  电竞: 资跳 / 微信 / 苹果(iOS)，可换绑 1788624000

面板新增「🎮 角色绑定明细」卡片，三个作用域并排；
冷却时间格式化成"无 / x 小时 / x 天 y 小时"，
时间戳过 `formatUnixSeconds` 那套（`0`/空显示 `-`，不显示 1970）。

## 验证（本地）

TZ=Asia/Shanghai **615 passed / 6 skipped**；ruff 全绿；前端 build 通过。
 2026-10-04 20:26:31 +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 f416397cc8 feat(account): 详情页重排 + 列表高价值套装列 + 兑换记录点击预览 
## 详情页重排（4 张卡，消除重复）

用户反馈「设计太乱、数据不好看、布局也乱」——根因是**同一份数据在一屏出现两次**：
积分/鱼翅/兑换余额在状态条和资产区各一次，角色绑定在状态条和信息表各一次。

新布局：**账号信息**（身份+状态+归属，一张 Descriptions）→ **资产与统计**
（数字只出现一次，上面"现在有多少"、下面"历史累计"）→ **高价值套装与兑换记录**
（从最顶上移到这里，它是补充信息，不该抢主视觉）→ **账号时间线**。
零散的 `flex + gap` 统计行改成 `Row/Col` 栅格，列宽对齐。

## 高价值套装：颜色按**价值**口径，别标反

用户澄清的业务语义与直觉相反：
- **没兑换过** = 还能用来绑定兑换 = **高价值**（绿色「可兑换」）
- 兑换过 1 个 → 价值降低；两个都兑换过 → 价值最低（橙色「已兑换」）

判定依据是**斗鱼官方兑换记录**（账号级）。⚠️ 不能用 `query_limited_goods` 的
`count`/`storeStatus` —— 那是**全局库存**（同一时刻不同账号看到的都一样），
用它判"这个账号有没有"必然给错结论。这个结论是推翻过一版才得到的：
第一版拿相隔两个月的两条快照对比，把**时间差异**当成了**账号差异**。

## 列表

- 新增「高价值套装」列：🟢两个都可兑换 / 🟠某套装已兑换 / ⚪未查询
  （「未查询」必须与「没兑换」分开，否则会把未知当成高价值）
- 「兑换记录」列只显示官方口径，**点击弹窗**看全部（按作用域分组，
  含商品/积分/真实兑换时间/当时用的昵称与平台），不用进详情页

## 三个作用域的记录展示

面板与预览都按 精英宝典 / 电竞手册 / 和平小店 分三块展示，
每条带**真实兑换时间**与"使用昵称"（排查时有用）。

## 顺带修

`exchange_records` 从数组改成按作用域分组的对象后，面板同步适配；
`formatTime` 对 `0` 显示 `-`（斗鱼用 0 表示"没有这个时间"，
直接格式化会显示成 1970/1/1）。
 2026-10-04 20:03:52 +08:00
yml2213 62d9053e8a feat(account): 官方兑换记录补成账号事件（三作用域）+ 一键查询结果落到账号 
## 官方兑换记录 → 真正的账号事件

关键发现：斗鱼官方兑换记录**带真实兑换时间**（`time` 字段），所以可以直接
补成正常的历史事件，时间线因此变完整（这就是「账号全生命周期」该有的样子），
列表的兑换聚合也随之准确 —— 上线前的兑换不再是一片空白。

- **三个作用域都拉**：精英宝典 / 电竞手册（共用 `exchange_records`，只有 manual_id
  不同）/ 和平小店（`xpd_embed_query` → `xpd_purchase_records`）
- 幂等键含作用域：`official_exchange:{scope}:{account}:{commodity}:{time}`
- `detail.scope` 标作用域；`source=official_sync` 与"当场记的"分得开
- 任一作用域失败只记进 `errors`，不影响其余（小店未开通会报
  `Livelink登录态校验失败`，属正常）

## 一键查询结果落到账号（不再只留在任务里）

- 新增 `accounts.high_value_owned`（迁移 0048）：**已兑换过的高价值套装名**，
  供列表展示。单开一列而不是让列表读 `overview_snapshot` —— 那份 JSON 有 1~2KB，
  15000 个账号各带一份会把响应放大到几十 MB。
- 迁移**可安全重跑**（启动时会自动跑）：加列前查 `information_schema`。
  ⚠️ 回填里**不要** `op.get_bind().commit()` —— MySQL 的 DDL 自动提交而 commit
  会打乱版本记账，表现为"列加上了、版本号没更新"，下次启动重复 ADD COLUMN
  直接把服务起不来（生产上就是启动即挂）。
- 迁移里从旧快照**回填** `high_value_owned`，已查过的账号不必重查。

## 两个 bug

1. **「最近一次兑换」按插入 id 排**（应为事件时间）：补录的历史事件 id 最大、
   时间却最老，会把几个月前的老兑换显示成"最近一次"。改为 `occurred_at DESC, id DESC`。
2. **手写的 `@model_serializer` 没列新字段** → 属性有值、JSON 里没有。
   这是本项目第三次踩 Pydantic 静默丢字段；已补，并把断言改为看 `model_dump()`。

## 列表「兑换记录」口径

只聚合**官方**记录（`source=official_sync`）：用户要求列表看官方的权威口径，
我们当场记的那些留给详情页时间线。另加 `GET /accounts/{id}/exchange-records`
供列表点击预览（按需拉取，不进列表响应）。
 2026-10-04 20:03:42 +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
yml2213 0b1fc1dee0 feat(events): 补齐资产【出项】—— 开通金额、鱼翅消耗、积分到期（C 最全） 
审「哪些操作该进账号生命周期」时发现：**进项有账、出项没账** ——
充值/积分到账都有金额，而开通（花积分）、送礼（花鱼翅）几乎没记，
于是「一共充了多少」算得出来，「花哪儿了」算不出来。

按确认的范围一次做完（应用宝充值**不动** —— 它按游戏角色记账、且未启用）。

## A. 开通类事件补金额

`elite_opened` / `esports_opened` 以前只记「开通后的积分余额」，不记**花了多少**。
现在补 `amount = -(开通前后积分差)`，并用**实测余额差**而不是"开通要多少分"的常量
（活动价、折扣会让实际扣减不同）。任一侧拿不到就不写金额，不编数字。

## B. 鱼翅消耗事件（新 `gold_spent`）

送礼以前只发「积分到账」，**花掉的鱼翅没有任何记录**。现在：
- 送礼**前后各刷一次**鱼翅（原来只在送礼后刷），取**实测余额差**；
- 发 `gold_spent`，`amount` 用负数（与 `exchange` 一致）；
- 余额没减少或拿不到 → **不发**：宁可少一条，也不要记一笔没发生的消耗。

## C. 积分到期（新 `points_expire`）

积分到期是资产真实减少，但**斗鱼不会通知** —— 只在积分查询里给 `willExpireTime`。
所以：
- 新增 `accounts.points_expire_at`（迁移 `0046`），送礼流程学到就写下来；
- 新增作业 `points_expire_check`：扫「已到期且积分未归零」的账号，补写事件并清标记
  （不重复记）；积分已为 0 则只清标记、不发事件（避免 `-0` 噪声）。

⚠️ **金额的诚实边界**：到期那一刻**到底扣了多少，我们没亲眼看到**。
所以默认 `confirmed=False`、标题带「（预计）」，记的是「当时余额」这个**预计要归零**的数量，
**不假装它是确认过的扣减**。作业刻意不发网络请求（纯 DB 可跑、不需要 CK），
要变成已确认只能由「到期后重查、真看到余额下降」的调用方补。

## 顺带修掉一个会静默丢事件的坑

同一个任务可能产生**两条事件**（送礼：既「积分到账」又「消耗鱼翅」）。
`source_ref` 是唯一键 —— 共用 `task_ref(task_id)` 会让**后写的那条被静默丢弃**。
已让副事件带后缀（`douyu_task:{id}:gold`），主事件保持原形态（与旧收集器一致）。
有用例专门钉住「一个任务两条事件都不丢」。

## 验证

- `TZ=Asia/Shanghai`：**550 passed / 6 skipped**（+18 条）
- `TZ=UTC`（事件 + 迁移 + 绑定）95 passed；ruff 全绿；前端 build 通过、lint 0 errors
- 真实开发库：迁移 `0046` 已应用；作业烟测 → 扫到 1 个到期账号，
  写入「积分到期 -500（预计）」`confirmed=False`，标记被清、重跑不再重复

## 现在的资产流水（斗鱼侧）

| 方向 | 覆盖 |
| --- | --- |
| 进项 | 充值（二维码/供应商/回调三路径去重）✅、积分到账 ✅ |
| 出项 | 兑换 ✅、**开通 ✅（新补金额）**、**送礼鱼翅 ✅（新）**、**积分到期 ✅（新，标预计）** |
| 未动 | 应用宝充值（独立系统、按游戏角色记、当前未启用） |
 2026-10-04 18:10:46 +08:00
yml2213 4c1fe0c84f fix(account): 补上电竞绑定映射漏掉的 game_not_bound（连生产库才发现的） 
把生产库克隆到本地做部署演练时，拉了三列绑定状态的**真实取值全集**，发现
`esports_bind_status` 里存在 `game_not_bound`（生产 26 行），而我的映射表里没有它
—— 会被归成 `unknown`，可它明明在说「没绑定」。

第一版映射只覆盖了文档里举的几个例子。**教训：映射表必须拿真实取值全集核对。**

修法：Python 映射与迁移 `0044` 的 CASE 同步补上 `game_not_bound → unbound`
（两者有逐字比对用例，不会分叉），并新增一条用**生产实测取值全集**驱动的用例
（17 + 11 + 9 个取值），以后往这三列加新取值时会被提醒确认语义，
而不是默默变成 `unknown`。

已在生产克隆库上验证：电竞列 unbound 从 0 变成 26（正是那批）。
 2026-10-04 17:49:02 +08:00
yml2213 eec42aa8a7 feat(check): 账号检测新增「按账号选择」—— 旧的手动输入与逻辑完整保留 
按反馈是**增加**而不是**替换**：旧路径一行未动，新路径另起一条。

## 两套来源并存

| | 手动输入（旧，默认） | 选择账号（新） |
| --- | --- | --- |
| 来源 | 粘贴文本 | 库里账号的凭据（不用人工粘贴） |
| 条目 `account_id` | **无** | 有 |
| 结果落账号时间线 | **否**（保持旧行为） | 是，新事件类型 `account_check` |
| 批次 / 并发 / 重试 / 代理 / 导出 zip | 完全不变 | 完全不变 |

**旧路径的「不发事件」是刻意的**：粘贴进来的账号没有归属，凭空造一条没有账号的
事件只是污染时间线。`parse_account_check_lines`、`export_line`、zip 分组全部未动，
有用例专门钉住这一点。

## 「选择账号」支持筛选（按反馈补充）

不是给一个扁平下拉，而是先按条件缩小范围再决定选法：

- 筛选：**标签 / 生命周期状态 / CK 健康**（复用账号列表同一套 `_filter_accounts_query`，
  两处口径不会不一致）
- 选法：手动多选（选项随筛选刷新）**或**「按筛选全选」（含列表里没显示出来的）

服务端支持 `select_all_matching + 各筛选条件`，与账号列表批量操作的字段形状一致。
可见性沿用账号域口径：客服只能检测自己名下的账号（越权 id 直接 403）。

## 结果表加账号回链

「选择账号」模式下条目带 `account_id`，账号列变成可点链接 → 直接跳到账号详情，
结果也在那里的时间线上。

## 排查中修掉两个 bug（都不是测试发现的）

**① `registry.create` 漏传 `account_id`**
它构造 `AccountCheckItemState` 时没把 `account_id` 从输入复制过去。
后果：批次照跑、结果照显示、zip 照导出，**事件永远不发且没有任何报错**。
是「跑一次真实检测再查事件表」才发现的（查出来 0 条）。已补，并加了用例。

**② 终态判断写成「键存在」而不是「非空」**
`_run_one` 置 `running` 时会显式传 `finished_at=None`，而判断写的是
`"finished_at" in updates` → **中间态也发事件**，于是时间线上记的是
`账号检查：running`；真正的终态再发时撞同一个幂等键被**静默丢弃** ——
结果是「只有一条，但记错了」，比没有更糟。

改成判非空。此处暴露了一个**假绿的用例**：我原来的「中间态不发事件」用例
没传 `finished_at=None`（与真实调用不一致），所以放过了这个 bug；
而且它还缺 `session.commit()`，在 MySQL REPEATABLE READ 下根本看不到
另一个会话刚提交的行 —— 双重假绿。两处都修了，并做了反向验证
（改回旧判断 → 用例立刻红）。

## 验证

- `TZ=Asia/Shanghai`：**520 passed / 6 skipped**（新增 17 条检测模式用例）
- `TZ=UTC`（检测 + 迁移）20 passed；ruff 全绿；前端 build 通过、lint 0 errors
- **真实端到端**：用真实库账号起批次 → 检测跑完（斗鱼返回「账号已认证」）→
  事件确实落库；清掉脏数据后用**与 `_run_one` 完全相同的调用序列**复验：
  两次 `_set_item` 只产生一条事件，且 title 是
  `账号检测：账号已认证`、`status=account_verified`（不再记成 running）

注：验证时真实触发了几次斗鱼登录检测（开发库那两个账号），结果都是「已认证」。
 2026-10-04 17:34:58 +08:00
yml2213 5ae5d92978 feat(account): 兑换记录列 + 修掉 source_ref NOT NULL 导致的事件静默丢失 
三件事合成一次提交（按反馈不再一改一提交）。

## ① 账号列表加「兑换记录」列

次数 + 最近一次（商品名 + 日期），填上列表右侧的空档。

数据源是**账号自己的事件流**（`account_events` 的 `exchange`），不是 `douyu_tasks`
的 JSON —— 后者是执行日志，S5 起业务事实已经在事件里了。

性能上刻意**每页只跑两条聚合查询**（不是每行一条 N+1）：
一条分组算 `count` + `max(occurred_at)`（走 `(account_id, event_type, occurred_at)`
复合索引），一条用窗口函数 `ROW_NUMBER()` 取每个账号最新那条的商品名。
实测 6 个账号 3 条兑换事件，聚合与「最近」都正确。

「兑换 」前缀在前端剥掉（列头已经叫「兑换记录」，再带前缀是重复）。

## ② 修掉一个静默丢事件的 bug（排查中发现的）

**现象**：开发库上「状态变迁 / 分配 / 标签 / 备注 / CK 清除」这些事件**一条都没有**，
而带幂等键的事件（业务事实、`ck_invalid`、`relogin_*`）照常写入 ——
时间线看起来有数据，只是恰好缺了某一类，**极难发现**。

**根因**：`source_ref` 是**可选**幂等键（模型与迁移文件都是 `nullable=True`，
`emit()` 对没有天然幂等键的事件就传 `None`）。但早期那版迁移
（重编号成 `0041` 之前的 `0040`）建的是 **NOT NULL**，而我后来只改了
**迁移文件**、没管**已建好的库** —— Alembic 只记版本号，不会重放已应用的脚本。
`__pycache__` 里那个 `20261002_0040_*.pyc` 就是旧版留下的痕迹。

**为什么静默**：`emit()` 按设计吞掉任何异常（事件是旁路，不能影响主流程），
只记一条 warning，调用方也从不检查返回值。已实测复现：
`emit(...)` 返回 `False` + warning，实际落库 `0` 条。

**修法**：迁移 `20261004_0045` 改回可空（`MODIFY`，**唯一索引保留**，幂等，
生产若跑过旧版也一并修好）。修复后实测：`emit` 返回 `True`、落库 1 条。

## ③ 补一条能防「未来」同类问题的守卫

`tests/test_migrations.py` 原本只比对「表/列/索引在不在」，**不比对可空性**。
已加：迁移建出的列**不允许比模型更严**（模型说可空、库里 NOT NULL）。

只查这个**危险方向**：反方向（模型 NOT NULL、库里允许 NULL）是无害的宽松，
历史遗留里有 28 处，一并报出来只会制造噪声、逼人修没收益的东西。

> 这条守卫**有边界**，已在代码注释与设计文档 §3.5.1 写明：
> 它在**全新库**上跑整链，只能防「未来的迁移建错」，**防不了已有库的历史漂移**。
> 已验证：临时禁用 `0045`，该用例仍通过（全新链本来就是对的）。

## 验证

- `TZ=Asia/Shanghai`：**503 passed / 6 skipped**（+3 条兑换列用例）
- `TZ=UTC`（迁移 + 列表相关）45 passed；ruff 全绿；前端 build 通过、lint 0 errors
- 真实开发库：迁移已应用（head `20261004_0045`），
  `source_ref` 现在 `IS_NULLABLE=YES` 且唯一索引仍在；
  不带幂等键的事件确实能落库；兑换聚合返回值正确

注：验证时在开发库那个有 CK 的账号上留了 3 条 `exchange` 演示事件
（兔兔白日梦 / 冠军鸡腿 / 烟花），是为了让列有数据可看，随时可删。
 2026-10-04 17:25:40 +08:00
yml2213 d3f5198227 style(ui): 账号列表列宽优化 —— 账号列不再吃掉全部剩余空间 
截图里的毛病很具体：**「账号」列被撑到 1000+px**，中间空出一大块，
而「状态」列只有 150px，把「检测 2026-10-01 19:07:25」挤成了两行。

根因是我前面把 ID 合并进「账号」列时，顺手把它的 `width` 去掉了 ——
于是它成了唯一的弹性列，把剩余空间全吃了。

修法：
- **账号列定宽 200 + `ellipsis`**，用户名过长就省略（`title` 保留全文）
- **CK 时间改用 `formatTimeShort`**（`10-01 19:07`），状态列加宽到 180，
  一句话能放下，不再折行
- 其余列宽按内容重新配比：绑定 190→150、积分 110→120、标签 170→190、操作 80→90（居中）
- **`tableLayout="fixed"`**：列宽按比例分配、剩余空间**均匀摊开**，
  而不是像 auto 布局那样全塞给内容最宽的那一列 —— 这才不会再出现「一列独大」

顺带清掉因此失效的 `formatTime` 导入（导入时间列上轮已删，它没有其它调用点）。

验证：pytest 500 passed / 6 skipped；ruff 全绿；build 通过、lint 0 errors。
 2026-10-04 17:19:09 +08:00
yml2213 a21e4a7e2a feat(ui): 账号列表恢复「标签」列（含就地编辑） 
按反馈把标签列加回来。这列不只是展示 —— **有 `account:tag` 权限时就是一个
内联编辑框**：选已有标签或直接输入新标签即保存，无权限时退化为只读 Tag。

因此一并恢复它所依赖的东西：
- `handleSetTag`（单条改标签）
- `tagColorMap` + `TAG_COLORS`（只读态的标签配色）
- `useMemo` 导入

所以现在改标签有三个入口，各管一段场景：
| 入口 | 场景 |
| --- | --- |
| 列表「标签」列 | 单条快速改 |
| 列表「批量打标签」 | 一批一起改 |
| 详情页状态卡 | 在账号全貌下改（S6） |

列表列最终为：**账号 / 状态 / 绑定 / 积分·鱼翅 / 标签 /（凭据三列，开关控制）/ 操作**

验证：pytest 500 passed / 6 skipped；ruff 全绿；前端 build 通过、lint 0 errors。
 2026-10-04 17:12:13 +08:00
yml2213 e24af9ad75 fix(ui): 账号列表按反馈调整 —— 保留批量操作与凭据开关，去掉「分配给」列 
上一个提交把四项一起砍了，其中两项理解反了，按反馈改回来：

## 恢复（撤销上一提交的 ① ④）

- **「显示凭据」开关 + 密码/邮箱/邮箱密码三列**
- **「批量打标签」「批量删除」按钮**，以及随之必需的**整套勾选机制**：
  `rowSelection`、`selectedRowKeys`、`selectedAllMatching`、
  「已选择 N 个 / 选择当前筛选下全部」提示条、批量设置标签弹窗、
  `handleBatchTag` / `handleBatchDelete`

## 新增去掉：**「分配给」列**

分配统一走「分配管理」页（`/accounts/assignments`，页面一直在），
列表里的内联分配下拉是重复入口。随之清掉只服务于它的
`handleAssign` / `loadUsers` / `users` 状态 / `userApi` 与 `UserInfo` 导入。

## 保持删除（反馈里未提）

**「标签」列**与**「导入时间」列**仍不恢复。注意因此产生的一处连带：
标签列里的**内联编辑框**也没了 —— 现在改标签的入口是
**批量打标签**（列表）+ **详情页状态卡**（S6 已做），够用。

## 踩到并修掉

用「区间删除」砍 `handleAssign`→`handleDelete` 时，把夹在中间的
**`handleBatchTag` 一起删了**（后来 `handleBatchTag` 引用未定义才暴露）。
已补回。教训：按区间删代码前要先确认区间里没有别的东西 ——
这类错误 `tsc` 只在**引用处**报，很容易看漏。

## 最终形态

- 列：账号 / 状态 / 绑定 / 积分·鱼翅 /（凭据三列，开关控制）/ 操作
- 工具栏：筛选（标签 · CK · 绑定 · 搜索）+ 显示凭据 + 批量打标签 + 批量删除 + 批量导入
- 618 行；`TAG_COLORS` / `tagColorMap` / `handleSetTag`(单条改标签)
  等确认无用的死代码已清

## 验证

- `TZ=Asia/Shanghai`：500 passed / 6 skipped；ruff 全绿
- 前端 build 通过、`npm run lint` **0 errors**
 2026-10-04 17:10:17 +08:00
yml2213 cb87a844b3 refactor(ui): 账号列表按「只做管理」重做 —— 砍掉凭据/标签/时间列与批量操作 
承接上一个提交。按确认的结果，四类老壳子残留一并移除：

## ① 「显示凭据」开关 + 密码 / 邮箱 / 邮箱密码 三列

这是老「卖号」视图的残留。移掉后列表不再有任何凭据字段，
`include_sensitive` 参数不再从列表请求里传（后端能力保留，需要时仍可显式请求）。

⚠️ 副作用：**界面上暂时没有地方能看到账号密码了**。当前重登全自动，
不需要人工读凭据；但如果你偶尔要抄出来核对，告诉我，我在**详情页**加一个
带权限校验 + 写审计的「查看凭据」，而不是把三列塞回列表。

## ② 「标签」列

标签仍可**筛选**（顶部下拉），但不再占一列。设置标签的入口统一到**详情页**
（S6 已在状态卡里做了就地编辑），列表里那个内联编辑框随之删除 ——
所以 `handleSetTag` / `tagColorMap` / `TAG_COLORS` 一并清掉。

## ③ 「导入时间」列

去掉（详情页仍有完整的导入时间与状态变更时间）。

## ④ 「批量打标签」「批量删除」按钮

随之移除**整套勾选机制**：`rowSelection`、`selectedRowKeys`、
`selectedAllMatching`、「已选择 N 个 / 选择当前筛选下全部」提示条、
批量设置标签弹窗、以及两个 handler。**单条删除保留**（操作列，受 `account:delete` 管）。
批量接口在后端保留不动（S4 已给它们接了逐账号事件，别浪费）。

## 结果

- 列表列：**账号 / 状态 / 绑定 / 积分·鱼翅 / 分配给 / 操作**
- 工具栏：筛选（标签 / CK / 绑定 / 搜索）+ 批量导入
- 文件 601 → 478 行；`Alert` / `TagOutlined` / `Eye*` / `App` / `modal` 等
  随之失效的导入与变量全部清掉（靠 `tsc --noUnusedLocals` 逐个抓出来）

## 验证

- `TZ=Asia/Shanghai`：500 passed / 6 skipped；ruff 全绿
- 前端 build 通过、`npm run lint` **0 errors**
- 逐个删除后都用 `tsc` 反查死代码，没有留下未使用变量
 2026-10-04 17:01:34 +08:00
yml2213 8a8c637db0 refactor(ui): 账号列表页重做 —— 状态分布当筛选入口，砍掉重复与噪声 
这页还是 S6 之前的老壳子：4 张统计卡有 3 张是装饰、状态与 CK 两列在说同一件事、
ID 单独占一列、绑定列 12 行全是「精? 电? 店?」。

## 统计卡 → 生命周期分布（可点击筛选）

原来：账号总数 / **标签数** / **已分配** / **未分配**。
标签数在筛选里就能看；已分配与未分配是一对冗余；而且它们都回答不了
「我该干什么」。现在按**生命周期状态**分布：总数 / 正常 / CK失效 / 待人工 /
未登录 / 已停用，**点一下就是「只看这些」**（`statusFilter`），计数为 0 的自动变淡。

后端 `accounts_summary` 相应扩出 `by_status` / `visible_total` /
`ck_invalid_count` / `no_cookie_count`。口径与列表一致：**归档不计入**。

## 表格列收敛

| 改动 | 理由 |
| --- | --- |
| **ID 列 → 并入「账号」小字** | 客服不看 ID，但报障时还要念得出来；合并后省一列宽度 |
| **CK 列 → 并入「状态」副行** | 生命周期状态里的「CK 失效」就是 CK 的结论，两列在说同一件事。合并后主标签给结论、副行小字给细节（检测时间 / `error` 这种「状态正常但没查明白」） |
| **绑定列：三个都 unknown 时显示「—」** | 满屏问号只是噪声，不如一眼看出「还没查过绑定」 |
| **「上传时间」→「导入时间」，精确到日** | 名字一直叫错；列表里只关心「哪一批」，时分秒是噪声（精确值挪进 tooltip） |
| **去掉「按状态筛选」下拉** | 上面卡片就是筛选入口，两处并存是重复（`STATUS_OPTIONS` 随之删除） |

## 验证

- `TZ=Asia/Shanghai`：**500 passed / 6 skipped**（+3 条 summary 用例）
- `TZ=UTC`（相关文件）82 passed；ruff 全绿
- 前端 build 通过、`npm run lint` **0 errors**
- 真实开发库：`by_status = {active: 4, imported: 8}`、`ck_invalid_count=0`、
  `no_cookie_count=8`、`visible_total=12`（与库内实际一致）

未动（待确认）：「显示凭据」开关与密码/邮箱/邮箱密码三列 —— 这是老「卖号」视图的残留，
默认关闭所以不占地方，但不确定现在的重登/检测流程还需不需要人工读凭据。
 2026-10-04 16:55:12 +08:00
yml2213 885a780bd3 feat(account): S6 账号页重构 —— 列表关键列 + 详情页生命周期状态卡 
S6 的展示层部分（数据模型部分见上一个提交）。目标：客服打开账号页要能一眼回答
「这账号能不能用、要不要我处理、账上还有多少」。

## 账号列表：加关键列 + 三个筛选

新增四列，**全部直接来自 `accounts` 行**（不 JOIN、不聚合 —— 列表是全站最热接口）：

| 列 | 内容 |
| --- | --- |
| **CK** | 有无 CK / 正常 / 已失效 / 检测异常 + 最近检测时间 |
| **绑定** | 精/电/店 三个作用域各一个小标签（✓ / … / ✗ / ?） |
| **积分 / 鱼翅** | 两行小字 |

新增筛选：**CK 健康**、**角色绑定**（三个作用域任一命中即算）。
`AccountOut` 相应补齐 `has_cookie` / `ck_check_status` / `ck_checked_at` /
`points` / `gold_balance` / 三组绑定状态与标签。

## 账号详情页：生命周期主页

顶部新增**生命周期状态卡**，把之前散落的信息聚成一眼可读的几格：

- **生命周期状态**：状态标签 + 不参与自动化标记 + 变更时间与原因
- **CK**：有无 / 健康 / 最近检测时间
- **角色绑定**：精/电/店三格
- **账上还有多少**：积分 / 鱼翅 / 兑换余额
- **归属与标注**：分配客服（下拉）+ 标签（就地编辑）—— 之前详情页只能看不能改

业务台账补上**登录成功次数**与**最近登录**（`stats` 里本来就有，只是没展示）。
时间线已有分类筛选，生命周期操作入口（停用/归档/恢复/自动化）S3 已加。

## ⚠️ 顺带修掉一个静默 bug

`bind_payload()` 的字段名按**作用域名**拼成了 `elite_bind_status` / `peace_bind_status`，
而 schema 声明的是 `role_bind_status` / `xpd_bind_status`。Pydantic 默认
`extra='ignore'`，于是多出来的键**被静默丢弃**、声明过的字段保持默认值 ——
**接口永远返回 unknown 而不报任何错**（这正是它躲过前面几轮测试的原因）。

修法：前缀改为由**列名**推导（`SCOPE_PAYLOAD_PREFIX`），并在模块导入时自检
「载荷前缀 == 列名前缀」。另加两条用例：`bind_payload` 的键必须都被
`DouyuTaskAccountOut` / `AccountOut` 声明（这是能抓到这类错的那种用例）。

顺带发现我自己之前那条 payload 用例**把错误的前缀当成了预期**，一并修正。

## 自己踩的坑

详情页加客服列表时又把 `useEffect` 写在了早期 `return` 之后 ——
和本次会话前面修 `LoginTasksPage` 的是同一个错。eslint（`react-hooks/rules-of-hooks`）
当场抓住，已上移。**`tsc` 与 `vite build` 都不会报这个**。

另外：列表关键列那处编辑我曾以为已生效（脚本打印了成功），实际没落到文件里 ——
后面是靠「读回文件确认」和用例失败才发现。已改为每次都读回核对。

## 验证

- `TZ=Asia/Shanghai`：**497 passed / 6 skipped**（S6 前半 490 → +7）
- `TZ=UTC`（相关文件）通过；ruff 全绿；前端 build 通过、lint **0 errors**
- **真实开发库端到端**：列表与工作台接口都返回了真实值
  （`has_cookie=True` / `ck_check_status=valid` / `role_bind_label=未知`），
  修 bug 前这两处返回的是被丢弃后的默认值

未做：`bind_status` 旧列待 S8 drop；保留策略里「状态派生类查询」已可下探到 7 天档（待确认）。
 2026-10-04 16:45:39 +08:00
yml2213 a64380fbcc feat(account): S6 bind_status 三列拆解 —— 四值枚举、唯一写入口、前端改读账号 
`accounts.bind_status` 是个**语义垃圾场**：一个自由文本列，6 个文件、**29 处写入**、
20 多种取值，混了三种东西 —— 真状态（`bind_confirmed`）、动作痕迹（`goods_locked`）、
纯查询痕迹（`points_queried`）。它是**覆盖式**的，所以 `bind_confirmed` 会被之后
任意一次查询盖掉 —— 「这个账号到底绑没绑」根本查不出来。
`esports_bind_status` / `xpd_bind_status` 是同一个病。

## 收敛成四值 + 三列一义

`unknown` / `unbound` / `pending` / `bound`，每个作用域一列：

| 列 | 作用域 |
| --- | --- |
| `accounts.role_bind_status`（**新增**） | 精英宝典角色 |
| `accounts.esports_bind_status`（收敛） | 电竞手册角色 |
| `accounts.xpd_bind_status`（收敛） | 和平小店角色 |

- 新增 `services/account_binding.py`：唯一写入口 `set_bind_status()`，
  传旧自由文本直接 `ValueError`（否则垃圾会被写回去）；`map_legacy_bind_status()` 负责旧值映射。
- **29 处自由文本写入全部删除或改走枚举**：真状态走枚举，动作/查询痕迹**不再写状态列**
  （动作已由 S5 的直发事件记录，查询痕迹本来就不该是状态）。
- `accounts.bind_status` 保留原值便于比对，**已无任何写入方**，待 S8 drop。
- 一条**源码扫描用例**禁止任何地方再出现 `account.bind_status = "..."` 这类写入。

## 回填不猜（设计文档 §5.5）

只映射**明确陈述了绑定关系**的取值（`bind_confirmed`/`esports_bound`/`xpd_bound` → bound，
`*_qr_*`/`*_ready` → pending，`game_not_bound`/`xpd_not_bound` → unbound），
**其余一律 unknown**。因为列是覆盖式的，「最后一件事是查询」并不代表没绑定。
迁移 SQL 与 Python 映射有一致性用例：**解析迁移源码里的 CASE 逐条比对**
（已反向验证：故意改错一条映射，用例立刻红）。

## ⚠️ 顺带救回一个差点被我自己丢掉的状态

「**电竞手册是否已开通**」以前**只寄生在 `esports_bind_status` 的 `esports_opened`
取值里**（`elite_opened` 有独立布尔列，电竞没有）。归一化会把那个取值抹成 `unknown`
→ **静默丢状态**。所以：
- 新增 `accounts.esports_opened` 布尔列（与 `elite_opened` 对称），开通任务成功时置位；
- 迁移里**必须先 `save_esports_opened()` 再归一化**，顺序用例钉住；
- 详情页「电竞手册」开通状态改读 `esports_opened`。

## 前端不再从任务日志反推账号状态

工作台原来从**当前加载的那一页任务**里挑每个账号最新的一条来推绑定状态
（`latestConfirmBindTaskByAccount` 等）。两个问题：① 支撑任务一旦翻出窗口，
**显示的状态就是错的**；② 这让任务日志变成「账号状态库」，于是它永远不敢清理。

现在状态读账号字段，任务日志只补「扫码流程中的瞬时信息」（如确认前的
`pending_role_name`）。删掉了两个不再需要的派生与对应的 `clearPending` 绕行逻辑。

## 踩到并修掉的东西

- **模型与迁移不一致**：我把模型收窄成 `String(16)`，迁移却留着 `String(32)` ——
  测试库按模型建、生产按迁移建，两边列宽不同。已让迁移也收窄，且**收窄必须在
  归一化之后**（旧取值最长 19 字符，先收窄会截断成废值）。downgrade 也补齐了反向操作，
  已实测 `downgrade -1 && upgrade head` 干净。
- **parity 用例第一版是抄了一份 SQL**（迁移改了用例也不会红，等于没测）——
  改成解析迁移源码；后来又因为列已收窄、19 字符的旧值塞不进测试库，
  干脆改成源码级解析比对（不造数据）。

## 验证

- `TZ=Asia/Shanghai`：**490 passed / 6 skipped**（S5 后 450 → 净增 40）
- `TZ=UTC`（相关文件）106 passed；迁移链 3 passed；ruff 全绿
- 前端 `tsc -b && vite build` 通过、`npm run lint` **0 errors**
- 真实开发库：迁移重放后三列均为 `varchar(16) NOT NULL DEFAULT 'unknown'`；
  12 个账号的旧值 `elite_status_queried`（纯查询痕迹）→ **unknown**（没有猜成 bound）

未做（后续）：S6 的**账号页重构**（列表关键列 / 生命周期主页）保留；
`bind_status` 旧列待 S8 drop；保留策略里「状态派生类查询」现在技术上可下探到 7 天档，
保守起见留待确认（影响的是在用页面显示，不是历史）。
 2026-10-04 16:28:06 +08:00
yml2213 6e729e7a80 feat(account): S5 业务事实直发事件 + 删掉收集器 + 任务日志保留策略 
时间线从此覆盖**全部**业务事实，`douyu_tasks` 也有了可控的增长边界。

## 一、删掉收集器（它必然漏数据）

`jobs/account_events_collect.py` 连同 `_task_to_event` / `COLLECTED_TASK_TYPES` /
水位线一起删除，迁移 `20261004_0043` 清掉它的作业行。删除理由是实测出来的：

- **靠 allowlist 认业务类型，新增类型就静默丢**：原有名单只有 5 个，
  而 `exchange_esports_goods`（电竞兑换）、`exchange_xpd_goods`（和平小店兑换）、
  `pay_locked_order`（锁单支付）、`donate_esports_*`（电竞礼物积分）**从来没进过时间线**；
- **「任务 success」≠「业务真的发生了」**（见下）；
- **字段路径靠抽样猜**：二维码充值的 `result` 里根本没有金额，收集器恒写
  `amount=None`，`recharge_total` 系统性少计；
- 作业默认 `enabled=False`，生产上一直没跑。

历史**不回填**（既有结论不变）：需要历史走斗鱼侧权威接口
（`query_exchange_records` / `query_xpd_purchase_records` / `query_points` 都是现成任务类型）。

## 二、业务事实直发：命名构造函数

新增 `services/business_events.py`：`record_recharge` / `record_exchange` /
`record_points_credit` / `record_bind`。每类事实的字段、标题、金额符号只定义一次
（与 S4 的 `record_account_action`、`on_ck_verdict` 同一套路）。

**9 处成功点接线**：`exchange_goods` 真兑换分支、`exchange_esports_goods`、
`exchange_xpd_goods`、`pay_locked_order`、`create_gold_qr`（二维码 + 供应商轮询 +
**供应商回调**三条路径）、`donate_elite_gift`、`donate_esports_gift`、
`confirm_bind`、`confirm_esports_bind`。

**只记真实事实**（按你的决定）：`exchange_goods` 里「预约到货 / 已预兑 / 预兑确认」
三条 success 分支**不发事件** —— 它们不消耗积分也没换到东西，旧收集器只按 status
收集，于是每预约一次就生成一条金额为空的 `exchange` 把 `exchange_count` 灌大。
`confirm_bind` 里「检测到账号本来就已绑定」那条也跳过。

## 三、修掉两个真 bug（都是钱账）

1. **到账判据 `!=` → `>`**（`douyu_runner_gold.py`）：余额**下降**也算「鱼翅已到账」。
   批内并发（最高 10）时同账号送礼会消耗鱼翅，余额一变就被充值任务读成到账，
   **往台账记一笔根本没发生的充值**。
2. **供应商回调晚于 runner 超时**：原来守卫是「任务状态没被改过才更新」，
   于是 runner 先判 failed、回调随后说成功的那笔真金白银**永远不进时间线**。
   改成按**回调自己的终态**判断，并补发事件。

## 四、发射顺序：一个会静默丢事件的坑

`_mark_task` 内部 `db.commit()`，而 `emit` 用 `db.begin_nested()` **只 RELEASE
SAVEPOINT、不提交外层事务**；runner 的 `finally` 只 `close()`（未提交即回滚）。
所以**在 `_mark_task` 之后发事件会被静默丢弃，且 `emit` 仍返回 True**。
所有接线一律紧贴 `_mark_task(success)` **之前**，并加了源码扫描用例钉住
（已反向验证：故意挪到之后，用例立刻报出 file:line）。

## 五、`douyu_tasks` 保留策略（新增作业，默认关闭）

`jobs/douyu_tasks_retention.py`，两档：

| 档 | 保留 |
| --- | --- |
| 噪声查询（只读看一眼就走，且前端不拿它派生账号状态） | **7 天** |
| 其余一切（业务事实 + 状态派生依赖的查询 + **以后新增的类型**） | **90 天** |

长保留档用 `task_type NOT IN (噪声名单)` 表达 → **新增类型默认长保留**，不会因为
「忘了加名单」被误删（正是收集器翻车的反面）。在途任务（planned/pending/running）
**绝不删**；分批删避免长锁；两个窗口都能在作业 `config` 里改，不必发版。

⚠️ 「前端从任务列表反推账号当前状态」那几类查询（`query_xpd_bind_info` /
`query_esports_game_name` 等）**故意留在长保留档** —— 删早了工作台账号行会变
「未查」，那是把**当前显示**搞坏。根治要靠 §3.6 的状态列拆解（后续阶段）。
作业默认 `enabled=False`，由运维决定何时打开。

## 验证

- `TZ=Asia/Shanghai`：**450 passed / 6 skipped**（S4 后 426 → 净增 24）
- `TZ=UTC`（相关文件）101 passed；ruff check/format 全绿
- 前端 build 通过、lint 0 errors
- 真实开发库：迁移已应用（head `20261004_0043`，孤儿作业行已清）；
  保留作业实跑确认「作业行默认关闭、SQL 在 MySQL 上正确、近期行不误删」
- **两处反向验证**：把 `record_bind` 挪到 `_mark_task` 之后 → 顺序用例报红；
  修掉 `registered_jobs()` 那个**假绿用例**（它返回 dict，原来的集合推导式
  遍历空字典恒成立），并在断言里加了反向确认

未做（后续）：S6 账号页重构 + `bind_status` 三列拆解（做完才能把状态派生类查询
也纳入短保留）、S7 账号检测改账号维度、S8 丢 `login_tasks` 旧凭据列。
 2026-10-04 16:00:42 +08:00
yml2213 253571730a feat(account): 补上改备注接口，remark_changed 事件从此有发射点 
`remark_changed` 此前是「定义了事件类型、但压根没有改备注的接口」，于是永远不发。
按 S4 的原则（留着一个永远不发的类型比删掉更糟 —— 看代码的人会以为它有数据），
补接口而不是删类型。

## 接口

`PUT /api/accounts/{id}/remark`，权限点 `account:remark`（授予 super_admin /
operation / support，与 `account:tag` 一致）。

- 与改标签一样走 `record_account_action()`：**审计 + 账号时间线一次写完**，
  审计带 `account_id`，事件 detail 带 `{from, to}`；
- **只做单个、不做批量**：备注是自由文本，给一堆账号写同一句备注没有实际意义
  （标签是短枚举才有批量）；
- 内容 trim 后截断到 256（与 `accounts.remark` 列宽一致），清空也记一条事件；
- 备注没变化时直接返回、**不写事件**：否则时间线会被「点开保存了一下但没改」刷满。

## 权限点新增前的安全检查

新权限点会被 `custom_permissions` 覆盖，所以先查了库：
`admin` / `kf1_test` 的 `custom_permissions` 是 **JSON null**（不是 SQL NULL），
Python 侧取出来是 `None` → `get_user_permissions` 走角色默认。
也就是说**没有任何用户在用自定义权限列表**，新增权限点不会把谁的能力锁掉。
（这一点很容易看错：`IS NULL` 判出来是「有自定义权限」，`JSON_LENGTH` 还是 1。）

## 前端

- 详情页「备注」一行改为可编辑（铅笔 → 输入框 → 保存/取消，回车即存）；
- `EVENT_STYLE` 补 `remark_changed`，时间线里能看到备注的每次变更。

## 一个自己踩到又修掉的坑

第一版把两个 `useState` 写在了 `if (!accountId) return <Empty/>` **之后** ——
正是本次会话刚在 LoginTasksPage 修掉的那类 hooks 顺序违规（`react-hooks/rules-of-hooks`
直接报错）。已上移到早期 return 之前的 state 区块。lint 抓到，构建不报，属于
「能跑但迟早炸」的那类问题。

## 验证

- `TZ=Asia/Shanghai`：**426 passed / 6 skipped**（S4 后 420 → 新增 6 条）
- `TZ=UTC`（相关文件）77 passed；ruff check/format 全绿
- 前端 `tsc -b && vite build` 通过、`npm run lint` 0 errors
- 新增用例：写入并带 from/to 事件与审计关联、未变化不写事件、清空也记一条、
  trim + 截断到 256、账号不存在 404、**新权限点确实在三个角色的默认权限里**
  （防止「加了接口但没人能用」）
 2026-10-04 15:21:48 +08:00
yml2213 0a922ce56d feat(account): S4 事件发射点补齐 —— 审计与时间线打通、批量事件、ck_invalid 只认转变 
S3 让 `status` 可信，S4 让**时间线完整**：账号上发生的事，时间线里都能查到。

## 补齐「定义了却从没发过」的事件

`assigned` / `tag_changed` 这两个类型早就定义了、前端 `EVENT_STYLE` 也渲染了，
但**全仓没有任何代码发过**（`grep` 只有定义处）。本次接上：

- 单个分配 / 批量分配 → `assigned`（detail 带 assigned_to / assigned_username）
- 单个改标签 / 批量改标签 / 按筛选批量改标签 → `tag_changed`（detail 带 from/to）

## 新增 `ck_cleared`，并修掉 `ck_invalid` 的刷屏

- **`ck_cleared`**：清 CK 是**不可逆**操作（重登当前成功率极低），时间线里却不留痕。
  现在单个清除与批量清除共用 `account_lifecycle.on_ck_cleared()`。
- **`ck_invalid` 改为只在「由好变坏」时发**。旧实现每轮巡检只要判定 invalid 就发一条，
  源码注释写着「避免每轮刷屏」，**但代码并没有做到** —— 6 小时一轮、失效一周就是
  28 条一模一样的事件。判定失效是**一次状态转变**，不是每轮读数。`error`（查不到）
  同样不改变结论、不发事件。

## 审计与时间线一次写完（防漏一边）

新增 `audit_service.record_account_action()`：**审计 + 账号事件一起写**，并把
`account_id` 落到审计上。这两件事必须成对出现 —— 只写审计，时间线就缺「谁改了什么」；
只发事件，合规审计就缺一条。分成两次调用写，迟早有人漏一边（`assigned` 就是这么漏的）。

顺带把批量删除的审计补上被删账号 id（`detail.account_ids`，截前 200 条）：
删账号会**连带删掉它的事件时间线**（外键），审计是唯一痕迹 —— 这正是 10-03
那次事故要留的东西。

## 批量操作不再逐条开 SAVEPOINT

批量分配/改标签可能覆盖几千个账号，而每个账号的时间线都该各留一条。
逐条走 `emit()` 会给每条开一个 SAVEPOINT，几千条时请求明显变慢。
新增 `emit_bulk()`：一次 executemany，整批包在**一个** SAVEPOINT 里，
与 `emit()` 一样**绝不抛异常**（整批失败就整批丢弃 + warning，不影响业务写入）。

## 检测入口收口：4 处 → 1 个 `on_ck_verdict()`

`ck_health` / 人工检测 / 工作台执行前检测 / 重登后复检 原本各自写
`ck_check_status` + `ck_check_result` + `ck_checked_at` + 发事件 + 调 `sync_status`，
口径容易分叉（`ck_invalid` 的刷屏就是这么来的）。现在统一走
`account_lifecycle.on_ck_verdict()`，顺序固定：**写结论 → 由好变坏记事件 → 重算状态**。

至此 `account_lifecycle` 成为**唯一**写生命周期字段的模块，并加了一条**源码扫描用例**
把它钉死（任何地方直接 `acc.status = ...` 都会让它红，并指出 file:line）——
比写在文档里的约定可靠。虎牙的 `huya_accounts.status` 是同一个病，但属另一套模型，
已在用例里显式排除并注明。

## 接口与前端

- 时间线支持 `?category=` 筛选（lifecycle / auth / business / ops）；
  响应补 `category` / `subject_*` / `actor_*`
- 前端 `EVENT_STYLE` 补上 `status_changed`（**S3 我漏的**：加了事件类型却没加样式，
  页面上显示成原始英文）与 `ck_cleared`；时间线加「分类」筛选

## 验证

- `TZ=Asia/Shanghai`：**420 passed / 6 skipped**（S3 后 404 → 新增 16 条）
- 迁移链 3 passed；ruff check/format 全绿；前端 `tsc -b && vite build` 与
  `npm run lint`（0 errors）均通过
- **两条关键用例都做过「反向验证」**（先注入旧行为确认会红）：
  - 把 `ck_invalid` 改回「每轮都发」→ 用例报 `3 == 1`；
  - 在路由里直接写 `acc.status = ...` → 不变量用例给出精确 file:line。
- 新用例还覆盖：批量分配/改标签逐账号发事件、清 CK 事件与审计关联、
  `emit_bulk` 的跳过与容错、时间线分类筛选、批量删除的 id 留痕。

未做（后续）：S5 业务事实直发事件 + `douyu_tasks` 保留策略、S6 账号页重构 +
`bind_status` 三列拆解。`remark_changed` 目前没有改备注的接口，故无发射点（已在文档标注）。
 2026-10-04 15:09:46 +08:00
yml2213 fbab805610 fix(ui): 修掉 LoginTasksPage 的 hooks 顺序告警（eslint 由红转绿） 
`setTaskSummary` 在 useEffect 里被使用（约 259 行），但它的 useState 声明在
约 420 行 —— eslint `react-hooks/immutability` 判为「访问了尚未声明的变量」。
这是 main 上就存在的历史问题，会让 `npm run lint` 失败。

**运行时其实不会踩 TDZ**（useEffect 在渲染后执行、且内部是 async，等到真正调用
setter 时声明早已执行完），但**声明与使用相隔 160 行**本身就是隐患：任何一次
把调用改成同步、或把 effect 往上移的重构都会真的炸。

处理：把 useState 声明移到任务相关 state 区块（taskPage / taskStatus / taskTotal
旁边）—— 既满足规则，也让这组状态聚在一起。先确认过**组件在声明之前没有任何
早期 return**，所以上移不会改变 hooks 的调用顺序。

验证：
- `npx eslint src/pages/LoginTasksPage.tsx` → 0 errors（原本 1 error）
- `npm run lint` → **exit 0**（29 个 warning 是既有的 react-refresh 提示，未动）
- `npm run build`（tsc -b && vite build）通过
 2026-10-04 14:52:05 +08:00
yml2213 1a8710834a feat(account): S3 生命周期状态收口 —— 6 状态状态机、唯一推导入口、停用/归档闭环 
`status` 列从「空壳」变成可信状态：S1 建了列、S2 让账号独立，本提交让状态真正
反映账号处境，并把「哪些账号要人处理」变成可筛选的事实。

## 状态机（7 → 6 个状态）

`imported` / `active` / `invalid` / `manual` / `disabled` / `archived`

**砍掉 `relogin`**：它完全等价于 `invalid + relogin_next_at is not None`，
独立成状态就多出一个必须与 `relogin_next_at` 同步的字段 —— 正是要消灭的「双份真相」。

## 唯一推导入口（防「双份真相」）

新增 `services/account_lifecycle.py`：
- `derive_status(account)` —— **纯函数**，按 cookie / ck_check_status / relogin_*
  推导状态；人工态（disabled/archived）优先级最高，不被覆盖；
- `sync_status(db, account)` —— 推导 + 变了才写，**幂等**（没变则不写库、不发事件，
  否则巡检每轮都往时间线刷一条）；
- `set_manual_state(db, account, state)` —— 停用/归档/`auto`（恢复自动推导）；
- `on_login_success(db, account)` —— **「登录成功对账号意味着什么」只定义一次**：
  作废本轮重登退避痕迹 + 重算状态。于是**「待人工」的账号被人工登录救回来时状态
  会自动恢复**，而不是卡在 manual。
- `MANUAL_KINDS` 从 `jobs/ck_relogin.py` 挪到这里（service 不该反向依赖 job）。

**9 处底层判据写入点全部接线**：登录成功、CK 清除（单个/批量）、ck_health 巡检、
人工 CK 检测、工作台执行前检测、重登复检、重登结算（成功/失败退避）。

## 消费端：补上一个真缺口 + 删掉两处临时派生

- ⚠️ **缺口**：`ck_health` / `ck_relogin` / `count_pending_relogin` 此前只按底层判据
  选行，**没排除 disabled/archived** —— S2 提交里已标注，状态一上线就会变成
  「停用的账号照样被自动重登」。现已全部排除。
- `automation.manual_queue` 原本用 4 个条件自己拼「需要人工」，现在一句
  `status == 'manual'`。同一判据从「3 处各写一遍」收敛成「1 处推导」。

## 接口与前端

- `PUT /api/accounts/{id}/lifecycle`（disabled/archived/auto + 原因，写审计）
- `PUT /api/accounts/{id}/automation`（**接上死开关**：`auto_managed` 此前没有任何
  接口/前端能改，永远是默认 True）
- 新增权限点 `account:manage`（运营默认拥有）
- 列表支持 `?status=` 筛选；**归档默认不出现**（要看需显式筛选）
- `AccountOut` / 概览接口补 status / status_label / status_reason / auto_managed
- 前端：账号列表加「状态」列与状态筛选；详情页状态卡 + 停用/归档/恢复/自动化开关

## 两个自查出来的问题（都已修）

1. **幂等键反而丢事件**：状态事件一开始用 `status:{id}:{target}:{秒级时间戳}` 作
   `source_ref`，结果同一账号在同一秒内两次切到同一状态就撞唯一键，`emit` 静默吞掉
   —— **状态改了、时间线却少一条**，正是本模块要消灭的「悄悄不一致」。
   改为不传 `source_ref`：`sync_status` 本身已幂等，不存在重复写入路径。已加用例。
2. **迁移与运行时规则分叉**：迁移 0042 的状态回填 CASE 原本会写出已被砍掉的
   `relogin`，且判据与 `derive_status` 不一致（次数用尽的会回填成 invalid 而非 manual）。
   已改成逐字对应，并加一条用例**真跑那段 SQL 与纯函数逐条比对**（已验证：
   临时改回旧 CASE 该用例立刻红）。

## 验证

- `TZ=Asia/Shanghai`：**404 passed / 6 skipped**（S2 后 373 → 新增 31 条）
- 迁移链 3 passed；ruff check/format 全绿；前端 `tsc -b && vite build` 通过
- 真实开发库核对：落库状态分布 active 4 / imported 8，**与 derive_status 逐账号比对无漂移**
- 新增用例覆盖：derive 真值表（每状态入口 + 人工态优先）、sync 幂等、
  人工态切换、**全生命周期走查**（导入→登录→失效→重登→转人工→人工救回→清 CK→停用）、
  自动化排除 disabled/archived、列表状态筛选、接口

未做（后续阶段）：S4 事件发射点补齐、S5 业务事实直发事件、S6 账号页重构。
 2026-10-04 14:48:22 +08:00
yml2213 94eace50c1 fix(events): S2.1 修掉 emit() 的 naive 时区偏移，并打通台账列与审计关联 
外部审计对 S1+S2 提出 3 条，全部复核成立，本提交一并修掉。第 1 条是真缺陷，
且已经写进数据了。

## 1. ⚠️ emit() 把 naive datetime 当成「本地时间」（数据正确性）

`emit()` 原来写 `(occurred_at or now).astimezone(UTC)`。对 **naive** 值，Python 会
把它当作**服务器本地时间**再换算 —— 本机 UTC+8，事件时间整整早 8 小时。

naive 的来源很具体：收集器用**裸 SQL** 读 `douyu_tasks`，绕过 `UTCDateTime`
装饰器，拿到的就是 naive。而这条路正是「充值/兑换/积分/开通」台账。

仓库早有既定约定（写在 `database.UTCDateTime` 里）：**naive → 视为已是 UTC，原样用**。
`scheduler._as_utc` / `yyb_service._as_utc` / `audit.py` 都遵守了，**只有 emit() 漏了**。
现抽成 `account_events_service.to_naive_utc()` 统一收口，并补齐文档。

**数据库铁证**（修复前，本机开发库）：
```
事件 occurred_at        源 douyu_tasks.finished_at    相差
2026-09-30 20:23:36  →  2026-10-01 04:23:36          8 小时
```
已用 `UPDATE ... JOIN douyu_tasks` 把那 3 条按源时间对齐（相差 0 秒），
修复 SQL 记在账号事件设计文档 §11.2 第 5 条，供曾开启过收集器的环境使用。
该作业默认 `enabled=false`、需人工开启，故生产大概率无受影响数据。

## 2. 回归用例：这个 bug 在 UTC 机器上**看不见**

`astimezone(UTC)` 在 TZ=UTC 下恰好是恒等变换 —— 旧实现与正确实现结果相同。
也就是说单写一条普通用例，在 CI/容器里会**假绿**，只在开发机现形。

所以用例显式把进程时区切到 UTC+8（`_force_non_utc_timezone`）。已验证：
**在 TZ=UTC 下临时还原旧实现，该用例照样红**。另补一条 aware 路径的用例，
防止「为了修 naive 把换算弄坏」。

顺带补了收集器的端到端用例：**事件 occurred_at 必须等于源任务 finished_at**。
旧用例只断言 written/watermark 数量、从不看时间，这正是 bug 一路绿灯的原因。

## 3. emit() 支持 S1 建的台账列（此前是「空壳」）

迁移 0042 给 `account_events` 加了 `category` / `subject_type` / `subject_key` /
`actor_type` / `actor_id` 与复合索引 `ix_account_events_ledger`，但 `emit()` 一直没
暴露它们 —— 列建好了没有写入方。现补齐参数与 INSERT，并加用例锁住「能写」。
S3 的 `status_changed`（`category="lifecycle"`）与 S5 的台账查询都要靠它。

## 4. 清 CK 的审计补 account_id

`DELETE /cookies/{id}` 与 `/cookies/batch` 的审计只写了 `target`（自由文本，
账号改名/重名就关联不上）。S1 已给 `audit_logs` 加了 `account_id`，这里补上写入
（批量时仅在只涉及一个账号时填），并加用例断言审计能反查到账号。
这是 S6「审计进账号时间线」的前置。

## 验证

- 新增/修改 5 条用例，先红后绿；**已验证在 TZ=UTC 下旧实现照样被这些用例抓到**
- `TZ=Asia/Shanghai`：**373 passed / 6 skipped**（原 368 + 5 条新用例）
- `TZ=UTC`：369 passed / 4 failed —— 那 4 条是 `test_huya_web_cookie_fields.py`
  的 qimei 用例，**在 main 上同样失败**（qimei 按 SDK 语义编码本地时间，
  与本次改动无关，也未修）
- ruff check / format 全绿；前端 `vite build` 通过（本次未动前端）
 2026-10-04 14:30:02 +08:00
yml2213 00125fbfc4 refactor(account): S2 读写一次切换 —— CK/健康/重登彻底搬到账号，登录记录退化为历史 
S1 加好了列，本提交把**读与写一起切**过去。这是设计里「同一份数据的读与写必须
在同一个提交里切」的要求：先切读或先切写都会出现「写账号、读记录」的中间态，
跑起来不报错，只是默默用错数据。

## 核心改动

**判定「谁有 CK」不再借道登录记录**
- `cookie_holding_filter()` / `cookie_operable_filter()` / `cookie_holding_account_ids_query()`
  / `visible_douyu_task_accounts()` 全部改为作用于 `Account`；
- `cookie_operable_filter()` 的「在途排除」仍查 `login_tasks`（那是**某次尝试**的属性），
  用 `NOT EXISTS` 子查询 + 迁移 0042 新增的 `(account_id, attempt_status)` 索引；
- 删除死代码 `latest_cookie_login_task()`；`latest_cookie()` 改为直接读账号。

**CK 写入**
- `_write_login_success()` 写 `Account.cookie / cookie_updated_at / cookie_source`；
- `_mark_attempt_failed()` 改看**账号**有没有 CK（决定是否沿用旧的失败语义）；
- 检测模式的 `task.cookie = ""` **不再清空账号的 CK**（见下「行为变更」）。

**自动化作业按账号调度**
- `ck_health`：`_select_tasks` → `_select_accounts`，`db.query(Account)`；新增
  `count_remaining()`（刻意不带 LIMIT，否则积压数恒等于批次上限）；
- `ck_relogin`：同样按账号选行；结算改为「账号 + 本轮尝试记录」，
  退避进度写账号；`settle_fresh_results(batch_id)` 按 `attempt_batch_id` 配对，
  `run_ck_relogin` 把 **account_ids** 交给 runner；
- 顺带让**没有任何登录历史的账号**也能被巡检/重登（以前它们永远进不了队列）。

**登录批次**
- `LoginBatchRunner` 去掉 `relogin_task_ids`，重登与登录统一走 `account_ids`；
- 批次行复用逻辑重写：只保证「同一账号不并发两行」，不再关心「哪一行持有 CK」。
  失败行复用同时看 `attempt_status`（账号有 CK 时 `_mark_attempt_failed` 刻意不动
  `status`，只看 status 会永远命不中 → 每次失败刷一行）。

**删除护栏语义变更（用户可感知）**
- 去掉「持有 CK 的记录不可删」——CK 在账号上，删历史不再影响登录态，历史终于可清理；
- **保留**「在途尝试不可删」（批次线程正拿着那条记录）。

## 行为变更（需评审）

1. **账号检测不再清空 CK**。旧代码在 check 模式写 `task.cookie = ""`，而那时记录的
   cookie 就是账号唯一凭证 —— 一次「批量检测」会把账号登录态删掉。解耦后
   「检测账号凭据」与「CK 是否有效」本就是两件事（后者归 `ck_health` 判），
   继续清空等于凭空制造不可逆的数据丢失（重登当前成功率极低）。
2. **Cookie 页的记录单位从「登录记录」变成「账号」**，所有接口的 id 入参/出参
   变成 `account_id`；`DELETE /cookies/{id}` 清的是该账号的 CK，**必写审计**。
3. 重复检测从「同一账号多行持 CK」改为「**同一个 CK 出现在多个账号上**」——
   后者才是真风险（两个账号共用一个登录态）。用 sha256 指纹分组：
   CK 是 AES-GCM + 随机 nonce 加密，**同一明文每次密文都不同**，比密文永远比不出重复。

## 修掉一个真实并发缺陷

`_write_login_success` 原先被传入 `self.db`（runner 主会话），而它是在**工作线程**里
用 `worker_db` 执行的。`emit()` 会往 `account_events` 插一行，其 `account_id` 外键对
`accounts` 那一行加**共享锁**；这把锁加在另一个会话上，紧接着本会话的
`UPDATE accounts SET cookie=...` 就被自己人挡住 —— 实测 **50 秒后
`Lock wait timeout exceeded`，登录明明成功却写不回 CK**（改造前 UPDATE 打在
`login_tasks` 上所以没撞上）。改为传 `worker_db`：事件本就该和状态变更同事务提交，
顺带修掉跨线程共用一个 Session 的隐患。

## 验证

- 全量 pytest **368 passed / 6 skipped**；迁移链 3 passed；
- 前端 `tsc -b && vite build` 通过；
- `ruff check` / `ruff format --check` 全绿（顺带修掉 main 上遗留的 F821）；
- 新增/改写的关键回归：**删掉全部登录历史后账号的 CK 与健康状态仍在**、
  **无登录历史的账号也能进巡检队列**、结算不碰 CK、删除护栏改为在途语义。

仍未做（设计里排期的后续阶段）：`account_lifecycle` 状态收口（S3）、事件发射点补齐（S4）、
业务事实直发事件（S5）、账号页重构（S6）。注意 `status` 目前只有模型默认值与迁移回填，
所以 `disabled/archived` 还没有任何写入方——S3 落地时要把自动化选行的状态过滤一起补上。
 2026-10-04 14:10:13 +08:00
yml2213 e916a7015d feat(db): S1 迁移 0042 —— 账号全生命周期落库（登录态 + 状态机 + 事件台账） 
账号不再依赖登录记录的第一步：把「账号自己的东西」搬到账号上。本提交**只加列、
只读源表**，不改任何行为，单独部署安全。

accounts 新增 15 列：
- 登录态：cookie / cookie_updated_at / cookie_source
- CK 健康：ck_check_status / ck_check_result / ck_checked_at
- 重登进度：relogin_attempts / relogin_next_at / relogin_last_error / relogin_failure_kind
- 生命周期：status / status_reason / status_changed_at / disabled_at / archived_at
- 索引：ck_checked_at、status、与 (status, relogin_next_at)

account_events 新增 5 列（category / subject_type / subject_key / actor_type / actor_id）
与台账复合索引 (account_id, event_type, subject_key, occurred_at) —— 支撑
「365 天同皮肤」这类需要检索客体的规则，让事件表同时承担业务台账。

login_tasks 补 (account_id, attempt_status) 索引：CK 搬到账号后，「在途尝试」只能留在
登录记录上，巡检/重登每轮都要按它过滤。

回填做成生产级：
- 只读 login_tasks、分块 200 账号、幂等（只在 accounts.cookie 为空时写）；
- 窗口函数取「最近一条持 CK 的行」，不用 GROUP_CONCAT（受 max_len 限制会静默截断）；
- 自校验 fail closed：回填不完整直接抛错让应用起不来，宁可起不来也不带半份 CK 上线；
- 外加值级校验，防张冠李戴（条数相等仍可能 A 账号拿到 B 账号的 CK）。

踩坑留档：cookie 是 TEXT，**不能有 server_default**（MySQL 1101：
BLOB/TEXT/GEOMETRY/JSON column can not have a default value），模型与迁移两侧都要去掉。

验证：
- 空库整链 upgrade head + 模型对齐 + 索引存在 → 通过；
- 本机开发库实跑 0041→0042：记录侧 4 个持 CK 账号 = 账号侧 4 个，值级不一致 0，
  CK 仍是密文（enc:v1: 前缀），状态分布 active 4 / imported 8；
- downgrade 到 0041 再 upgrade：数据完整还原（这是 CK 丢失场景的安全网）；
- 全量 pytest 364 passed / 6 skipped。
 2026-10-04 13:45:59 +08:00
yml2213 98a9f0e0bc chore(merge): 账号事件迁移改号 0041，并去重排查报告 
dev 与 main 从 294c6cd 分叉后，各自新增了一个 0040 迁移（都从 20261002_0039 起链）：
- main：20261003_0040 douyu_tasks.account_assigned_to（生产已应用）
- dev： 20261002_0040 account_events（未上生产）

两者合并即两个 alembic head，upgrade head 会直接失败。因为账号事件迁移从未被生产库
应用过，改号是安全的：

1. account_events 迁移改名为 20261003_0041，down_revision 指向 20261003_0040；
2. tests/test_migrations.py 的 HEAD_REVISION 同步改 20261003_0041；
3. 迁移保持幂等，本机开发库（alembic_version 已是 20261003_0040、account_events 表已存在）
   实跑 upgrade 通过，仅推进版本号、数据未动；
4. 顺带修正规划/解耦设计里「下一个迁移编号」的过期取值（现为 20261003_0042）。

排查报告去重：两个会话各自写了一份《生产服务器高负载排查…》报告，内容重叠且互相矛盾
（一处写 8 核/16GB，另一处有 nproc 原始输出为 4 vCPU/7.1GiB）。合并为单一文档
docs/生产服务器高负载排查与优化报告.md，以带原始命令输出的事实为准，删除重复的那份，
并修正引用它的迁移方案文档。
 2026-10-04 13:20:36 +08:00