dachui/live-hub-py
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
575 Commits 3 Branches 0 Tags
4eef45efe400bcd16455cb820fcc8df7188799e5
Commit Graph
54 Commits
Author SHA1 Message Date
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 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 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 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 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 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 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 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 e88c41385b Merge branch 'main' into dev 
# Conflicts:
#	tests/test_migrations.py
 2026-10-04 13:17:43 +08:00
yml2213 7790be4e04 perf(douyu-tasks): 为斗鱼任务增加归属客服索引字段，彻底消除全表 filesort 慢查询 
1. 数据库新增迁移 20261003_0040，在 douyu_tasks 表增加 account_assigned_to 字段，并创建 (account_assigned_to, handbook_scope, id) 与 (account_assigned_to, id) 复合覆盖索引；
2. 迁移脚本自动回填历史 24 万条任务的所属客服 ID；
3. 任务服务与账号路由联动：创建任务时自动继承 account_assigned_to，修改账号分配时同步更新关联任务归属；
4. 斗鱼任务查询路由 _visible_tasks_query 改为通过 account_assigned_to 复合索引过滤，消除与 accounts 表的跨表关联与临时表全量文件排序；
5. 新增 test_douyu_task_assigned_optimization 单元测试并通过整链迁移与回归测试。
 2026-10-03 13:10:59 +08:00
yml2213 834bfdd1d0 feat(account-events): 账号详情页与账号事件历史全链路支持 
1. 新增账号事件数据表 AccountEvent 与迁移版本 20261002_0040_account_events，支持审计 Cookie 变更、自动重登、健康检查及任务执行事件；
2. 后端新增 account_events_service 并扩展 /api/accounts 路由，支持事件查询、过滤与上报；
3. 前端新增 AccountDetailPage 账号详情页组件，支持账号元信息展示、事件历史瀑布流与快捷重登操作；
4. 修复 CK 重登与自动化定时任务中事件关联逻辑，补充 test_account_events 单元测试；
5. 新增生产服务器高负载排查分析报告及相关设计文档。
 2026-10-03 12:58:58 +08:00
yml2213 afa5c815f6 feat(orders): P0 订单读取适配层——连 order_site 只读库查订单（默认关闭） 
让运营能按订单号查到订单，作为后续资料收集（P2）与皮肤准入（P3/P4）的输入。
order_site 零改动：只读直连、独立极小连接池、可一键降级。

上机核实推翻了规划两处假设（详见 §6.5.1）：
- orders 表没有 order_no 列，只有 id 与 platform_order_id → 查询入口用后者；
- platform_order_id 非唯一：541 组重复，形态固定为「91kaquan 内部行(已发货)
  + 真实店铺行(无人管)」。按规划原文的单行判据，这 540 个已发货订单会被误判
  成「没人管」而放行重复履约。改为**订单号维度聚合**：任一行已发货即 auto_fulfilled。

真机验证（只读账号 livehub_ro）：三桶判定全对，重复组正确拦下并回显真实
店铺行的中文名（狂沙舞者，而非内部码 suit_sand_dancer），单次查询 3.3ms。

顺带修一个只在真机才暴露的 bug：_get_engine 先置 _INITIALIZED 再读 URL，
一次落空就把模块永久毒化成不可用，之后补上连接串也救不回来。
 2026-10-02 22:50:20 +08:00
yml2213 8fc8e623b9 feat(automation): CK 自动重登（P1b）+ 失败分型与待人工队列 
P1a 的巡检只产出「谁失效了」的清单，不兑现修复：1,356 个失效账号仍要人工逐个
选集→点重登→过滑块。线上实测 20 个失效账号重登 20/20 成功（2 分 13 秒、零极验），
证实失效是会话级过期而非凭证问题，可救量约 1,350。

后端：
- 迁移 20261002_0038：login_tasks 加 relogin_failure_kind（枚举），供作业决定
  「继续退避重试」还是「转人工」；不用 attempt_message 做字符串匹配（文案一改
  就失效，页面也要按类型筛选）；
