dachui/live-hub-py
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
481 Commits 3 Branches 0 Tags
7aaaeebe2b135a8ffe6f8a0468ffde4cd35cc34a
Commit Graph
481 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
yml2213 7aaaeebe2b fix(automation): 修正调度口径——作业每 5 分钟跑一轮，interval_seconds 只是单行重检间隔 
P1a 把两个「间隔」混成了一个：next_run_at 用的是 job.interval_seconds，于是
作业 6 小时才跑一轮、每轮 200 条 = 800 条/天，全库 12,881 条要 16 天才能过
一遍 —— 等于没巡检，与规划里「账号 6 小时内被查一次」的目标差了两个数量级。

按规划原意修正：
- TICK_SECONDS 60 → 300：作业每个 tick（5 分钟）跑一轮；
- next_run_at 改为 finished + TICK_SECONDS，不再用 interval_seconds；
- interval_seconds 只作为「同一行多久重新检测」的选行 cutoff（选行逻辑本来就
  是这么用的，无需改）；
- 容量口径随之更新：5 分钟一轮 × 200 条 = 40 条/分钟 ≥ 需要的 36 条/分钟，
  冷启动约 5.4 小时覆盖全库，稳态每轮一百多条；
- 前端标签由「巡检周期(小时)」改为「单账号重检间隔(小时)」，说明文案写清
  「每 5 分钟跑一轮」，避免运维误以为是作业周期。

同步更新规划文档 §7.2/§7.3（含两个间隔不能混的说明）与附录 C 的三段上线
步骤（立即跑一次 → 每轮 50 观察 → 每轮 200 启用）。
 2026-10-02 19:54:31 +08:00
yml2213 2379598800 docs(plan): 记录迁移编号不能改名的坑，并说明应用过后的对齐做法 
P1a 的迁移先叫 20261002_0038，本地 dev 库应用过之后为保持链条连续改名成
0037，dev 库的 alembic_version 还记着旧编号，再启动就报
Can't locate revision identified by '20261002_0038'。

结论写进附录 C.1：编号要在被任何库应用之前定下来；已经应用过又必须改名时，
除改文件外还要把每个应用过的库 UPDATE alembic_version 对齐（前提是迁移内容
未变）。
 2026-10-02 19:48:47 +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 6537d77323 chore(gitignore): 忽略 .env.bak* 与 backups/，防口令和账号数据误提交 
原规则只忽略 .env，改 .env 前留的备份（.env.bak-时间戳）虽然未跟踪但**未被
忽略**，一次 git add -A 就会把数据库口令提交进仓库；backups/ 目录同理，服务器
上那份 login_tasks 全量备份有 33MB 账号数据。
 2026-10-02 19:34:37 +08:00
yml2213 6a62bbe70f docs(plan): 新增自动化与资料收集规划与皮肤准入映射分析 
把「CK 全靠人工维护 / 资料靠人转述 / 兑换无台账」整理成分期规划，并基于两套
线上库的实测数据定下关键口径。

数据结论（2026-10-02 实测）：
- order_site 271,134 单按履约路由二选一且完全不重叠：A 有 fulfillment_tasks
  85,338 单（88.3% 已 delivered，是发货平台的活）、B 有 work_orders 96,755 单
  （打手）、C 两者都无 89,542 单 —— 只有 C 是「没人管」，才是本系统的目标；
- 斗鱼可兑换商品只有 78 个（皮肤类 60）。C 桶皮肤类 923 个快手商品名映射过去：
  62 个唯一命中（27.7% 件数）、14 个命中多个（12.4%，需用户选）、847 个斗鱼
  兑不了（59.9%）—— 准入白名单以斗鱼商品目录为准，不匹配就不建单；
- order_items.spec_json 已带 sellerId/relItemId/relSkuId/skuNick，(itemId, skuId)
  才是单订单的精确定位键（4,092 个数字 skuId 中 89% 唯一），接单平台就是按
  sku_exact/sku_series 匹配的，本系统照此设计；
