20 Commits

Include renames

Author	SHA1	Message	Date
butubb	e348de48d3	feat(upstream): 上游更新检查——定期比上游、落后了推企业微信 ... 本仓库在上游 MediaCrawler 之上加了一整层（见 UPSTREAM.md），可合并流程默认 「有人知道上游动了」。而部署是 git pull --ff-only，只从自己的 Gitea 拉——上游的 提交不主动 fetch 就永远看不见。拖着不合并的代价是复利的：越久越难合。 于是把「上游动了没有」变成一条会自己跑、会推企业微信的通知： * api/monitor/upstream.py：git fetch <url> <branch> 到 FETCH_HEAD，用 rev-list --count HEAD..FETCH_HEAD 算落后数、FETCH_HEAD..HEAD 算领先数。 用 git 而非托管商 API，因为只有 git 知道共同祖先在哪——本仓库含有上游没有的 提交，直接比 tip 会得出错误结论。增量 fetch 只传几个新提交，不会遇到 UPSTREAM.md 里说的「大包必断」。 * 只 fetch 到 FETCH_HEAD：不配 remote、不写 refs/remotes、不碰索引与工作区， 所以不打断正在跑的采集，也不和 deploy.sh 的 git pull 抢锁。 * 挂在调度器 tick 上（不是采集，所以不看 is_busy、不受活跃时段限制——定时检查 放在半夜反而最合适），按 checked_at + 间隔 到期才跑；失败也写 checked_at， 于是 GitHub 不通时是每间隔重试一次，而不是每个 tick 撞一次墙。 * 同一个 tip 只推一次（记 tip 而不是「推过没」），上游真又动了会再推。 * 两个接口：GET /monitor/upstream 只读缓存；POST /monitor/upstream/check 手动 查一次且刻意不推通知——点按钮的人正看着结果。 * 默认关闭，间隔默认一天。 Dockerfile 显式装 git（python:slim 不带，而这是唯一的依赖）；deploy.sh 顺带补上 一个真 bug 的提示：Dockerfile/requirements.txt 变了只 up -d 用的还是旧镜像。	2026-10-10 09:17:06 +08:00
butubb	de9ff58371	feat(monitor): 扫码同时存一份 Cookie，并把登录判定换成权威判据 ... 用户问「现在是不是扫码就能自动获取 cookie」—— 不是，而且这正是那个面板显得没用的根源： 它只干了半件事，扫码**只写浏览器 profile，完全不提取 cookie**（qrlogin.py 里连一行 取 cookie 的代码都没有）。于是： - CDP 开着时任务能用（复用 profile），但 Cookie 面板始终显示「未配置」 - CDP 一关，任务立刻断，因为库里那份 cookie 从来没被填过 现在扫码把两件事一起做了：写 profile（CDP 用）+ 存一份到库（Cookie 注入用）。 两种机制同时填上，开关怎么切都不断。cookie 只在内存里从 qrlogin 传到路由，不进响应体。 同时修掉一个同类 bug：监控侧的登录判定还在用页面里的 window.__INITIAL_STATE__， 而那是**页面加载那一刻的快照** —— 浏览器本来就登录着时它是对的，但扫码是加载之后 才登录的，快照不会翻转，表现为「扫了码却一直停在二维码上」。运营模块踩过同一个坑， 当时只修了那一处。现在两边统一为：拿 cookie 问后台接口「我是谁」。顺带不再需要页面导航， 检测变轻了。 前端：已登录时按钮原先被我藏起来了，面板于是变成一块只能看、不能操作的区域 —— 用户的原话是「没用」。现在两种状态都给按钮，含义不同：未登录=取二维码， 已登录=把当前登录态同步成 Cookie。 测试：tests/test_qrlogin.py 重写（stub 从页面探针换成后台接口），新增「成功会话必须 交出 cookie」「只能取一次」两例。	2026-10-09 13:46:48 +08:00
butubb	f6ddc46d62	feat(notify): 通知拆成「新作品」与「异常」两个开关，异常默认开 ... 问题：cookie 过期导致任务失败，但没有任何通知。查下来不是代码问题 —— notify_enabled 在两个任务上都是 False，而它默认就是关的，事件（run_failed） 也确实生成了，只卡在最后一道闸门。 但那个默认值是错的。代码里的理由是「一条任务列表都推到一个群会很快变吵，所以默认静默」， 这个理由对新作品成立（可能每轮都有），对失败不成立：一次登录态失效意味着这个任务事实上 已经死了，而你不会知道，直到某天发现数据停在几周前。最该被告知的就是这种情况。 现在拆开： - notify_enabled —— 推送新作品，可能每轮都有，默认关 - notify_failures —— 推送异常（登录失效/运行失败/没抓到数据），默认开 事件按开关过滤（build_run_message）：只勾了「新作品」的任务不该因为一次失败被推消息， 反之亦然，否则拆开开关就没有意义。已有任务由 _ensure_columns 补上 notify_failures=1， 所以会自动开始收到异常推送。 列名 notify_enabled 是历史遗留（它早先是唯一的通知开关），语义已收窄为「新作品」， 用注释写明，不做列重命名 —— 那需要单独的迁移，不值为一个内部工具做。	2026-10-09 13:37:02 +08:00
butubb	2e6fa955b0	feat(monitor): 博主组头补上指标合计与本轮增量 ... 折叠之后组头只有「N 篇」，等于把信息藏了起来 —— 折叠应该意味着「收起来但仍可一眼读到」， 而不是「看不见」。现在组头与数据行列对齐，每个指标列给出该博主的合计，下面再带本轮增量 （那才是监控真正要看的）。 合计口径与项目一致：某个指标在所有作品上都是 null 时，合计是 null 而不是 0 —— 「0」是真实值、「null」是不知道，合计成 0 会让「还没采到」看起来像「互动为零」。	2026-10-08 13:58:26 +08:00
butubb	0eb6ba31c5	feat(monitor): 作品栏按博主分组折叠，评论栏改为 博主/作品/评论 三级 ... 先回答现状：跳转作品的按钮本来就有（作品栏每行末尾的外链图标）； 评论栏原本是**两级**（作品 -> 评论），第一级是作品不是博主，所以并不是三级。 - MonitorNote 新增 creator_name（爬虫产出的 jsonl 里本来就有昵称，只是没存）。 存的是**已脱敏**的值（张***三），与项目一贯的匿名化姿态一致 —— 爬虫刻意不落原始 user_id（tools/user_hash.py），所以 creator_hash 是唯一稳定的分组依据。 实测该哈希是无盐 sha256，能用任务目标的 external_id 反算配对。 - 入库时刷新 creator_name：作者改昵称是常事，只在首次写一次会一直显示旧的 - 作品栏：按 creator_hash 分组，组头可折叠（默认展开 —— 折叠的默认值不该藏数据）， 行内跳转按钮加了 title 说明 - 评论栏：一级博主、二级作品、三级评论。_note_meta_map 补上博主维度， 评论流和作品分组都带上它 - 认不出博主的作品归到「未知博主」，不丢 顺带修一个语法错误：JSX 注释放在三元表达式分支里是非法的（那是子节点语法不是表达式）， 移进 div 内。	2026-10-08 09:43:19 +08:00
butubb	b11bbf771a	fix(covers): 封面地址是签名过期而非防盗链，改为本地缓存 ... 实测推翻了之前的诊断。同一批图： 当天签发的地址 /202610080841/... -> 200，带不带 Referer 都一样 隔天的地址 /202610070837/... -> 403，带不带 Referer 都一样 路径里那段时间戳就是签发时刻。所以这是**过期**，Referer 根本不是那个维度 —— 上一轮加 referrerPolicy 是照着错误结论改的，白改。 修法： - 采集入库时每轮刷新 cover 地址。原先只在首次入库写一次，旧作品的地址烂在库里， 而且再怎么重跑也修不回来 - 新增 api/monitor/covers.py：把图下载落盘。图一旦落盘就与签名无关，永远可读 - 下载放在 runner 的 Phase 5（事务已提交之后），不放 ingest —— ingest 的文档写明 No network，往里塞网络请求会毁掉它可离线测试这一点 - 新增 GET /api/monitor/covers/{note_id} 取图。这条路由带鉴权，封面不会被匿名读走 - service 返回本地地址优先，没有缓存时才退回远程 - 每轮只补一批（60 张）：一次跑几百张既慢又会给图床压力，而旧地址本来就在陆续过期， 分摊到几轮反而更稳 顺带修正 NoteCover 的注释 —— 它写着防盗链，而那个结论已被推翻，留个错的注释比没有更糟。	2026-10-08 08:45:30 +08:00
butubb	fa227600fe	fix(creator): 权限开通后的状态显示 + 同步范围可选可查 ... - 权限显示：实测今天 display/status 已变成 1，但 tip 是「数据正在更新中，请耐心等待」， 作品仍是 0 条。原逻辑只在未开通时显示提示条，于是会一边写着「数据已开通」一边列不出 作品，自相矛盾。现在只要后台有话要说就显示，并按状态区分措辞。 - 同步范围：原本写死 90 天，界面上既看不见也改不了。现在可选 7/30/90/180/365/730 天， 与后端校验上限一致。 - 新增 creator_account.last_sync_days，记录上次实际使用的范围 —— 否则界面只能说 「同步过了」，说不清覆盖的是哪一段。选择器也会对齐到它，避免上次同步 1 年、这次 点一下悄悄缩回 90 天。	2026-10-08 07:52:28 +08:00
butubb	bef0a4fbde	fix(creator): 扫码成功却一直停在二维码上 + 运营改为左右布局 ... 【扫码不完成】根因是判据本身。原先读页面里的 window.__INITIAL_STATE__，而那是 页面加载那一刻的快照：监控那边的同一探针能用，是因为那台浏览器的页面加载时就已经 登录了；而扫码是加载之后才登录的 —— SPA 内部确实登进去了，但初始快照不会翻转， 于是检测永远等不到。 改成拿 cookie 直接问创作者后台 /api/galaxy/user/info 我是谁。实测这个判据很干净： 游客也会拿到 a1（所以签名算得出来），但接口直接回 401 无登录信息；只有真正登录了 才返回 user_id。所以「有 a1」什么都证明不了，后台认了才算。 顺带按 5 秒节流 —— 前端每 2 秒问一次，没必要每次都打后台接口。 【弹窗不关】成功后不自动关闭，停在二维码上会让人以为没成功。现在显示账号卡片与原话 提示，1.6 秒后自动关闭并提供一个「完成」按钮。 【已完成结果会残留】take_cookie 取走 cookie 就拆会话，而在飞的轮询会看到 _current 为空 回报 idle，把已显示的成功能擦掉。现在把结果记在模块里重复返回，关闭弹窗时清掉 —— 否则下次打开会立刻显示上次的成功。 【布局】按用户要求改成左右两栏（左账号列表、右数据面板），与监控统一，取消二级菜单。 未选过时默认选中第一个，右栏不会一开始就是空的。 测试：tests/test_creator_login.py 新增 7 例，含「游客会话永不完成」「接口不打满每次轮询」 「临时上下文用完必须关掉」。	2026-10-07 16:40:24 +08:00
butubb	2f5852e311	fix(ui): 运营与扫码登录态没跟着平台走，且两个登录面板分不清 ... 两个 bug 是同一类问题：没做平台门禁。 1) 切到抖音等平台，「运营」仍列出小红书账号。运营读的是小红书创作者后台， 其它平台根本没有对应的后台接口。现在按平台门禁换掉整个视图并说明原因 —— 与 MonitorDashboard / ReportView 用 isWired 的做法一致。 2) 扫码登录面板把小红书的会话当成任意平台的登录态报。它的检测读的是小红书页面的 __INITIAL_STATE__，后端 qrlogin.LOGIN_URL 里也只有 xhs 一项；而标题写的是 「{当前平台}登录态」，于是切到抖音照样显示已登录—— 这是个具体的谎。 现在非小红书直接换掉整个面板（只改标题不够，下面的块读的仍是小红书的状态）。 3) 两个面板的标题都是「登录态」，看不出区别。它们其实是不同机制： - Cookie 面板：存进库、每轮以 --cookies_file 注入子进程 → 改名为「Cookie（定时任务用）」 - 扫码面板：写进浏览器 profile、CDP 模式复用 → 改名为「浏览器登录态（扫码）」	2026-10-07 16:35:12 +08:00
butubb	c2b310c7bf	feat(creator): 新增「运营」模块 —— 多账号扫码登录与创作者后台数据 ... 侧边栏在「监控」右边加了「运营」：账号列表 → 点进二级详情看该账号的数据。 【为什么是独立模块而不是监控的子视图】两者形状不同：监控是公开数据（点赞/收藏/评论/分享）的每轮快照+差分；运营是创作者后台按日期给出的曝光/观看/完播率/涨粉。凭据不同、采集方式也不同 —— 那边要浏览器登录态，这边是纯请求。硬塞进同一个模型会同时污染两边。 【扫码登录的关键差异】监控的扫码把登录态写进浏览器默认 profile（爬虫要复用）。运营要的是 cookie 字符串（纯请求够用），所以每次登录开一个**临时上下文**，扫完取出 cookie 就丢弃 —— 登第二个账号不会把第一个顶掉，也不影响监控那个登录态，十个账号互不干扰。 【决策依据】tools/probe_creator_api.py 的 Phase 0 实测：签名可自造（XYW_：MD5 → base64 → AES-128-CBC，与 xhshow 内置实现常量逐字节一致）；主站 cookie 即可认证创作者后台；接口与参数已与真实页面对齐。 后端： - api/creator/models.py: creator_account / creator_note_stat。**复用 MonitorBase**，这样 create_all 与上一轮改成元数据驱动的 _ensure_columns 会自动覆盖新表 - api/creator/signing.py: XYW_ 签名，带三条实测结论（url= 前缀、appId=ugc、401 与 406 的区别） - api/creator/client.py: 纯 httpx 客户端。字段名尚未亲眼验证过，所以写成多别名匹配；解析不出来存 None 而非 0 - api/creator/service.py: 账号 CRUD 与同步。cookie 绝不进入对外结构，只给 has_cookie - api/creator/login.py: 临时上下文的扫码登录 - api/routers/creator.py: 8 条路由，全部带鉴权 前端： - 侧边栏「运营」+ OperationView（账号列表 → 二级详情）+ AddAccountDialog - 权限状态显眼呈现：pending 时照抄后台原话「已为您申请数据权限，次日可查看」，并说明此时同步返回 0 条是正常的，不是采集失败 测试：tests/test_creator_client.py 新增 48 例，含「cookie 不得出现在对外结构里」这条不变量，以及权限未生效时空壳响应的处理。	2026-10-07 16:30:45 +08:00
butubb	2b9ebdad87	fix(ui): 「每轮最多采集作品数」标签是错的——它是每个博主的上限 ... 爬虫里这个值是在 per-creator 的函数内比较的（client.py get_all_notes_by_creator 的 result 是局部变量），而外层 for 循环遍历全部目标。所以 100 个目标 × 20 篇 = 单轮最多 2000 篇，一篇都不会被丢弃。标签写成「每轮最多」会让人以为超出的会被截掉。 - creator 模式：标签改为「每个博主最多采集作品数」，并实时算出「N 个目标 × M 篇 → 单轮最多 X 篇」 - note 模式：禁用该输入并说明「此项不生效」——get_specified_notes 里没有任何 CRAWLER_MAX_NOTES_COUNT 引用，列出的每个链接都会被逐条抓 - 单轮估算超过 500 篇时给出警告：每篇还要抓最多 max_comments_count 条评论、并发为 1，容易触发限流，也可能跑不完就被默认 1 小时的任务超时中断	2026-10-07 15:46:11 +08:00
butubb	6eff6fcc83	fix: 扫码登录状态可独立查询 + 趋势图改回自适应纵轴 ... 【登录反馈】实测这台浏览器 loggedIn=true，其实早就登录成功了；看不到反馈是判据和设计的问题： 1. 判据不可靠。原先靠 web_session 的值变化判断——对照组显示：一个全新的空 profile 首次访问小红书就会被发一个 web_session，所以「有这个 cookie」什么都证明不了。可信信号是页面自己的 __INITIAL_STATE__.user.loggedIn，但它是 Vue 响应式引用，必须 .value 解包（这就是前面探针读到 [object Object] 和 None 的原因）。 2. 状态绑死在临时会话上。扫码会话是内存状态，进程一重启就没（部署、崩溃都算），面板于是悄悄退回初始态——一次成功扫码看起来像什么都没发生。 改法不是让会话活得久，而是把「登没登录」变成随时可查、与会话无关： - 新增 GET /api/monitor/login/state，直接问浏览器要答案，带 5 秒缓存；force=true 先重载页面再读，用于状态陈旧 - qrlogin 改为常驻 Playwright 客户端 + 复用同一个标签页，并在重启后认领浏览器里已存在的 xhs 标签页，避免堆孤儿页 - 把「读不到状态」与「未登录」分开——前者显示具体错误，不再悄悄显示成未登录 - 面板顶部常驻显示登录态与昵称，带「重新检测」按钮；扫码成功后自动翻转 【趋势图】上一轮改过头了。dataviz 规范里没有「折线图必须从 0 起」这条——基线相关的条文全是讲柱状图的（柱状图用长度编码数值，不从 0 起比例就是错的；折线图用位置编码，轴只需如实框住数据）。改回自适应，保留上一轮修好的左侧刻度栏让范围始终可见；步长收敛到 1/2/5×10ⁿ，全平序列撑开一档避免除零。	2026-10-07 15:42:58 +08:00
butubb	8f4e5586e9	feat(schedule): 任务支持「每天定时 / 每周定时」，用选择器而不是手写 cron ... - schedule.py: 新增调度计算模块（纯函数，便于单测）。三种模式：interval（每 N 分钟）/ daily（选钟点）/ weekly（选星期 + 钟点） - 钟点模式是「固定时刻」而非「固定延迟」——从日历重算，所以某轮跑晚了不会把之后每一轮都拖晚。interval 保持原语义：从上一轮开始计时 - 抖动只加给 interval。给「每天 9:00」也加抖动就成了 9:00–9:01 随机触发，操作者选的时间被悄悄改掉，只会像 bug - 模型 / schema / service: 新增 schedule_mode / schedule_hours / schedule_days / schedule_minute。时钟字段存逗号分隔文本——几个小整数、永远整体读写，单开一张表只会换来 join。interval_minutes 保留且仍是默认值，已有任务不受影响 - service: 改动任何调度字段都按合并后的状态重算 next_run_at。重新启用也算改动，否则停用一个月再打开会带着一个月前的 next_run_at，一保存就立即触发 - 前端: 运行方式三选一 + 小时/星期胶囊多选 + 分钟下拉，并实时预览结果句子。任务卡片改显示后端拼好的 schedule_label，避免列表和编辑器对同一计划给出两种说法 - 校验: 钟点模式至少选一个时间，按周至少选一个星期 tests/test_schedule.py 新增 24 个用例，含「恰好等于当前时刻的档位归属下一天」这个会让调度器自循环的边界。	2026-10-07 15:33:17 +08:00
butubb	242e3a7837	fix(chart): 纵轴自 0 起、刻度归位、数据点恢复为正圆 ... - 纵轴从 0 起，上界取整到好读的数（1/1.2/1.5/2/…）。此前按 [最小值,最大值] 自适应，491→506 这点变化被撑满整个图高、看着像暴涨，且上下两刻度就是 506 和 491 两个几乎一样的数，没有 0 做参照读不出量级 - 刻度线画在 0 / 中值 / 上界，标签贴在各自主线上、放进左侧刻度栏。原来是两个绝对定位的数字浮在图面上，会挤在一起读成一个数 - 数据点恢复为正圆：根因是 preserveAspectRatio="none" 把 600×160 的 viewBox 横向拉满容器，横纵缩放不一致，半径 4 的圆被压成椭圆。改为用 ResizeObserver 量出容器宽度、等比绘图 - 每个数据点都画出来（原先只画末点），点数多时自动缩小半径；悬停热区按点位间距铺满整段，不再固定 12px - 当前值移到标题行，不再浮在图面上遮挡曲线	2026-10-07 15:26:42 +08:00
butubb	89b7b1e825	fix: 封面图不再被图床拒绝，作品栏补上封面 ... - NoteCover: 新增共用封面组件，核心是 referrerPolicy="no-referrer"。小红书图床对带外部 Referer 的请求一律 403，而浏览器对跨域 <img> 默认就会带上本站源作为 Referer —— 于是封面全显示成破图，而 URL 本身完全正常。实测同一张图：无 Referer 200 / 67968B，Referer 为本站 403 / 0B - CommentsFeed: 改用 NoteCover，修掉评论栏封面全部加载失败 - NotesTable: 作品栏此前完全没有渲染封面，补上缩略图；封面缺失时用占位块，避免行高随封面陆续到达而跳动 放在一个组件里而不是就地加属性，是为了让下一个显示封面的页面不会漏掉。	2026-10-07 15:21:29 +08:00
butubb	37ca1b1cd6	feat: CDP 接管开关 + 扫码登录面板 + Docker 部署 ... - runner: enable_cdp_mode 从硬编码 False 改为系统设置 cdp_enabled。服务器部署下爬虫接管已开启远程调试的 Chrome（默认 9222），复用其 profile 登录态；本机桌面默认仍为关，行为不变 - qrlogin: 新增 CDP 扫码登录。Chrome 在服务器上跑于 Xvfb，show_qrcode 依赖的 PIL 桌面看图程序不存在，二维码无处可显示；改为经 CDP 从页面取出二维码交给 WebUI 渲染。刻意复用 browser.contexts[0]（新建 context 是无痕 profile，扫了也白扫），且绝不调用 browser.close()（会连带关掉操作者自己的 Chrome） - webui: 设置页新增扫码面板，替换原本跳到采集页看终端二维码的入口 - Dockerfile / .dockerignore / docker-compose.yml: 服务器部署。host 网络是必需而非图省事——容器里 127.0.0.1:9222 必须落到宿主机回环 - UPSTREAM.md: 补充 gitcode 镜像，用于 GitHub 大包传输必断时补历史	2026-10-07 10:41:11 +08:00
butubb	4e60524f37	feat: 监控面板 / 登录鉴权 / 多平台切换 / MySQL ... 在上游 MediaCrawler 之上新增一层： - 监控层 api/monitor/ —— 多博主/多笔记的定时采集、指标快照差分、报表、 企业微信通知。每轮采集写入独立目录，差分才成立。 - WebUI 登录鉴权 api/auth.py —— PBKDF2 口令 + 服务端会话，/api 全接口防护。 WebSocket 单独加依赖：BaseHTTPMiddleware 对 ws 作用域直接放行，覆盖不到。 - 全局平台切换 + 能力矩阵 —— 如实区分「爬虫模块支持」与「监控层已接线」， 未接通的平台直接拒绝建任务，而不是静默跑空。 - 监控库改用 MySQL 5.7（可回退 SQLite 供测试）：逐表强制 utf8mb4 （服务端与库默认都是 latin1），启动校验所连 schema 以防写错库， 连接池 recycle + pre_ping 应对 MySQL 的 8 小时空闲断连。 修复上游缺陷： - xhs/core.py: 主页抓取失败会跳掉整个博主，导致一条作品都抓不到， 而那份资料只喂给一个空函数。改为尽力而为，失败不中断。 - xhs/login.py: cookie 登录只注入 web_session，冷启动签名会失败。 新增 INJECT_ALL_COOKIES 开关（默认关闭，原有行为不变）。 - requirements.txt: 补上 websockets。它在上游 pyproject.toml 里有声明、 这里漏了，导致 uvicorn 没有 WebSocket 能力，实时日志流从未工作。 改动过的上游文件清单及合并方式见 UPSTREAM.md。 测试：492 passed（另有 1 个既有的 Windows/gbk 上游测试失败，与本改动无关）	2026-10-07 09:58:40 +08:00
程序员阿江(Relakkes)	0ca7b29cf0	feat(media): 重构媒体下载，支持 xhs/dy/ks/bili/wb 五平台 ... 旧实现只覆盖 4 个平台，且把整个文件读进内存、无重试与完整性校验， 代码按平台复制粘贴了 4 份。本次用统一下载器替换： - 新增 media_downloader/：流式写入、Range 续传、指数退避重试、大小校验、 路径穿越防护；B 站 DASH 音视频分轨下载后交由 ffmpeg 无损合流 - 新增 media_platform/<平台>/media.py：从平台原始响应提取媒体地址， 与下载器解耦；快手首次接入下载能力 - 开关：config.ENABLE_GET_MEDIA 与 --get_media，并打通 API/WebUI； 同时修正旧配置项 ENABLE_GET_MEIDAS 的拼写 - 落盘按帖子聚合：{SAVE_DATA_PATH 或 data}/{platform}/media/{内容ID}/ - B 站装好 ffmpeg 时走 DASH 最高画质，否则降级 mp4 直链（产物 video-durl.mp4， 避免低清文件阻塞后续的高清路径） - 删除 4 个 *_store_media.py、AbstractStoreImage/Video 及各 client 的媒体 GET 方法 媒体下载失败只记录日志，不中断爬取主流程。	2026-09-17 22:54:22 +08:00
程序员阿江(Relakkes)	076dcba978	fix: 修复 WebUI 源码缺失、环境检测路径及文档说明 ... - 调整 .gitignore，避免误忽略 webui/src/lib/ 和 webui/src/components/env/ - 补齐 WebUI 缺失的 lib 工具函数、API 封装及环境检测组件 - 修复 /api/env/check 使用相对路径导致启动目录不同时检测失败的问题 - 更新中/英/西三语 README 的 WebUI 开发调试与生产构建说明	2026-07-01 23:32:10 +08:00
程序员阿江(Relakkes)	65ddaa8828	refactor: 将 WebUI 源码纳入仓库,移除打包产物 ... - 新增 webui/ 前端源码目录（React+Vite+TypeScript+Tailwind） - 删除 api/webui/ 中旧的打包静态资源 - 更新 .gitignore 忽略 api/webui/ 构建输出和 webui/node_modules - 更新 README 增加前端构建说明	2026-07-01 23:05:03 +08:00