- jobs/ck_relogin.py：
  - 候选 = 巡检判定 invalid + 允许自动管理 + 无在途尝试 + 退避到期 + 未超每日上限
    + **未转人工**（极验/凭证问题不再自动重登）；
  - 复用 LoginBatchRunner(mode="relogin")，成功才替换 CK（沿用既有安全语义）。
    自动化身份取最早的超管做 created_by，权限给 login:view_all 以免受归属限制；
    总时长上限压到 240 秒，避免长时间占住调度线程；
  - settle_results() 独立成纯函数便于单测：成功清空退避状态；失败按分型分流 ——
    captcha/credential 转人工（不排期）、email_quota 退避到次日零点+随机抖动、
    email_code/interrupted/network 走 1h→3h→12h→24h 阶梯；次数用尽也停下等人工；
  - 未知文案默认按可重试处理（有每日上限兜底），别把可能只是抖动的账号推给人工；
- 注册第二个作业「CK 自动重登」（batch 10 / 并发 3，**默认关闭**）；
- 新增 GET /api/automation/manual-queue：按原因分组列出待人工处理的账号。可重试
  类型但已无下次排期的（次数用尽）单独成组 —— 否则会混进「验证码失败」里，客服
  看不出这个已经不会再自动试了。

前端：
- /automation 页新增「待人工处理」卡片，按分型分组展示（极验要过滑块、凭证要核对、
  次数用尽要人工确认），各带账号与最近失败原因。

测试：新增 26 条（分型顺序陷阱「上限」优先于「验证码」、退避阶梯、配额退避次日、
候选筛选、MySQL 方言编译、结算、待人工队列分组）。
提交前全量 297 通过、ruff 全绿、前端 tsc 通过。

注意：提交时另一路「测试改用 MySQL」的改造正在同一工作区进行，本次刻意只暂存
本功能相关文件，未触碰 tests/conftest.py、tests/support/ 及对方已转换的测试文件。
 2026-10-02 20:51:19 +08:00
yml2213 65a4590291 refactor(time): 时间列统一走 UTCDateTime，并把 MySQL 会话时区对齐成 UTC 
问题不是「UTC 还是本地时间」，而是这套口径有两个半吊子的地方：

1. 库里存 naive UTC、读出来也是裸时间，于是每一处比较/输出都得自己补时区。
   项目里因此散了三份 _as_utc 和一堆 replace(tzinfo=UTC)，P1a 排下一轮时间
   时还炸过一次 TypeError: can't compare offset-naive and offset-aware。
2. MySQL 会话时区跟随系统 +08:00，而库里存的是 UTC —— SQL 里的 NOW()/
   CURDATE() 比库里的时间快 8 小时，查询会静默返回空（P1a 排查时就遇到过，
   看着像「没有数据」）。

改动：

- 新增 database.UTCDateTime：写时 aware→转 UTC 去 tzinfo、naive 视为 UTC；
  读时一律补 UTC 时区。底层 DDL 仍是 DATETIME，**不需要迁移**。models.py 的
  28 个时间列全部改用它，模型上的时间字段从此不再是裸值；
- docker-compose 给 mysql 加 --default-time-zone=+00:00，让 SQL 时间函数与存储
  口径一致。安全性已核实：全库 0 个 TIMESTAMP 列、0 个 CURRENT_TIMESTAMP
  默认值，改这里不会改变任何已有数据的语义；
- 新增 tests/test_utc_datetime.py：读出必须 aware、能直接和 datetime.now(UTC)
  比较、带 +08:00 的写入要落成 UTC、naive 写入视为 UTC，并有一条元测试扫描
  Base.metadata，防止以后新增时间列忘了用 UTCDateTime。

保留既有的 _as_utc 补丁（对 aware 值是幂等的，属防御性代码）；新代码不再需要。
「存 UTC、算 UTC、显示本地」三条线至此各自明确：存储与比较统一 UTC，日志按
容器 TZ 显示本地时间，前端 formatTime 负责转本地。
 2026-10-02 20:27:07 +08:00
