dachui/live-hub-py
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
589 Commits 3 Branches 0 Tags
dev
Commit Graph
33 Commits
Author SHA1 Message Date
yml2213 224b147735 Merge branch 'main' into dev: 同步充值渠道切换修复 2026-10-08 11:53:26 +08:00
yml2213 ec07e4fc06 fix(config): 修复切换充值渠道报错及补齐 peace_enabled 字段声明 
- 在 DouyuConfigOut 与 DouyuConfigUpdate 中补齐 peace_enabled 声明与序列化
- 在 update_config 中使用 getattr(req, field, None) 安全读取属性，避免 AttributeError 导致 500
- 在 _config_out 中加入 peace_enabled 输出映射
- 增加切换充值渠道与配置更新的单元测试
 2026-10-08 11:49:41 +08:00
yml2213 7c1a6caf47 fix(config): 补充 peace_enabled 字段声明并增加安全属性读取 
- 在 DouyuConfigOut 与 DouyuConfigUpdate 中加入 peace_enabled 声明与序列化
- 在 update_config 中使用 getattr(req, field, None) 做安全兜底，避免 500
 2026-10-07 16:19:23 +08:00
yml2213 18bc7be4b1 feat(pool): 账号自动分配与回收（租约 + 补给链 + 独立工作台） 
在既有「管理员分配 → 客服导入工作台 → 手动选号」之外**新增**一条
「客服选皮肤 + 数量 → 系统分配账号 + 按需补积分 → 用完自动收回」的路径。
旧路径只做并集与可选参数扩展，行为不变（有用例守着）。

- 归属与使用权分离：新增 account_leases（生成列 + 唯一索引，并发抢号由数据库裁决），
  assigned_to 收窄为管理员/运营的维护责任；客服可见范围扩为「名下 ∪ 租用中」
- account_pool 服务：候选筛选、两梯队排序（先花快过期的 / 先选充值少的）、
  供给与成本预估、租约领取/释放/回收
- 补给链：查余额 → 充鱼翅（单次 ≤800 元，超限拆单）→ 赠精英令 → 兑换；
  运行期两道闸门：_skip_when（余额已够就别再花钱）、_depends_on（前置未成功就跳过）
- 转人工：鱼翅支付等 10 分钟未到账转 manual_required，租约先不还；
  account_lease_reaper 兜 TTL 到期 / 漏释放 / 孤儿批次
- 运营流水：业务事件补 actor_id = task.created_by；账号详情页展示操作人、渠道
  与租赁记录
- 新工作台：/douyu/pool + 菜单「账号分配台」（新建，不改造旧工作台）
- 修复 D1：官方补录的兑换事件漏写 subject_key（10,612 条主键为空），
  会让 365 天同皮肤规则漏判 87% 的历史；补代码 + 回填脚本
- 迁移 20261007_0052；权限 account:pool_use / account:pool_admin

测试：766 passed, 6 skipped（改动前基线 727）；ruff 与 tsc -b 干净。
设计稿与实施记录：docs/设计-账号自动分配与回收.md
 2026-10-07 12:29:08 +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 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 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 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 64c399617a fix(douyu): 账号只要还持有 CK 就不再从工作台消失 
线上事故：分配给客服的账号（如「远行者103」）在斗鱼工作台与 CK 列表里
查不到，只有账号管理里还能搜到。原因是可见性判定写成了
LoginTask.status == "success"，而按设计保留旧 CK 的三种状态都不再是
success：

- 普通登录批次启动时会把复用的成功记录置为 pending/running（旧 CK 保留），
  批次被停止或失败后一直停在 pending，账号永久消失；
- CK 重登失败置为 relogin_failed（旧 CK 保留），账号从工作台消失；
- 普通登录失败置为 failed（复用记录的旧 CK 未清空），同样消失。

线上现状：12545 个账号持有 CK，但只有 11703 个能出现在工作台，842 个
（644 重登失败 + 176 排队中 + …）对客服和管理员都不可见。

改动：
- douyu_service 新增 cookie_holding_filter()/latest_cookie_login_task()，
  以「记录里还留着 Cookie」作为唯一判据，并抽出 LOGIN_IN_FLIGHT_STATUSES
  与 cookie_operable_filter() 供检测/重登入口复用；
- 斗鱼工作台账号列表、任务账号校验、账号管理 has_cookie 筛选、分配校验与
  概览、CK 管理/操作列表、首页 CK 统计统一改用该判据；
- 工作台取 CK 从 latest_success_login_task 换成 latest_cookie_login_task，
  保证重登失败/排队中的账号仍能被任务正常执行；
- 新增 cleanup_orphan_login_tasks()：进程重启后把遗留的 pending/running
  收敛为 failed 并保留旧 CK，避免页面永久显示排队中。

新增回归测试覆盖上述状态下的可见性、可执行性与启动清理。
 2026-10-01 18:18:02 +08:00
yml2213andCursor 4806d4bbf1 feat(douyu): 精英宝典导入支持按多行账户名筛选 
对齐 Cookie 自定义 CK 的粘贴导入方式，按账户名精确匹配并保持粘贴顺序。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-29 15:02:53 +08:00
yml2213 b58c6b4357 执行 Ruff 安全自动修复 2026-08-31 10:28:14 +08:00
yml2213 ec3c14d0a3 type: 收窄斗鱼任务路由类型 2026-08-30 20:02:03 +08:00
yml2213 9497e1ace6 perf: 优化 MySQL 查询并接入 pytest 2026-08-30 18:26:54 +08:00
yml2213 1ed1eac205 同步客服充值渠道配置 2026-08-14 14:00:51 +08:00
yml2213 644a9b118f 区分斗鱼充值审计方式 2026-08-14 13:29:54 +08:00
yml2213 7fe6228901 增加充值审计日志 2026-08-14 11:52:30 +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 c77e8f4641 feat(douyu): 支持工作台分页与一键导入 2026-08-07 23:06:08 +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 5f63d77dc3 feat(douyu): 和平小店绑定功能(生成绑定二维码/查询绑定信息) 
- activity_client: xpd_bind_qr(roleParam 签发 livelink 绑定链接, 微信扫码进小程序绑定)
  + xpd_bind_info(bindInfo 查询绑定状态/角色/平台), gameRole 非 dict 边界防护
- runner/service: 注册 get_xpd_bind_qr / query_xpd_bind_info 任务, 回写
  xpd_game_name / xpd_bind_status
- router: get_xpd_bind_qr 的 url 加入列表接口保留白名单(二维码展示)
- 前端: 和平小店面板新增两个按钮, 二维码列支持 get_xpd_bind_qr 展示/放大
 2026-08-06 17:33:11 +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 25880e91a7 斗鱼客服导入账号 支持tag 2026-08-06 13:20:12 +08:00
yml2213 335f5cf57b 优化首页统计和任务请求 2026-08-05 10:41:40 +08:00
yml2213 2fda47c631 优化任务列表性能和本地登录代理 2026-08-05 10:03:18 +08:00
yml2213 dff0d7db9e feat(douyu): 工作台默认空白账号,导入/移除通过 localStorage 持久化,刷新不再加载全部账号 2026-08-04 16:25:49 +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 df4297bee5 完善客服操作台权限与绑定二维码 2026-07-25 09:45:49 +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