 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
|
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 |
|