yml2213 f745a61df1 feat(automation): CK 自动巡检（P1a），只检测不改 CK 
后台原本靠人工逐批点「CK 检测」发现失效账号，1.2 万个账号根本盯不过来。
P1a 把「哪些账号失效了」自动化：自动挑久未检测的账号、调现成检测接口、
把结果写回 ck_check_*。**本作业不替换任何 CK**，重登仍由人工点，符合规划里
「先做只读/只提示，确认无误再做自动动作」的渐进上线原则。

实现：
- 迁移 20261002_0037：automation_jobs / automation_runs 两张表，
  login_tasks 加 relogin_attempts / relogin_next_at / relogin_last_error
  （为 P1b 备好），accounts 加 auto_managed（特殊账号不参与自动化）；
- services/automation/scheduler.py：进程内调度线程，60s tick，状态全部落库
  （重启不丢调度进度、不重复跑轮）；AUTOMATION_ENABLED 默认关闭，作业开关
  也默认关闭；ensure_jobs 只补缺失行、不覆盖运维改过的配置；
  作业异常只记 failed，不拖垮调度线程；单容器 --workers 1，无需分布式锁；
- services/automation/jobs/ck_health.py：选行口径与人工检测一致
  （cookie_holding_filter：持有 CK 且无在途尝试），叠加久未检测、
  auto_managed、batch_size，按 ck_checked_at 升序（最久没查的优先）；
  只写 ck_check_status / ck_check_result / ck_checked_at；
- routers/automation.py：GET /jobs、PATCH /jobs/{key}、POST /jobs/{key}/run、
  GET /runs；新增权限点 automation:view（运营可看）与 automation:manage
  （仅超管），改配置与手动触发都写审计；
- 顺带补 POST /api/login/batch 的审计（此前批次是谁发起、多少账号无据可查）；
- 前端 /automation 页：作业卡片（开关/周期/单轮条数/并发）、运行历史、
  「立即跑一次」；总开关未打开、调度线程未运行时给明确提示。

验证：
- 22 条新测试覆盖调度器行为（只跑到点的、异常不抛出、下轮时间、配置不被重置）、
  选行条件（在途尝试/auto_managed/间隔/batch_size）、接口与权限，其中一条
  专门断言巡检后 cookie/status/message/attempt_status 一字未动；
- 全量 257 条通过；前端 tsc 与构建通过；
- 端到端用 3 个真实账号跑真实斗鱼接口：巡检结果与直接调 check_douyu_cookie
  逐条一致（3/3 valid），CK 与尝试状态全程未变。

顺带修掉一处会炸生产的坑：DB 时间列读出来是 naive UTC，直接与
datetime.now(UTC) 比较会 TypeError，现统一走 _as_utc() 补时区。
 2026-10-02 19:47:41 +08:00
yml2213 99db772ddd feat(douyu): 精英宝典支持查询开通状态，开通前先校验且不再误判到账 
线上两个问题：工作台看不到账号有没有开通精英宝典；点开通时二维码会「闪一下
就变小」——大图弹窗 2~4 秒后自动关闭，只剩列表里 56px 的小二维码。

根因：
- getUserInfo 的 manualType/expireTime 才是开通状态的权威口径，但只有兑换
  流程用过一次，没有任务类型对外暴露；前端只看积分列，而「开通后积分花完」
  和「从未开通」都是 0 分，区分不了（实测 13456 manualType=1/score=0）；
- 开通前不查状态，且到账判定写成「积分 >= 300」：账上本来就有 680 分的账号
  在出码后第一轮轮询就被判成功，前端按 paymentArrived 自动关掉了弹窗。

改动：
- 新增任务类型 query_elite_status：查 manualType/manualScore/expireTime 并
  落库到 accounts.elite_opened / elite_expire_time（迁移 20261001_0036），
  精英工作台加查询按钮与「宝典状态」列（已开通+到期 / 未开通）；
- create_elite_qr 开通前先查状态：已开通直接判成功、不再生成支付码（方案 A），
  既消除二维码闪现，也避免给已开通账号开出真实支付单；