- CK 巡检规模 12,881 行（valid 10,079 / invalid 905 / 从未检测 1,897），按 6h
  周期反推 batch_size 应为 200 而非 50，否则实际周期被拉长到 21 小时。

规划要点：
- 与 order_site 整合选只读直连 PG：order_site 零代码改动，跨库 SQL 只允许出现在
  一个适配层文件里，另配降级开关与只读保护参数；
- P1 拆成 P1a（只检测、不改动任何 CK）与 P1b（自动重登，默认关闭），按「渐进
  上线」原则逐步减少人工；
- 用户截图一律进私有 OSS 桶 + 后端鉴权代理读图，不落本地磁盘；
- P4 的规则/模板/状态机对齐 order_site 接单平台：资料模板固定为游戏编号 +
  游戏昵称 + 主页截图，皮肤由订单号自动对应，仅多选类让用户选一件；
- 取消规则映射层（与 skin_aliases 职责重叠），规则直接挂 commodity_id，
  连带去掉 rule_ambiguous 状态。

三轮复核：① 补齐结构与缺口（术语表、P0 章节、权限表、配置清单、保留策略、
文案、测试计划、风险回退、迁移与文件清单、施工单）；② 逐条核对代码事实
（路径/符号/接口/字段/迁移 head/测试基线全部命中）；③ 找出并修掉 8 处实现级
矛盾（选择结果无处存、365 天命中的状态缺失、draft 悬空、多选回链断点、P4 与
P1b 排期矛盾、映射层重叠、P2 能力错位、用户回看链接缺失）。

含：docs/自动化与资料收集规划.md、docs/皮肤准入映射分析.md，并更新文档索引。
 2026-10-02 19:34:37 +08:00
yml2213 2bdabc4e03 fix(compose): 补容器资源限额，并修正数据卷默认值以防错挂空卷 
一、内存 / CPU 限额
douyu-login 与 mysql 此前均为 unlimited（Mem=0、NanoCpus=0）。本机 7G 且与
order_site 共用，任一方内存失控都会把整机拖垮（order_site 曾因此被 OOM kill）。
现各限 2G / 2 核；可用 DOUYU_LOGIN_MEM_LIMIT、DOUYU_LOGIN_CPUS、MYSQL_MEM_LIMIT、
MYSQL_CPUS 在 .env 覆盖。

二、修正 mysql-data 的卷名默认值（重要，防数据事故）
原默认值 live-hub-py_mysql-data 是**另一个空卷**，真实数据在项目改名前的
douyu_login_py_mysql-data（4G+）。由于该行改动之后一直没重建过容器，
隐患一直没暴露；2026-10-02 第一次重建容器即挂到空卷，
表现为数据全丢（douyu_tasks 由 228475 行变成空表）。

现默认值指向真实卷，并默认 external: true（不再由本项目创建/删除该卷，
docker compose down -v 也不会把它删掉）。修完不再依赖 .env 是否设置该变量。
 2026-10-02 19:34:29 +08:00
yml2213 168421b40c fix(douyu): 恢复二维码常驻显示，绑定类任务终态也要能看到码 
上一版加了「任务进终态后隐藏账号列表里的小二维码」，但绑定类任务等不到扫码
时会以 success 收尾（douyu_runner_bind: "已生成绑定二维码，未检测到新扫码
角色"），url 仍在结果里，码却被藏掉，客服再也点不开 —— 绑定/电竞绑定/小店
绑定都受影响。

二维码的意义与任务终态无关：只要 result 里还有地址就一直显示。这里恢复
taskQrUrl()，删除 activeTaskQrUrl 与 QR_TERMINAL_STATUSES。

「开通时二维码闪一下就变小」不会复发：根因是支付弹窗被自动关闭 + 已开通账号
被误判到账，现在弹窗不再自动关，且已开通账号在开通前就被拦下、根本不生成
支付码。
 2026-10-02 09:14:40 +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 4d87cdc16d fix(douyu): 取邮箱验证码取错邮件，导致登录永远报「邮箱验证码错误」 
