hhhge/NeteaseUrl
Archived
1
0 Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity
79 Commits 1 Branch 0 Tags
046225e38d30c74f8cbb8f4743aff8ecdda32b73
Commit Graph
6 Commits
Author SHA1 Message Date
snowy-yang 0569b50737 refactor: 清理 13 处生产死代码 
为什么：用 AST 级引用分析（而非文本 grep——同名符号会互相掩盖）确认这些
符号全项目零引用。文本 grep 查不出的原因是它们都有「活着的同名兄弟」：

services/downloads.py（共 6 个，93 行）
  _parse_cookie_str / _global_music_u / _vip_name / _detect_vip /
  _admin_client / _user_client
  —— 活的是 core.media.parse_cookie_str、web/routers/music.py、account.py 的版本
  随之失效的 import：USER_COOKIE_FILE / GLOBAL_MUSIC_U_CACHE / VIP_PROBE_LOCK /
  account_info / detect_vip_by_probe / QRLoginClient

services/api_service.py
  APIResponse 类（29 行）—— web/response.py 才是活的响应封装

services/_shared.py
  _rate_ok —— 逐字复制 web.ratelimit.rate_ok

core/utils.py
  safe_int / safe_console_print —— 活的是 web/request_utils.safe_int

core/repo.py
  all_settings / get_user_by_name —— auth_system.get_user_by_name 才是活的

core/db.py / web/auth_state.py / web/request_utils.py
  execute_many / _safe_register_credits + secrets_rand / dedup_ids

结果：生产代码死代码候选 13 → 0（余下 118 个全是 pytest 测试函数，属正常）。
 2026-09-26 18:54:11 +08:00
snowy-yang bd3a4ac70b fix: 统一 core/auth_system 的数据目录解析，消除脑裂隐患 
为什么：`core/db.py` 认 SITE_DATA_DIR、`auth_system/db.py` 写死 Path('data')，
而两处指向的是**同一个** data/site.db。web/main.py 的文档字符串还宣称
「数据目录可由 SITE_DATA_DIR 覆盖」——只有 core 侧做到了。

后果：只要运维真的设置 SITE_DATA_DIR，站点库（用户/账本/卡密）与
core 侧读的设置/公告就会落到两个不同文件，且**不会报错**——
表现为「设置改了不生效」「公告消失」这类极难排查的诡异现象。
全仓 grep 确认该变量当前只出现在 core/db.py 与 web/main.py 两处，
没有任何测试或部署在用，所以是纯隐性隐患。

顺带修一个实测到的坑：`os.environ.get('SITE_DATA_DIR', 'data')` 的默认值
只在变量**缺失**时生效，`SITE_DATA_DIR=`（空串，compose/K8s 里很常见）
会让 Path('') 退化成当前工作目录，数据库静默落到 CWD。改用 `or 'data'`。

验证：四种取值（未设置 / 空串 / 绝对路径 / 相对路径）下
core.DATA_DIR == auth_system.DATA_DIR 且 DB_PATH 相同，全部一致。
 2026-09-26 14:15:58 +08:00
snowy-yang 183f5744d8 fix: 修复 7 处变量可能未绑定的真缺陷，类型检查升到 standard 
为什么：IDE 里成片的黄色波浪线并非风格噪声。ruff 与 pyright(basic) 都是
0 报错，但 basic 会整体漏报「变量可能未绑定」这类**可执行缺陷**；实测
standard 多报 7 处且全部为真——异常处理器引用了尚未赋值的局部变量，一旦走进
异常分支就会 NameError 二次崩溃，把原始异常彻底掩盖。

- core/db.py, core/http_client.py：3 处 @asynccontextmanager 的返回标注
  AsyncIterator[X] 更正为 AsyncGenerator[X, None]（前者不含 send 语义）
- core/state.py：三个模块级缓存补 TypedDict 建模。原先无标注的 dict 字面量被
  推断为「所有值类型的并集」（float | None），每个读写点都退化成联合类型；
  拆成 _VipCache（data 可为 None 表示未探测）与 _VipEntry（data 必定存在）后，
  类型检查立刻抓出 account.py 对未探测缓存的直接解包隐患
- services/batch.py：zip_valid 提到函数头。ZIP 构建前的业务错误（参数缺失/
  无歌曲）会 early raise，而异常处理器引用了该名字 → NameError 二次崩溃
- services/podcast.py：radio_name、pct 同理补初始化
- services/downloads.py：声明返回 str 却可能给出 None，改 `or ''` 满足契约
- web/routers/download.py：id_list 提前绑定
- web/auth_state.py：解包出的 c 未被使用
- pyproject.toml：typeCheckingMode 由 basic 升到 standard 作为门禁，并移除
  已被 standard 覆盖的 reportGeneralTypeIssues

门禁：ruff All checks passed · pyright(standard) 0 errors 0 warnings
 2026-09-26 13:54:23 +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
snowy-yang c77ef40fd5 feat(db): 同步栈读写并发（_q 去锁）+ core.db 并发/跨loop 修复 
auth_system._q：单语句读不再持 _DB_LOCK —— WAL 下每连接读一致性快照，
读写互不阻塞；旧实现把全部读也串行化且被写挡住。写事务（_x 与 24 个
with _DB_LOCK 块，经扫描均为写事务）仍全程串行，无写-写竞争。

core.db 并发修复（由测试暴露的真实缺陷）：
- WAL 切换竞态：并发连接同时执行 PRAGMA journal_mode=WAL 争排他锁
  → 专用锁内串行切换 + 二次复查（busy_timeout 前置）
- 跨事件循环锁：模块级 asyncio.Lock 绑定首个 loop，多 loop 场景报
  "bound to a different event loop" → 锁按 loop 隔离

测试：25/25 通过（新增「读不被写锁阻塞」红转绿、读+同步写者并发 WAL、
异步并发读）；
lint: ruff All checks passed；pyright 0 errors。
验收：冒烟 10/10、奇偶校验 2/2、uvicorn 真实启动 Flask 兜底+FastAPI 双通。
 2026-09-26 01:03:18 +08:00
snowy-yang 9f56f68b66 chore(async-infra): 异步基础层 + 工具链 + 清理 
异步基础层（core/）：
- db.py   aiosqlite + WAL：读路径无锁并发、写路径 asyncio.Lock 串行，
          busy_timeout 自旋——实现「读写同时进行」（旧实现用 RLock 全读串行）
- http_client.py  aiohttp 连接池 + 有界重试（5xx 重试 / 4xx 不重试）+
          响应体上限 + 流式接口；按事件循环隔离 session（支持迁移期双 loop）

工具链：
- pyproject.toml   ruff(E/F/W/I/B/UP/C4/ASYNC/S/RUF) + pyright(basic) + pytest(asyncio auto)
- requirements-fastapi.txt  FastAPI/aiohttp/aiosqlite/aiofiles 等目标栈
- requirements-dev.txt      开发依赖（pytest/ruff/pyright）

清理：删除无用脚本 _csscheck.py 与产物标记 _css_ok.txt/_pkg_ok.txt，同步 .gitignore

验证：pytest 10/10（含「写 200 条同时 4 读协程零异常」并发用例）；
ruff All checks passed；pyright 0 errors。
 2026-09-26 00:24:00 +08:00