- 到账判定改为「积分比开通前增长」，基线用与轮询同源的 credit/balance 取，
  取不到基线才退回旧口径；
- 支付弹窗不再自动关闭：到账/失败/停止都在弹窗里给结论 + 手动关闭；列表小
  二维码在任务进终态后隐藏。

新增 9 条测试覆盖上述行为，回退 runner 时其中 8 条失败。
 2026-10-01 19:08:25 +08:00
yml2213 6a25097412 fix(douyu): 替换 CK 是最后一步，只有登录成功才写回记录 
上一版把可见性改成「记录里还有 CK」，账号不会再消失，但根因还在：批次启动
时就把复用的成功记录改成 pending（旧 CK 仍在），停止或失败后没人恢复状态，
记录一直显示成一次没完成的登录。

按「替换 CK 是最后一步」把两者拆开：

- login_tasks 新增 attempt_status / attempt_message / attempt_batch_id /
  attempt_at，批次只写 attempt_*，status/cookie/message 只在登录成功时更新；
- _begin_attempt 只登记尝试，_mark_attempt_failed 只记录失败（已有 CK 的记录
  原样不动），_write_login_success 是唯一替换旧 CK 的入口；
- 停止批次、代理不可用、登录异常、进程重启清理全部改为收敛 attempt_*，
  因此停止一个批次不可能再让账号失去 CK；
- 复用的记录改用「持有 CK 的记录」，不再创建第二条记录，失败记录在无 CK 时
  才复用；
- 登录任务列表/统计按 attempt_* 展示「这次登录怎么样了」，批次筛选同时匹配
  attempt_batch_id；CK 操作页的重登状态也从 attempt_* 映射；
- 迁移 20261001_0035 归一存量数据：持有 CK 的记录 status 统一为 success、
  历史状态搬进 attempt_*，无 CK 且卡在 pending/running 的收敛为 failed。

新增测试：批次失败/停止不碰旧 CK、成功后替换 CK、列表展示尝试状态、
迁移存量数据归一。
 2026-10-01 18:29:49 +08:00
yml2213 8309072120 统一推送前Python代码格式 2026-09-05 19:25:46 +08:00
yml2213 61eb434138 双份cookie存储：raw_cookie 保存App原始凭据，与网页运行ck分离 
网页运行ck（cookie列）含本地随机生成的网页设备字段，若被风控标记
无法还原纯净登录凭据；新增 raw_cookie 保存16字段App原始态，供
设备态重建/审计/复核登录有效性。

- HuyaAccount 加 raw_cookie 列（alembic 0034，MySQL TEXT nullable）
- HuyaLoginResult 加 raw_cookie 字段；App登录链补齐前快照原始凭据
- upsert_huya_cookie 支持双写；app-password-login 路由透传 raw_cookie
- 存量行 raw_cookie 为 NULL（老账号无快照），新登录自动填充
 2026-09-01 23:15:20 +08:00
yml2213 26514b332d 完成虎牙宝典WSS绑定与快照隔离重构 2026-09-01 12:40:22 +08:00
yml2213 955ba45488 虎牙精英宝典 2026-08-31 19:34:59 +08:00
yml2213 b58c6b4357 执行 Ruff 安全自动修复 2026-08-31 10:28:14 +08:00
yml2213 17577ff734 type: 渐进式接入 Pyright 并类型化 ORM 模型 2026-08-30 19:44:01 +08:00
yml2213 13b5aedd1d test: 全面迁移 pytest 并加入格式门禁 2026-08-30 19:19:32 +08:00
yml2213 3ce1c7a51b test: pytest 工程化落地 — 本地门禁、容器测试镜像、迁移链冒烟测试 
- 门禁: 本地 pre-push 钩子（.git/hooks，推送前强制跑全量 pytest）
- Docker: 新增 test 镜像阶段（含 dev 依赖与 tests），compose 提供
  --profile test run --rm test 入口；dev.sh 支持 ./dev.sh test