线上现象：同一个邮箱每次登录都取到同一个旧验证码（UID=1、几小时前那封），
提交必然失败；整体重试 20 次又把斗鱼的发信配额打爆。

两个根因：

1. Roundcube 返回的邮件列表本来就是 UID 降序（最新在前），代码又 reversed()
   了一次，于是从收件箱最旧的一封开始读；
2. _parse_rc_date 用 UTC 作为基准，而 Roundcube 显示的是邮箱本地时间，旧邮件
   被凭空加了 8 小时，看起来比发送时间还新，时间过滤形同虚设。

改动：

- 发信前用 latest_douyu_uid() 记录收件箱最新斗鱼邮件 UID，之后只接受 UID
  更大的邮件，精确锁定「本次发送触发的那封」，不再依赖列表顺序和日期解析；
- 明确按 UID 降序读取，去掉多余的 reversed()；
- 日期解析改为本地时区 aware datetime，时间兜底过滤才真正生效；
- 斗鱼返回「邮箱验证码发送次数已达上限」时抛 EmailQuotaError，直接终止批次
  不再重试，避免继续烧配额。

线上实测（忧伤的心750 / aakpfc@bdhg.xyz）：修复前每次读 UID=1 的旧码
942715；修复后基线 UID=20、按发送时间与快照过滤均正确跳过旧邮件，正文读取
取到最新一封。
 2026-10-01 18:42:56 +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 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 1ac6a13a2c fix(audit): 修复审计日志时区差并支持供应商单号搜索与展示 
- 解决审计日志 8 小时时区差：后端输出带时区 UTC ISO 字符串，前端 formatTime 增加 UTC 自动解析换算
- 审计日志支持单号检索：list_audit_logs 关联 DouyuTask 匹配供应商单号、外部单号、UID、昵称等
- 列表摘要与详情抽屉优化：摘要直观展示供应商单号与外部单号，抽屉增加专用供应商订单列表并支持一键复制
- 增加测试用例覆盖时间格式与单号反向检索
 2026-09-12 14:52:26 +08:00
yml2213 4518b726ac feat(huya): 浏览器兑换三目标直达并收窄扩展注入范围 
- 操作列改为「直播间 / 精英宝典 / 电竞宝典」三个直达按钮，点哪个就按哪个目标写入登录态并打开，去掉弹窗内选择
- 新增 services/huya_exchange_targets.py 统一三个目标地址，接口支持可选 body {"target": "..."}（不传=精英宝典）
- 扩展内容脚本从 <all_urls> 收窄到后台站点白名单，service worker 校验 sender.tab.url，拒绝其它来源的注入
- 注入改为 Cookie 写完后回执（ok/written/failed/error），前端按回执提示成功或失败，不再静默
- 扩展图标兜底改用 world:'MAIN' 读取；一个 Cookie 都没写成功时不打开目标页
- 兑换材料签发写审计 huya:exchange:kit（含账号与目标）
- 控制台脚本增加 huya.com 域校验与 Secure，与扩展路径保持一致
- 修复兑换记录轮询的跨账号串扰与卸载后 setState；兑换请求加 epoch 防止过期结果覆盖弹窗
- 新增 tests/test_huya_browser_exchange.py（13 项）并同步 docs/HUYA_BROWSER_EXCHANGE.md
 2026-09-11 10:31:46 +08:00
