外部审计对 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-02
当前入口
- 自动化与资料收集规划:CK 自动管理、资料收集链接、皮肤台账与半自动工单的分期计划(规划中,未开工)。
- 皮肤准入映射分析:C 桶皮肤类到斗鱼商品目录的归一与覆盖分析(923 个快手名 → 78 个斗鱼商品,覆盖率 40.1%)。
- 虎牙 Cookie 路线状态:当前实现、字段状态、验证边界和后续工作。
- 虎牙网页设备字段溯源:浏览器证据、字段来源和生成算法。
- 虎牙 Cookie 合并审计与来源矩阵:字段来源约束和合并策略。
- 虎牙精英宝典联调指南:工作台联调顺序和只读验证方法。
虎牙业务与协议
- 虎牙精英宝典 9.1 全流程分析
- 虎牙精英宝典后端与抓包对照
- 虎牙精英宝典 8.31 Python 重分析
- 虎牙精英宝典联调指南
- 网页 Cookie 缺失字段历史方案
- 虎牙 App 登录总览
- 虎牙纯 Python 自动登录总结
虎牙设备与加密逆向
- HDID 算法生成
- HDID 研究记录
- 标识符命名规范
- 铸币机终局总结
- App 登录协议抓包实证
- App 登录 WUP 明文抓包
- App 登录加密算法动态验证
- App 登录 APK 静态分析
- App 登录逆向笔记
- 扫码登录闭环逆向
- hyCred 签发侦察笔记
设备注册与运行工具
鱼翅充值接口
文档约定
- 带日期的抓包和逆向笔记属于历史证据,结论以对应日期为准。
- 当前代码行为和未完成项以“虎牙 Cookie 路线状态”为准。
- Cookie、UID、订单号和设备标识进入文档时使用脱敏值;真实数据只保存在本地 evidence 目录。
- 兑换、下单和支付属于写操作,除非明确确认,不纳入自动回归测试。