- 测试基建: 根目录 conftest.py 统一 DATABASE_URL/APP_ENCRYPTION_KEY，
  移除 9 个测试文件内的重复 setdefault（含多余 import os）
- 迁移冒烟: tests/test_migrations.py 校验链线性、脚本可编译、空库整链
  upgrade head 后与 Base.metadata 表/列/索引对齐
- 修复冒烟测试发现的漂移: YybRechargeTask.task_id 冗余 index=True
  （唯一索引已覆盖，迁移链未建普通索引，模型与真实 schema 对齐）
- alembic.ini: path_separator=os 消除弃用告警；README 补测试章节
 2026-08-30 18:54:00 +08:00
yml2213 d6ab4d8699 feat(web): 虎牙账号管理界面优化 — 登录渠道区分 (Web 旧版 / App 协议 / 短信) 
后端:
- HuyaAccount 新增 login_channel 字段 + 迁移 20260829_0030 (启动自动升级)
- 5 个登录端点成功后记录渠道: web/app 批量与单账号 + 短信
- HuyaAccountOut 输出 login_channel
前端:
- 账号表新增『登录渠道』列 (App 协议/Web 旧版/短信/仅导入)
- 工具栏登录按钮分组: App 协议登录(primary 推荐) 与 Web 登录(旧版, Tooltip 说明)
- 行内操作新增单账号 App/Web 登录按钮 (复用批量端点传单 id)
- tsc + vite build 通过
 2026-08-29 13:13:57 +08:00
yml2213 7fe6228901 增加充值审计日志 2026-08-14 11:52:30 +08:00
yml2213 e2a45b7893 优化斗鱼充值日志与配置 2026-08-14 11:27:53 +08:00
yml2213 0bf69c1240 优化斗鱼充值 2026-08-13 21:43:27 +08:00
yml2213 902e669614 功能: 接入鱼翅供应商直充渠道 2026-08-13 21:11:20 +08:00
yml2213 cf3fe68de3 功能: 按用户同步斗鱼工作台 2026-08-13 15:47:07 +08:00
yml2213 090698e6b2 fix: harden user management operations 2026-08-13 15:07:33 +08:00
yml2213 5074faf9f6 优化了部分支付宝界面 2026-08-12 19:12:22 +08:00
yml2213 d19c0902f2 初步增加, 扫码登录成功 2026-08-12 16:22:55 +08:00
yml2213 b962f63bd2 feat(cookies): CK 有效性检测(双接口) + 结果持久化 
- 检测: 鱼丸余额(fishBall) + 用户等级(userLevelDetail)双接口均通过才判有效,
  附带鱼丸数/昵称/等级, 失败时分别说明原因, 8 并发批量检测
- 持久化: login_tasks 新增 ck_check_status/ck_check_result/ck_checked_at,
  刷新翻页不丢失; 列表与详情接口返回检测字段
- 前端: 新增"有效性"列(有效/无效+鱼丸昵称tooltip)与独立"检测时间"列,
  行内/选中批量检测按钮(cookie:view 权限), 加载时初始化历史检测结果
 2026-08-06 20:58:23 +08:00
yml2213 a515ea6e0a feat(douyu): 和平小店扭蛋碎片查询 + 深色模式修复 + 任务状态 WS 即时推送 
- 碎片: 新增 query_xpd_fragments 任务, 复用 e语言 gamecoin 接口取扭蛋币 jb2,
  账号已存角色回退(规避 Livelink 风控), accounts.xpd_fragments 字段与迁移
- 列表: 和平小店移除鱼翅/限制兑换/换绑时间列, 新增扭蛋碎片列;
  操作区硬编码白底改用 theme token, 深色模式适配(三个手册共用)
- 轮询: 任务状态经 WS(level=task)即时推送(二维码/绑定进度即时展示),
  pending/running/终态全覆盖, REST/WS 载荷统一 douyu_task_payload,
  raw 快照递归剥离, HTTP 轮询降频 5s/30s 兜底
 2026-08-06 20:21:28 +08:00