yml2213andCursor 874a95dd6f chore: 提交和推送前增加前端 TypeScript 检查 
与 Docker 构建的 tsc -b 对齐，避免类型错误在服务器构建才暴露。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-10 11:45:35 +08:00
yml2213andCursor c1f4e7c7ae fix(huya): 修复账号页登录队列状态比较导致的前端构建失败 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-10 11:42:41 +08:00
yml2213andCursor e0810a9c0b style: 按 ruff 格式化登录队列代码并跳过已删除文件的推送检查 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-10 11:32:29 +08:00
yml2213andCursor e81119117f feat(huya): 多选登录改单线程队列并拆分路由与工作台 
默认同时只登一个号，失败两次跳下一个，号间留间隔，结束后可一键重试失败账号。
顺带拆分虎牙路由与斗鱼工作台页面，并补齐 raw_cookie 重建入口。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-10 11:31:50 +08:00
yml2213 8dea9e3244 style(huya): 全面重塑虎牙账号管理页面UI视觉与交互体验 2026-09-06 14:08:51 +08:00
yml2213 cbc7f7c9c5 fix(huya): 优化账号密码导入交互并将导入类型严格限制为四段格式 
- 交互优化：将账号标签选择器移至弹窗顶部，避免下拉列表向下展开时遮挡底部的'确定'/'导入'按钮
- 格式限制：严格限制仅允许'账号----密码----手机号----接码链接'四段格式导入
- 前后端校验：前端逐行校验格式并提示具体错误行号，后端限制 require_four_segments=True 兜底
 2026-09-06 14:00:24 +08:00
yml2213 d3005478a9 feat(huya): 支持四段式账号导入接码及旋转/文本点选多级验证码闭环过验 
- 账号导入：支持'账号----密码----手机号----接码链接'四段式解析与持久化存储
- 旋转验证码 (rotate_auth / xz)：逆向分析官方协议，基于圆周边界采样互相关算法秒级计算旋转还原角度
- 文本点选验证码 (dx_auth)：内置成语与古诗名句语料，支持题干菜名提取与古诗/成语挖空正则求解及小图动态合成
- 短信二次验证 (sms_auth2)：结合 sms_url 自动轮询接码链接并 Hex 编码提交官方过验
- 前端交互：增加接码标签、在线查询短信验证码、一键自动短信登录与测试接码链接功能
- 回归测试：新增旋转验证、短信接码流与文本点选测试用例（173 passed）
 2026-09-06 13:56:44 +08:00
yml2213 4f9a6864eb 优化验证码展示 2026-09-06 13:02:37 +08:00
yml2213 8309072120 统一推送前Python代码格式 2026-09-05 19:25:46 +08:00
yml2213 90a0065918 虎牙菜单按角色显示并修复确认框暗色模式 
客服在虎牙导航只显示浏览器兑换，管理员/运营保留完整入口；退出登录
与显示凭据确认框改用 App.useApp() 的 modal 实例以适配暗色主题；
版本号升至 0.3.0。
 2026-09-05 19:21:59 +08:00
yml2213 178eba1eea 浏览器兑换独立成页面并按斗鱼模式优化导入 
新增 /huya/browser-exchange 页面（精英宝典下方），支持导入账号与
执行兑换，客服仅见已分配账号；账号管理页移除该功能。导入弹窗对齐
斗鱼操作台：服务端分页筛选、可搜索标签、无 CK 不展示、导入本页/
一键导入全部/导入选中；新增 /accounts/ids 接口与 workbench
browser_exchange scope。
 2026-09-05 18:30:29 +08:00
yml2213 230d6c1918 虎牙人工兑换改用本机浏览器并新增扩展自动注入登录态 
移除服务器浏览器方案（容器/Xvfb/noVNC/CDP 会话管理），后端仅下发
兑换材料；新增内置 Chrome/Edge 扩展一键写入 huya.com 登录态，
未安装扩展时回退控制台脚本手动注入，兑换始终由用户手动完成。
 2026-09-05 17:55:31 +08:00
