Archived
snowy-yang
e8cc7cb34a
为什么：文件 IO 这条线上 to_thread 用得过宽。凡是「单文件 exists / unlink / stat」 这类微秒级元数据操作，线程调度开销（几十微秒起）比操作本身还大，套 to_thread 只是 给同步调用加了层异步外壳，不产生任何并发收益；真正需要卸载的是整库复制、ZIP 整段 拷贝、SQLite 探测这类活。本批按这个口径把两端都摆正，并顺手修掉一处真实缺陷。 改动： - web/routers/admin_site.py 备份上传：原 `content = await f.read()` 会把整库一次性 读进内存（端点对外无大小上限，等于给了上传方一个内存放大器），落盘后还要把文件 重新打开读一次头。改为 _save_upload_stream 按 1 MiB 逐块搬运——内存占用恒为一块， 文件头在写第一块时就地截获（省掉那趟回读）。仍属阻塞 IO，故保留在 to_thread 里。 - web/routers/admin_site.py backup_list：撤掉仅为一次 stat 而拆出的嵌套函数 + to_thread，直接在事件循环里做完。 - web/routers/admin.py：save_cookie / logout / _get_cookie_info 四处 to_thread 改 直接调用——它们读写 1KB 级的 cookie.txt，全程不碰网络。 - music_api/qr_client.py：logout() 的 print 改 logger。该方法既被 CLI 也被 admin 端点调用，在 web 语境里 print 会把内容直接喷到服务端 stdout，绕过 logging 配置、 无法被收集，也污染容器日志。 - auth_system/backup.py：三处单文件 unlink（占位文件回滚、删备份、裁剪 pre_restore_） 改直接同步；把只为配合 to_thread 而拆出的 _backup_path_sync 并回 backup_path。 保留在线程里的：整库 copy2 / os.replace、glob + N 次 stat、SQLite 探测、以及持 跨线程锁的 _reserve_backup_path（内联会让事件循环等一把别的线程可能持有的锁）。 - web/routers/delivery.py：两处 os.path.exists 改直接同步（带 ASYNC240 行内豁免， 与 core/db.py、auth_system/db.py 同一写法），顺带删掉随之未使用的 asyncio 导入。 - pyproject.toml / uv.lock：移除 aiofiles。它全仓零引用，且底层同样是 to_thread—— 对 1KB 的 cookie 文件不会带来任何真异步收益。 验证： - uv run ruff check . → All checks passed! - uv run pyright → 0 errors, 0 warnings, 0 informations - uv run pytest → 392 项，0 失败 / 0 error / 0 skipped （含 test_admin_backup_upload 四条：接受真实 SQLite / 缺字段拒 / 后缀拒 / 后缀对但内容非库必须拒且不留半成品） - data/site.db sha256 前后一致（a19f5dbf…6487），无 -wal/-shm 残留