snowy-yang
|
4d3204213e
|
refactor: resolve_episode_url 阶梯构造拆解(58 行 / 圈 19 / 嵌套 3 → 36 行 / 圈 12 / 嵌套 2)
为什么:播客单集直链解析的唯一入口,前 20 行是降级阶梯的嵌套构造
(if 套 for 套 if),与尝试循环混在同一个函数里,改音质口径要通读全函数。
拆出:
- _falldown_order(模块级纯函数):降级尝试序列——auto→通用阶梯原序 /
已知音质→向下后缀 / 未知音质→该音质优先+通用阶梯,去重保序收敛为
dict.fromkeys;_FALLDOWN_LADDER 从函数内上移模块级
- resolve_episode_url 只剩尝试循环;song_id 的 int 防御上提循环外
(循环不变量:原实现首轮即判、失败直接 None,url_v1 从未收到过坏 sid)
先写测试后动代码:新增 tests/test_resolve_episode_url.py 11 例,在未改动
实现上一次跑绿,钉住核心口径——「只向下不向上」(standard 绝不回退到
exhigh,历史坑)、未知音质前置、垃圾 song_id 零请求、APIException 降级、
data[0] 无 url 降级、结果映射缺省值。
门禁:ruff 全过 · pyright 0/0 · pytest 370 passed(359→370)。
|
2026-09-27 11:00:50 +08:00 |
|
snowy-yang
|
d2e6856899
|
refactor: get_playlist_detail 批次拉取拆解(94 行 / 圈 24 / 嵌套 3 → 60 行 / 圈 9 / 嵌套 1)
为什么:歌单解析的唯一上游通道,94 行单函数把「歌单头解析 / trackIds
分批拉明细 / 失败批次记账 / incomplete 标记 / 错误映射」五件事揉在
一个 try 里;曲目字段映射与搜索歌曲路逐字段重复。
拆出(模块级,与 search_music 拆解同风格):
- _song_base_fields:歌曲条目公共字段(搜索/歌单共用同一容错口径),
_map_song_item 改为其加 type 键的包装
- _playlist_track_ids:trackIds → 字符串 ID 列表
- _collect_playlist_tracks:批次循环整体(失败批次计数、脏 ID 跳批、
明细缺 id 跳过、incomplete 判定输入),嵌套 3 是批次语义固有,
集中在单一职责函数内
保留语义:脏 ID('①'.isdigit() 为真但 int() 抛 ValueError)跳过整批
且不计 failed_batches;批次阶段网络错误仍映射「获取歌单详情请求失败」。
先写测试后动代码:新增 tests/test_playlist_detail.py 11 例,在未改动
实现上跑绿(修正 1 例测试自身的替身消费顺序),覆盖此前零测试路径——
playlist:null 防枚举、业务 code 错误、非 dict 响应、批次失败记账、
脏 ID 跳批、100/批分批、错误映射。
门禁:ruff 全过 · pyright 0/0 · pytest 359 passed(348→359)。
|
2026-09-27 10:53:48 +08:00 |
|
snowy-yang
|
e00ac14460
|
refactor: search_music 四路映射拆解(101 行 / 圈 32 / 嵌套 6 → 42 行 / 圈 7 / 嵌套 1)
为什么:站内搜索的唯一上游通道,101 行里 if/elif 四路条目映射占了
2/3,错误映射与字段容错口径(歌曲 artists 空缺兜底未知歌手、专辑
不兜底、alias 缺省 '' 等)全埋在分支里,改一路要通读全函数。
拆出(模块级,与既有 _ensure_dict 同风格):
- _map_song_item / _map_album_item / _map_artist_item / _map_playlist_item
——四路口径原样,docstring 标注各路容错差异
- _SEARCH_RESULT_KEYS + _SEARCH_ITEM_MAPPERS 派发表(未知类型不在表内
→ 空结果,原 if/elif 无 else 行为一致)
- _collect_search_items 统一「取键 → 无 id 跳过 → 映射」
先写测试后动代码:新增 tests/test_search_music.py 12 例,在未改动
实现上跑绿(修正 1 例替身形状:网络异常必须抛垫片自己的
RequestException,aiohttp.ClientError 由 aiohttp_compat 内部翻译,
直接抛底层是不存在的形状)。契约测试不为违反 offset: int 签名的
None 入参背书(防御性 int(offset or 0) 保留,不测)。
门禁:ruff 全过 · pyright 0/0 · pytest 330 passed(319→330)。
|
2026-09-27 09:42:07 +08:00 |
|
snowy-yang
|
095171e0b7
|
refactor: 两个根级游离模块并入 music_api 包,消除分层倒置
为什么:podcast_api.py(560 行) 与 qr_login.py(397 行) 既不属于任何包、也不是
入口脚本,却同时被 services 层与 web 层引用——`services/downloads.py` 直接
`from qr_login import ...`、`services/podcast.py` 直接 `import podcast_api`,
业务层反向依赖顶层游离模块,是本次架构体检里唯一的无争议分层倒置。
两者本就依赖 music_api(前者取 url_v1/APIConstants/APIException,后者取
QRLoginManager),与 music_api 下已有的 qr.py / compat.py 是同一层的同类物。
迁移(git 保留重命名历史):
- podcast_api.py -> music_api/podcast.py
- qr_login.py -> music_api/qr_client.py
**命名避让**:不叫 music_api/qr_login.py——music_api/__init__ 已经从 .compat
导出了一个**同名函数** qr_login,同名子模块会与之互相遮蔽。改叫 qr_client
(其核心导出即 QRLoginClient),并在验证里专门确认 music_api.qr_login 仍是
可调用函数、music_api.podcast 是模块,两者不冲突。
内部导入顺带改为精确子模块,不再绕道包门面:
- podcast.py:from music_api import APIConstants/APIException/url_v1
→ from .compat import url_v1 / from .constants import ... / from .errors import ...
- qr_client.py:删掉那层 try/except ImportError 包装(它给的是「请确保
music_api.py 文件存在」这类顶层脚本时代的提示,作为包内模块已无意义),
改 from .cookies/.errors/.qr 相对导入
- CLI 用法文本 python qr_login.py → python -m music_api.qr_client
(相对导入后直接跑脚本会失败,必须走 -m;全仓确认无脚本/文档引用旧入口)
- 路径安全性已核对:qr_client 用的是 CWD 相对的 cookie.txt,不是 __file__ 相对,
迁移不改其解析结果
引用点全部更新(AST 扫描确认覆盖全集,替换后残留 0):
- podcast:services/podcast.py(1 + 5 处调用) · web/routers/podcast.py(1 + 6)
· web/routers/download.py(2 处函数内 + 3),导入名统一为 `podcast`
- qr_login:services/downloads.py · web/routers/admin.py · web/routers/user.py(×2)
- services/__init__.py 依赖自检列表去掉这两个名字(已并入 music_api)
- pyproject include 去掉两个顶层文件名(music_api 目录已覆盖)
验证:
- 11 + 3 个符号在新位置全部 hasattr 通过;podcast_api / qr_login 已
ModuleNotFoundError;6 个调用方模块均可 import;services 依赖自检仍生效
- 门禁:ruff 0 · pyright 0 errors/0 warnings · pytest 184 passed
- 真实 uvicorn 冒烟 10/10,含 /podcast/parse 与 /podcast/hot 返回 401
(模块导入失败会是 500,路由缺失会是 404,401 证明两者都正常)
- 生产 data/ 指纹 before == after
|
2026-09-26 15:03:47 +08:00 |
|
snowy-yang
|
d600b6a630
|
refactor: crypto 改用手写轮子的标准替代,去掉重复的函数内 import
- hex_digest:`"".join([hex(d)[2:].zfill(2) for d in data])` → `data.hex()`。
前者每字节做一次 hex()+zfill 再拼接,后者是 C 实现;两者输出相同。
- hash_hex_digest:绕道 digest() → hex_digest() 两步,直接 hexdigest()。
- _aes_encrypt / encrypt 里的函数内 import 删除:模块顶部已导入
Cipher/algorithms/modes/padding,函数内又导一遍纯属冗余;
base64、secrets 则提到模块顶部(原来每次调用都要走一次 import 查找)。
- PKCS7(128) 保留字面量并加注释:**不要**改写成 algorithms.AES.block_size
——它在类型存根里声明为 property 而非 int,pyright 会报 reportArgumentType
(本次实测踩到,门禁拦下)。
等价性验证:encrypt_params 对固定 payload 的输出 sha1 保持
76e3738f8eab61fcfd1145164ba8e1f91d40ee4f 不变;hex_digest/hash_hex_digest
的输出逐字符相同;并做了 docstring 逐条比对确认无文本误伤。
|
2026-09-26 14:16:05 +08:00 |
|
snowy-yang
|
6288a98ecc
|
refactor: 拆分 4 个巨石模块为包,清理过时注释并删除作废文档
为什么:单文件 1100~1900 行的巨石模块让「改一处要通读全文」;同时注释里残留
大量已删台账的编号,以及「Flask/FastAPI 双栈迁移期」这类已失实的架构描述,
会误导后来者按不复存在的架构去改代码。
拆分(对外导入路径不变,行为零变更):
- music_downloader.py -> music_downloader/(models/downloader/cover/_http/_log/_concurrency)
- auth_system.py -> auth_system/(db/security/users/credits/ledger/mail/cards/backup...)
- music_api.py -> music_api/(api/client/crypto/qr/cookies/compat/constants/errors)
- services/runtime.py -> services/(api_service/_shared/_taskcore/downloads/batch/podcast/
streaming/tasks);services/runtime.py 保留为兼容门面
兼容性做法:各包用 __init__.py 以 __all__ 原样再导出全部符号,既有调用点
(auth_system.xxx / services.xxx / from music_api import Y)零改动;路径常量改为经包属性
动态读取(auth_system.DB_PATH),否则测试的 monkeypatch 会静默失效并写到生产库。
修复 9 处代码损伤(上一轮注释清理把 `()` 当「空括号残留」删掉所致;用「与拆分前逐字
等价」校验逐一定位,静态检查只会报出其中 4 处):
- core/config.py ).strip() or '*'
- core/state.py threading.Lock() x2
- qr_login.py datetime.now() / .strip()
- music_downloader/downloader.py .lower()
- services/podcast.py set() / time.time() x2
清理与删除:
- 删除 部署文档.md / 功能介绍.md / README_私有包警告.txt
- 清理指向已删台账与文档的过时编号注释;把「迁移期 / 两栈 / 双框架 / 已迁移」等
失实描述改写为现状描述(保留 `<-> Flask /path` 映射表等仍有价值的契约来源说明)
- _mkpkg.py:公开包剔除清单去掉已不存在的文档名;私有包警告改为自包含
- pyproject.toml:补 pythonpath = ["."],使裸跑 pytest 不再 import core 失败
验证:ruff 全通过;pyright 0 errors / 0 warnings(102 文件);pytest 144 passed;
真实 uvicorn 冒烟 6 条路由符合预期且生产 data/ 指纹未变;忽略注释的逐字等价性校验通过。
|
2026-09-26 12:37:48 +08:00 |
|