yml2213 95ad900ef0 统一推送前Python代码格式 2026-09-02 18:11:41 +08:00
yml2213 aaaa568916 修正活动WSS会话guid一致性 2026-09-02 18:07:31 +08:00
yml2213 92ba6cbc62 闭合QIMEI h38兼容键 2026-09-02 17:51:12 +08:00
yml2213 1f3773de28 修正QIMEI UUID42随机段生成 2026-09-02 17:15:06 +08:00
yml2213 17ee943753 复刻QIMEI UUID42并默认使用无头浏览器 2026-09-02 16:59:46 +08:00
yml2213 c62c025ced 整理虎牙文档并接入设备画像指纹 2026-09-02 13:42:32 +08:00
yml2213 2a1b1e642c 优化虎牙精英宝典工作台与Cookie生成 2026-09-02 12:48:41 +08:00
yml2213 0d21a3fa09 trace文档补充：逆向生成器全链路验证通过（含真实兑换成功） 2026-09-01 23:53:28 +08:00
yml2213 8fef04d0af web_cookie_fields 用逆向算法替换随机：__yamid_new=UUIDv1时间戳复刻、game_did=35位63字符集、_yasids同源、_qimei_uuid42=1a前缀、guid回退加固定段 2026-09-01 23:48:00 +08:00
yml2213 8b24732c81 文档：网页设备字段溯源实证——5字段服务端下发/其余浏览器脚本生成，定位QIMEI SDK 0.6.3与guid固定段 2026-09-01 23:34:30 +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 3ae1c3de1e 文档：浏览器注入ck未登录根因=domain需带前导点(.huya.com)，host-only仅主域生效 2026-09-01 23:02:40 +08:00
yml2213 45da352668 登录链补齐网页设备字段并修正udb_appid为5002 
App模拟扫码登录只产出16个udb_*认证字段且udb_appid=5008(App渠道)；
真实网页登录态是41字段+udb_appid=5002，缺字段注入浏览器会导致
UDB SDK判定设备态不完整。登录成功返回前用 fill_web_cookie_fields
补齐guid/qimei/yamid/game_did等字段并强制udb_appid=5002。

实测：16字段App ck -> 41字段网页形态，checkLogin=isLogined:true、
cookie/verify returnCode:0，与8.31真实扫码登录抓包一致
 2026-09-01 22:44:42 +08:00
yml2213 0839fc5947 文档记录商品/兑换全链路验证：getActPrizeList/Detail/Records 全 200，scoreExchangePrize 往返成功(604积分不足) 2026-09-01 22:29:59 +08:00
yml2213 416dc2585b 文档补充三通道cookie依赖矩阵：商城WSS/HTTP RPC原始cookie即可，仅活动WSS需补齐 2026-09-01 22:23:13 +08:00
yml2213 9b0ef63eca 文档补充端到端验证：query_game_name/query_points 均 success 2026-09-01 22:16:38 +08:00
yml2213 5dc736516f 补齐网页Cookie缺失字段并接入会话自动预取guid 
- 新增 core/huya/web_cookie_fields.py：4 核心设备字段（guid 取自 wsLaunch 会话、
  _qimei_uuid42/__yamid_new/game_did 随机对齐格式）+ qimei 皮肤 + 22 个统计/会话字段
- elite_session 活动通道初始化时若缺网页字段，先 wsLaunch 预取服务端认可 guid，
  补齐 cookie 后重建会话；业务 RPC 统一走补齐后的 cookie
- 实测：账号 id=58（原始 16 字段登录态）checkUserBindGameAccount status=200
  （和平精英已绑定/收麦季）、getUserScore status=200（积分 4880）
- 附补齐方案与浏览器实测来源记录 docs/HUYA_CHAT_缺失字段补齐方案.md
 2026-09-01 22:12:58 +08:00
yml2213 61ce0c9672 WSS连接不信任环境代理避免SOCKS劫持 2026-09-01 20:30:01 +08:00
yml2213 9f3e3a74ce 修正活动WSS AUTH帧对齐9.1抓包字节 2026-09-01 20:25:31 +08:00
yml2213 727c32a5f5 接入匿名设备态协议补齐Cookie字段并放宽保存 2026-09-01 19:29:56 +08:00
yml2213 8447ca82ed 真实浏览器抓包与匿名设备态协议生成器 2026-09-01 19:17:36 +08:00
yml2213 48c37bb8d7 虎牙网页Cookie来源驱动合并与WSS传输门禁 2026-09-01 19:17:32 +08:00
yml2213 8e3c0e69bc 修正虎牙活动wsLaunch包封装 2026-09-01 12:56:37 +08:00
yml2213 5a1456e3cb 修正虎牙活动WSS初始化序列 2026-09-01 12:52:26 +08:00