yml2213 fdc74eba8c feat(douyu): 新增和平小店查询模块(绑定角色/商品列表/点券余额) 
- activity_client: getIframeUrl 签发 code/sig,道聚城 getrole.out/recommend/balance 接口
  (2026-08 起需 isCode=1 + authType=delegate + sAnchorId 才能通过 Livelink 校验)
- 迁移 0016: accounts xpd_* 字段、douyu_config 小店配置(actAlias/actId/rid)、
  douyu_xpd_goods_snapshot 商品快照表
- runner/service/router/schema 注册 query_xpd_role/refresh_xpd_goods/query_xpd_balance
  三个任务,任务结果剥离 role.raw 防 openid 泄露
- 前端: 和平小店路由/菜单/DouyuTasksPage 三态/商品下拉/配置弹窗
 2026-08-06 17:23:59 +08:00
yml2213 a466e11c9c 优化斗鱼绑定状态同步 2026-08-02 17:54:36 +08:00
yml2213 8de269f958 增加兑换 2026-07-28 18:12:11 +08:00
yml2213 624198bca4 优化电竞手册换绑时间展示 2026-07-28 17:27:35 +08:00
yml2213 d7a8666fe4 新增电竞手册独立绑定流程 2026-07-28 17:12:08 +08:00
yml2213 62099e8d68 新增斗鱼活动任务模块：绑定、宝典、鱼翅、积分、兑换等功能 
- 新增 activity_client.py：封装斗鱼活动/兑换/充值/送礼接口
- 新增 cookie_utils.py：Cookie 解析与规范化工具
- 新增 douyu_service/douyu_runner：斗鱼任务服务层与批量执行器
- 新增 douyu 路由：任务类型查询、账号列表、配置管理、商品管理、批量任务、WebSocket 日志
- 新增 models/schemas：DouyuTask/DouyuConfig/DouyuGoodsSnapshot 模型，Account 扩展点数/鱼翅/绑定状态等字段
- 新增数据库迁移：斗鱼活动相关表与 accounts 字段补充
- 新增前端 DouyuTasksPage 任务操作台页面
- 兑换商品请求添加 sec-ch-ua 反检测头
- 兑换商品支持最多 8 次重试 + csrf_token 自动刷新
- 注册 douyu:task / douyu:config 权限点
- 侧边栏新增斗鱼分组与任务操作台菜单入口
 2026-07-24 16:11:39 +08:00
yml2213 e18b2c6e0c 虎牙自动注册持久化成功流水与批次，支持失败续跑与随时导出 
将注册批次/条目/成功记录落库，成功一个写入一条流水；服务中断可恢复并续跑失败项，换电脑也能导出 txt。同时修复 pending 被误判为运行中导致页面卡住的问题。
 2026-07-12 20:05:04 +08:00
yml2213 2203420146 虎牙支持先导入账号密码再登录 2026-07-05 20:47:16 +08:00
yml2213 5513b5a313 实现虎牙充值商品列表与支付二维码 2026-07-04 23:48:53 +08:00
yml2213 5b84f82a2e 优化虎牙默认配置 2026-07-04 18:10:03 +08:00
yml2213 e1d47a85be 新增虎牙账号和任务基础功能 2026-07-04 16:31:12 +08:00
yml2213 83345dfdc5 增加了代理平台和日志 2026-06-24 14:22:29 +08:00
yml2213 177ec42416 加密敏感数据并优化补CK流程 2026-06-24 09:10:31 +08:00
yml2213andClaude Fable 5 52102655ac 修复IMAP连接：支持非SSL端口143 
- IMAP服务器 111.229.206.54 只开放143端口（非SSL），993不通
- 默认配置改为端口143、ssl=False
- EmailVerifier 增加 use_ssl 参数，支持 IMAP4 和 IMAP4_SSL
- Account 模型增加 email_imap_ssl 字段
- 数据库迁移：新增列 + 修正旧数据端口和SSL设置
- 导入账号时自动填充 ssl 配置

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-06-22 20:58:31 +08:00