58 Commits

Include renames

Author	SHA1	Message	Date
butubb	36f41450ae	fix(monitor): 博主改名之后，旧作品上的名字也跟着改 ... 昵称是**博主级**的属性，而作品是逐条刷的：一个博主只有落在采集窗口里的那几条会被 重刷，掉出窗口的老作品会一直留着旧名字。于是改名之后库里一半新一半旧 —— * 作品栏组头取的是该博主名下作品的 max(name)，**恰好可能取到旧的那个**（比如从 「BBB」改成「AAA」，max 还是 BBB）； * 导出和 SQL 直接看到旧名字。 两处修： 1. ingest 收完这一轮之后，把这一轮看到的 (博主, 昵称) 铺到该博主在本任务下的 **全部**作品上。带上 `!= name` 让没变化的不产生写入。只限本任务 —— 另一个任务里 的同一个人是另一条跟踪线。 2. `list_creators` 的昵称**优先取账号快照**：那一行每次采集都从资料接口重写，是 最新的一份；小红书那条路没有快照，才退回作品上的名字。 顺带把两份 SQL 里的 COALESCE 顺序调成一致（不然查出来还是旧名字）。	2026-10-11 10:08:58 +08:00
butubb	b9aa590814	feat(monitor): 作品标签 —— 词表在设置里维护，作品上贴 ... 和「作品备注」刻意并存，不是一回事：备注是一句话的自由文字，标签是**从一份固定 词表里选的分类**。分类必须封闭，否则「重点 / 重要 / 优先」各写各的，筛就没法用了。 * `monitor_tag`：词表，全局一套（不按平台分）—— 「重点」是给人自己用的心智，不该在 小红书和抖音各定义一遍。颜色存的是**调色板里的名字**，不是色值：Tailwind 的类名是 静态提取的，拼出来的 `text-${color}` 它看不见，线上会静默变无色。 * `monitor_note_tag`：作品↔标签，**多对多**。一条作品可以既是重点又是竞品；只能贴一个 的话人就会跑去备注里写自由文字，这份词表就白建了。全部替换式提交，不是逐个增删。 * 删除标签时**显式删关联**，不靠外键级联 —— 测试跑 SQLite，它默认不开外键约束。 * 组头上的筛选做成平铺开关片，多选是「或」。 顺带：/monitor/notes 现在支持按 tag_id 筛。	2026-10-11 09:16:17 +08:00
butubb	44277600e4	feat(monitor): 组头上加一个跳到博主主页的按钮 ... `creator_hash` 是单向的，拼不出主页地址 —— 所以这个 id 必须在采集时单独存下来。 抖音的资料接口本来就返回 sec_uid，只是之前没落库。 * `monitor_creator_stat` 加 `creator_id` 列（老数据默认空，下一次采集补上）； * 链接在 `adapters.creator_url()` 里拼，**空串是有意义的返回值**：平台不认识、 或者没拿到 id，就返回空，界面据此不画按钮 —— 画一个点开 404 的按钮比不画糟； * 没有作品的博主照样有链接：他恰恰是你想点进去看的那个人。 已知缺口：小红书那条路（爬虫子进程）根本不落创作者资料，所以那边没有链接。	2026-10-11 08:52:51 +08:00
butubb	d52b6942ac	fix(monitor): 作品栏只显示每个博主最新的 N 条（库里一条不删） ... 原来 max_notes_count **只**被当作每轮拉取的条数，落库时从不删任何东西，列表也不按 博主截断。于是超出的作品会一直堆着（21、22、23…），而掉出采集窗口的那些**再也采不到** —— 指标冻在最后一次，看上去却和正在跟踪的作品一模一样。界面上那句「仅显示每个博主 最新的 N 条作品」是假的，后端根本没做这个截断。 现在界面按窗口显示：库是账本，界面是窗口。趋势图、报表、**导出**读的仍然是全量 —— 导出是数据，少几行就是在丢东西，所以 `windowed` 默认关，只有 /monitor/notes 打开。 窗口按**发布时间**排序，不是「最后一次见到」：降级路径（作品列表被风控挡住）会把所有 已知作品都刷一遍，那样每个人的 last_seen_at 都一样，按它开窗等于没开。解析不出日期的 作品**永不隐藏** —— 因为读不出日期就让一条作品消失，比多显示一条糟得多。 只对博主模式开窗；笔记模式的目标本身就是一件作品。	2026-10-11 08:30:10 +08:00
butubb	a42f8e8b2f	feat(monitor): 作品导出里，没有作品的博主也占一行 ... 导出原先是从作品摊出来的，于是「这个号这段时间一条作品都没发」直接从表里消失 —— 而在表里，**消失和「一切正常」长得一模一样**。这类博主恰恰是名单上最该被看见的： 还在涨粉、只是没动静，或者号出了问题。 来源换成 博主 ∪ 作品（和作品栏同一份 list_creators），没有作品的那一行只填博主， 作品那几列留空 —— **空，不是 0**。 顺带把账号级指标加进作品导出（粉丝数 / 总获赞 / 主页作品数）：没有作品的博主那一行 就只剩它们，不加的话那一行等于空行。「主页作品数」是平台上的总数，和下面几列（我们 监控到的作品）不是一回事，所以名字分得开。 排序改成按「这是谁」，同一个博主的行挨在一起 —— 表格是拿去筛和做透视的。	2026-10-11 07:54:26 +08:00
butubb	61808444ad	feat(monitor): 评论接口带上 a_bogus 签名；修好作品导出的空列 ... **评论能采了。** 之前 comment/list 一直回 200 + 空 body，被读成「这条没评论」—— 而它其实只是被网关挡了。缺的就是 a_bogus 签名，仓库里本来就有 （libs/douyin.js + execjs）。签上之后实测 200 / 9960 字节真评论。 只给评论接口签：作品、详情、博主资料三个不带签名也照常返回，而给它们加签名是 没验证过的改动。签名按需 import —— 那个模块 import 时就把 JS 喂给 execjs， 不该拖进监控层热路径。 **作品导出那几列一直是空的。** 列名写的是裸键 liked_count，而作品行的指标嵌在 metrics / deltas 里，row.get() 永远取到 None —— 导出来的表有「点赞/评论/收藏/ 分享」四列，每一格都没有数。原来的测试只断言了「作品ID」，所以没发现。 顺手补上：导出带上 博主备注/昵称、作品备注、发布时间，时间戳格式化成人能读的 形态（原来是一串 13 位毫秒，Excel 里没法看也没法排序）。	2026-10-10 21:09:52 +08:00
butubb	e0581682e1	fix(monitor): 没有作品的博主在作品栏里也要看得见 ... 分组是从作品推出来的（按作品的 creator_hash 归组），于是没有作品的博主根本 不进列表：目标加了、资料采到了、粉丝数就躺在库里，界面上什么都看不见。 而这类博主恰恰是最该看见的 —— 还在涨粉，只是最近没发东西。藏起来正好藏反了。 线上就有一个：5 个目标里 3 个没作品，那 3 个连同已采到的粉丝数一起消失了。 改成 **账号快照 ∪ 作品** 两个来源： * 有快照没作品 → 一个 0 篇的组，备注和粉丝数照常显示，组里写「暂无作品」； * 有作品没快照 → 一个没有账号指标的组（小红书那条路不产生快照）。 /notes 因此多返回一份 `creators`，而不是让前端从作品里推 —— 作品推不出上面 第一类人。组头改读它，`MonitorNote` 上那几个字段降级成「顺着作品问作者」用。	2026-10-10 20:57:07 +08:00
butubb	20e672834c	feat(monitor): 博主的粉丝数，以及给作品起备注 ... 两件都是「作品栏里把这东西认出来」的延伸： * **账号级指标**：作品列表只会说「这条涨了多少赞」，说不了「这个人整个 账号的粉丝在涨还是在掉」。抖音的资料接口本来就有粉丝数/总获赞/作品数， 每轮顺手记一条快照（`monitor_creator_stat`，粒度 = 任务×博主×轮次， 和作品指标同形）。组头显示最近一条。 快照在「一条作品都没采到」的早退**之前**落：作品列表被风控挡住的那一轮， 正是「粉丝还在涨、但新作品没在发现」最该被看见的时刻。 * **作品备注**：博主备注回答「这个账号是谁」，这条回答「这条我要盯着」。 一个博主底下常常只有一两件值得盯的作品，所以不能合并成一条。键取 (platform, note_id)，跨任务共用一份。 两边都守住同一条口径：**不知道就是 null，不写成 0** —— 0 在趋势图上是一条 砸到底的线，和「还没采到」是两回事。	2026-10-10 18:09:03 +08:00
butubb	0a88474c92	feat(monitor): 给博主起备注 —— 作品栏里才认得出「这是谁」 ... 作品栏按 creator_hash 把作品归到博主的组里，可那是个哈希；creator_name 是平台昵称， 粉丝少的号常常认不出。两样都没法把账号对上人。 * 新表 monitor_creator_alias，键取 **(platform, creator_hash)** 而不是按任务： 哈希对同一个 uid 是稳定的，所以同一个博主出现在多个任务里时，备注只填一次。 * list_notes 带上 creator_alias（整体查一次再在内存里取，不是每条作品查一次）。 * `PUT /monitor/creators/{creator_hash}`，空串即清掉那条备注。 * 作品栏的博主组头：**优先显示备注**，起过备注之后平台昵称降成副标题（它仍是有用的 对照）；组头上一个铅笔按钮就地编辑，回车保存、失焦保存、Esc 取消。 Esc 那条要单独处理：取消之后紧接着的失焦会把刚放弃的内容存进去，所以用一个标记让那次 失焦闭嘴。 测试 +6：没起过时是空串、起了会跟着作品返回、**跨任务共用一条**、**不串到别的平台**、 空串清掉、前后空格会被去掉。	2026-10-10 18:00:13 +08:00
butubb	5552e2a2b8	fix(monitor): 抖音任务永远「运行中」—— page.evaluate 卡在一个死掉的标签页上，而我没给超时 ... 用户报「一直在运行中」。库里那条 run 是真的卡住了：日志里一条采集输出都没有， 说明它卡在 collect 里、还没走到任何日志。探针定位到： 标签页: [''] ← 一个 URL 为空的标签页，渲染进程已卡死 context.cookies(): OK, 90 个 ← cookie 读得到 page.evaluate('navigator.userAgent'): **永远不返回** 而问浏览器要身份（UA + client hints）是采集的**第一步**，`page.evaluate` 又**没设超时** —— 于是整轮挂在那儿，run 永远停在「运行中」。 三处修复，各挡一层： 1. `page.evaluate` / `context.cookies()` 全部加超时（8 秒）。卡住就跳过，不再无限等。 2. 不假设第一个标签页是好的：逐个试、优先抖音页；全都不行就临时开一个干净页问完关掉。 拿不到就退回库里那份 cookie —— **不编造指纹**，那比没有更糟。 3. **进程内那条路补上整体超时**：爬虫那条靠 `run_and_wait(timeout=...)` 兜底，这条路 没有子进程、没人管，里面任何一次卡住都会变成永久的「运行中」。 测试 +6：卡死的页会被跳过（真 sleep，验的正是超时）、没 UA 的页跳过、全不行时开临时页 并关掉它、优先抖音页；以及整轮卡住时 run 不会停在 running（含超时原因）。	2026-10-10 17:51:54 +08:00
butubb	9e13a7f686	fix(monitor): 抖音任务的 run 永远停在「排队中」—— 我上一版把状态标记缩进错了 ... 用户报的现象：任务一直显示「排队中」。查库确认有两批 run 卡在 pending（任务 7 的 44/45、 任务 15 的 62/63）。两个原因，一个是我上一版改坏的： 1) **`RUN_RUNNING` 被我缩进进了爬虫那条分支。** 抖音走的是另一条路，于是它**从不标记 「运行中」** —— 建完 pending 那一行就直接进采集，中途一旦出事（异常、进程被重启）， 状态就永远停在 pending。这是我加平台分岔时把原本在两条路公共位置的一行挪进去了。 2) **`recover()` 只收 `running`，够不着 `pending`。** 那行是上一轮建的、后面的采集却 根本没机会开始（进程重启），它永远不会自己往前走。于是重启也救不回来，界面上就是 一个永远「排队中」的幽灵。现在 pending 一起收。 两处都补了测试：抖音路的 run 必须在**采集开始之前**就已经是 running（这条改回去就会 失败）；recover 要把 pending 也标成 interrupted。	2026-10-10 17:47:41 +08:00
butubb	9f70cd0924	fix(monitor): 抖音「作品」模式的目标被当成博主去查，白废一条本来能用的路 ... 两种模式的**目标是不同的东西**，原来的 fetcher 却一条路走到底： * 「作品」模式（粘贴作品链接）—— 目标本身就是作品 id，直接取详情即可。**这个接口没被 那道真校验挡，今天就能用。** * 「博主」模式 —— 目标是主页 sec_uid，要先拉作品列表；那个接口被挡，退化成刷新已知作品。 原来两种都去调 author_videos（它要的是博主 sec_uid），于是「作品」模式的监控拿作品号当 sec_uid 去查，必然失败 —— 而且失败原因说得很难懂（接口回你「未登录/不是浏览器」）。 结果就是：**新建「作品」模式的抖音监控永远抓不到东西**，而那本来是现有条件下唯一能用的。 现在按 mode 分岔。测试 +2：作品模式必须走 detail 且**不得**去调列表接口（走错了会 直接抛断言）；一件作品坏掉不连累其他作品。 顺带记一条排查结论：博主主页的 HTML 里**没有**作品列表（RENDER_DATA 解出来只有 {isLogin, statusCode, isSpider}），所以「走页面 HTML 免接口」那条路也是死的。	2026-10-10 17:30:28 +08:00
butubb	95b1be2c2e	fix(monitor): 一轮产物里重复的作品会让指标快照撞唯一键，整个 run 崩掉 ... 跑真任务时踩到的： sqlalchemy.exc.IntegrityError: (1062, "Duplicate entry '7-7690458980574358513-45' for key 'uq_note_metric'") 根因是我上一版写错了一处作用域：退化路径里那个「遍历已知作品」的循环写在了**目标循环内部**， 所以任务有多个目标时，同一批已知作品会被拉两遍 → 同一件作品在一轮里出现两条记录 → ingest 给同一件作品写两份本轮快照 → 撞 (task_id, note_id, run_id) 唯一键。 两处都修，各挡一层： * douyin_fetch：去重集合挪到 collect 的最外层，**跨目标**只算一次；退化时也先查一遍 已知作品是否已刷过。 * ingest：`_ingest_notes` 对「一轮里重复出现的 note_id」免疫。一层在源头、一层在入口， 因为产物里重复并不罕见（多个目标指向同一个人、上游重跑、退化路径），不该靠上游自觉。 测试 +2：多目标时已知作品只刷一次；同一轮里重复的作品只落一份快照（这条会崩在 唯一键上，所以它测的正是运行时的那个崩法）。	2026-10-10 17:24:08 +08:00
butubb	3b6a437e6c	feat(monitor): 抖音监控改走新的 Web 接口客户端（接上上一版的移植） ... 上一版只把客户端写出来、验证了它单独可用，**但没有接进任何地方** —— 所以你建的任务跑起来 仍然在调爬虫子进程，报的仍然是那句自己编的「account blocked」。这一步把它接上。 * runner 的 Phase 2 按平台分岔：dy 走进程内 HTTP 客户端（douyin_fetch），其余平台照旧走 爬虫子进程。抖音那条不再起 Playwright、不再构造那串自相矛盾的浏览器指纹参数。 * 新增 douyin_fetch：把采到的东西写成 store/douyin 那套 jsonl 形状 —— **ingest 完全不知道 数据是从哪来的**，重采样/差分/事件/通知/报表全都照旧，一个字没改。 * 失败不再假装：一条都没采到就以非零退出码 + **真实原因**交给 ingest，落成 「采集进程异常退出（code=1）：…」。绝不会再掉进「疑似登录失效」那个分支。 * 已知作品列表接口（aweme/post）被抖音单独加了真校验（200 + 空 body），所以加了退化： 拿不到列表就用库里已知的 aweme_id 逐条走 detail 刷新。**边界是：已知作品的指标能继续 更新，新作品发现不了** —— 这个边界会以一条 warning 日志留下痕迹，不让它看起来一切正常。 * 顺带给客户端补上 video_detail（实测可用：200 / 45425 字节），退化路径靠它。 测试 +6：产物目录与文件名、评论文件即使为空也要建（ingest 靠它区分「没评论」和 「什么都没抓到」）、重复作品只写一次、列表被挡时的退化、彻底失败仍写出产物与原因、 评论失败不连累作品。	2026-10-10 17:21:12 +08:00
butubb	7442bc10b8	feat(monitor): 抖音 Web 接口客户端 —— 绕开爬虫子进程，直接发 HTTP ... 移植自 mac-agent-os 的 mediacrawler_adapter：不起子进程、不开页面，用浏览器里那份 登录态直接调抖音 Web 接口。产物键名照抄 store/douyin，所以 ingest 那条链路一个字不用改。 **目前能用的（真环境实测，非推断）**： profile/other : 200, 7075 字节 —— 博主主页指标（粉丝/获赞/作品数/昵称） aweme/detail : 200, 45425 字节 —— 单条作品详情（含点赞/评论/收藏/分享） **目前不能用的：作品列表 `aweme/post`。** 两个互相独立的原因： 1. 这个接口被抖音单独升级成了真校验：不带 x-tt-argus 回 403「Uifid Not Found」， 带上 dummy 值回 200 + **空 body**。也就是说「头在不在」骗得过，「真校验」过不了。 同一套头打 profile/other 和 aweme/detail 都是通的 —— 抖音是挑着接口加保护的， 挑中的恰好是「批量拉作品列表」这个最敏感的动作。 2. 改走页面截获也不行：CDP 浏览器打开博主主页会落到「验证码中间页」（当天大量探测的 代价，过几小时要重测）。 所以现在的边界是：**已知作品的指标刷新能做，自动发现新作品做不了**。 **排查中控住变量后得到的两条事实**（都写进注释了）： · `Accept` / `Accept-Language` / `Referer` 才是主页接口能返回真数据的原因 —— 只有 UA+client hints+Cookie 时是 200 但仅 121 字节的空壳，补上这三个头变 7074 字节。 （我先前猜的 sec-ch-ua 不是关键。） · 因此 UA 与 client hints 必须**成套地取自同一个浏览器**，所以 BrowserIdentity 一次 从 CDP 取齐 cookie + UA + hints，而不是各自写死。 「200 + 空 body 必须当场报错」也是刻意写死的：放过去它会在下游变成「这个博主没作品」， 把一次失败伪装成一条正常结果 —— 爬虫那条路正是这么栽的，还被翻译成「账号被封」。 顺带：把参考项目目录加进 .gitignore。上一次 `git add -A` 把 mac-agent-os-main 整个 （1429 个文件）带进了提交，已从历史里清掉。 测试 +11：cookie 解析、请求头成套性（含 uifid 缺失/回退）、产物键名与 store 对齐、 以及 _get 的三条失败路径（空 body / 403 带网关原话 / 正常返回）。	2026-10-10 17:13:04 +08:00
butubb	21ff01b894	fix(douyin): 缺 sec-ch-ua 请求头，网关回 200 + 空 body（不是「账号被封」） ... 先纠正一个我上一轮给错的结论：日志里的 `account blocked` **不是抖音说的**，是 MediaCrawler 自己编的： if response.text == "" or response.text == "blocked": raise Exception("account blocked") 真实情况只是**抖音返回了空 body**。我把它读成了「账号被风控」，还写进了运行历史和 给用户的结论里 —— 用户质疑「我网页版和手机版都能正常登录」，一查，他是对的。 实测定位（同一 URL、同一 cookie、同一参数）： 浏览器页面内 fetch : 200, 7077 字节 ✓ httpx : 200, 0 字节 ✗ 带 a_bogus : 0 字节 不带 a_bogus : 0 字节 四种 msToken 变体 : 全部 200 有数据（所以不是它） 用浏览器那次的完整头重放 httpx : 200, 7077 字节 ✓ 浏览器那次请求比爬虫多的，只有这三个头： sec-ch-ua: "Google Chrome";v="155", "Chromium";v="155", "Not(A:Brand";v=24 sec-ch-ua-mobile: ?0 sec-ch-ua-platform: "Linux" 爬虫的 UA 是从页面读的（声称是 Chrome 155）却不带 sec-ch-ua —— 「Chrome 的 UA + 没有 sec-ch-ua」是最典型的机器人特征。网关的回应方式是不报错、不给原因，回一个 200 + 空 body，HTTP 状态还写在成功那一栏。 修：media_platform/douyin/help.py 新增 client_hint_headers()，从 navigator.userAgentData 现算这三个头（现算而不是写死 —— 写死的版本号一旦和 UA 里的 对不上，就又是一个可疑特征）；core.py 建客户端时带上。 诚实说明：我无法解释**为什么之前能跑**（run 34 还是成功的，40 分钟后同样的代码就 不行了）。最可能是字节那边收紧了这道校验，但我没有证据，别当结论。 测试 +8：还原出的头与真实浏览器抓到的值逐字一致；拿不到 userAgentData 时返回空而不 凭空编造（编一组和 UA 对不上的头比不带头更糟）；mobile 标志；platform 缺失时仍发另两个。	2026-10-10 16:47:49 +08:00
butubb	e4affe9170	feat(monitor): 运行历史要写清楚失败原因，不能只写「退出码 1」 ... 用户的要求：运行历史的说明要写清楚。现在确实写不清楚 —— 抖音那次失败，运行历史里 只有一句 `Crawler exited with code 1`，而真正的报错 `DataFetchError: account blocked` 埋在子进程的 stderr 里，谁也看不到。 那两者本来是断开的两条路：子进程的输出只流向日志 WebSocket（前端 Terminal 看得到）， 而监控层调 run_and_wait() 只拿得到一个退出码。 * crawler_manager 在 _push_log() 里留一份输出尾巴（80 行，每次 start 清空）—— 那是所有输出的唯一出口，挂这儿不会漏。新增 get_output_tail()。 * ingest 新增 diagnose_failure()：倒着找第一行像异常的行（traceback 的末行）， 认不出就退回最后一行；管理器自己补的「Crawler exited with code」不是原因，排除掉。 * describe_exit_code() 接受这个原因并附在消息里；失败事件的标题也带上，这样企业微信 通知和事件流不用翻日志就能看懂。 * runner 把尾巴交给 ingest；「超时/没起来」那条分支同样带上原因 —— -1 同时代表两种 情况，而要查的东西完全不同。 * 运行历史那一格是截断的（240px），而失败原因现在有一整行 —— 补上 title 悬停显示， 并放宽到 320px。没有悬停提示等于把最要紧的半句藏起来。 测试 +5：能挑出异常行、不会把管理器自己的话当成原因、没有输出时不报错、认不出时退回 最后一行、以及失败运行同时记下退出码与真因（含事件标题）。	2026-10-10 16:14:54 +08:00
butubb	1118d466be	fix(monitor): 抖音的时间戳是秒、小红书是毫秒，不换算会把 2026 年显示成 1970 年 ... 上一个提交把作品发布日期透到界面之后，抖音那一行显示成 1970-01-22。查原始产物： 小红书 time = 1790923011000 → 毫秒 → 2026-10-02 ✓ 抖音 create_time = 1790574515 → 秒 → 2026-09-28 ✗（被当毫秒 → 1970-01-22） 抖音给的是**秒**。而且这条路径不只影响新增的发布日期 —— **评论的 create_time 走的是 同一条路**，所以抖音评论的时间一直是错的，只是之前界面上没显示出来，没人发现。 时间单位的换算正是 adapters 该管的事，所以加在那边： * `PlatformAdapter.time_scale`（小红书 1、抖音 1000）+ `to_ms()`，解析不出来返回 None 而不是伪造 0。 * ingest 用它换算作品的 published_at 和评论的 create_time。落库统一毫秒，展示层不必 关心来源。 * 已入库的数据要能自愈：published_at 和评论 create_time 原先都是**只写一次**的，换算 改对了老数据也修不回来。现在它们会在重采时跟着刷新（昵称早就是这么做的）。 测试 +1：抖音记录落库后 published_at 是 1790574515 * 1000，且年份是 2026 不是 1970。 dy 的 fixture 也改成用真实的秒值（原来写的是毫秒形态，所以测不出这个 bug）。 注意：库里那条抖音记录**仍带着错的值**，要等抖音下一次成功采集才会被修回来 —— 而它 现在正被平台风控挡着（account blocked），见下一条说明。	2026-10-10 16:08:42 +08:00
butubb	3486c7f524	feat(monitor): 作品栏和评论栏显示作品的发布日期 ... 需求：抖音和小红书都要能看到作品的发布日期。 `MonitorNote.published_at` 其实**一直在库里**（ingest 早就按平台取：小红书 time、 抖音 create_time），只是从来没往 API 和界面上透 —— 后端序列化没这个键，前端类型里 也没有，所以界面上只有「首次发现」。 * 后端：list_notes 的序列化补上 published_at；_note_meta_map 也带上，于是 list_comments 多一个 note_published_at，分组接口的桶多一个 published_at。 * 前端：NotesTable 新增「发布日期」列（要让分组表头的 colspan 从 +4 变 +5）； 评论栏作品那一层在标题旁显示日期 —— 同名作品不少，日期能帮着认。 * 新增 formatDate：发布日期问的是「哪一天发的」，绝对日期比「3天前」好认，也不会 每天看都在变。具体到分钟的版本放在 title 里，悬停可见。 刻意和「首次发现」分开：前者是作者发布的那天，后者是我们第一次看到它的那天。把一个 早就存在的作品加进监控时，两者能差好几个月 —— 测试里就用不同的值把这两者钉住。 顺带修正一处过时注释：前端类型里还写着 creator_name 是「已脱敏的昵称」， 脱敏已经在上一个提交里关掉了（config.MASK_NICKNAME）。 测试 +2：桶要带发布日期；作品列表接口要带，且它不等于 first_seen_at。	2026-10-10 16:06:22 +08:00
butubb	cd85587f00	feat(privacy): 关掉昵称脱敏 —— 脱敏有损，撞名就分不出博主 ... 需求：评论栏/作品栏要能分清是哪个博主。修好分组字段之后名字仍带星号，因为上游作为 教学版默认对昵称做中间脱敏（首尾各留 1 字，中间星号）。这个脱敏是**有损**的： 「张三」和「张四」都变成「张*」 「小明老师」和「小刚老师」都变成「小***师」 而本仓库的用途是监控一批公开创作者账号，分清谁是谁正是这一层要干的事。所以关掉它。 * config/base_config.py 新增 MASK_NICKNAME = False（和 INJECT_ALL_COOKIES 一样是个 开关，不是删代码 —— 改回 True 就恢复上游行为）。 * tools/user_hash.py 的 mask_nickname 读这个开关，关闭时原样返回。读的是模块属性而 不是导入值，测试才能 monkeypatch。脱敏实现本身一字未动。 * 顺带修一个数据陈旧问题：评论是去重后直接 continue 的，昵称只在首次入库时写一次， 于是开关一改（或评论者改名）老评论永远停在旧值 —— 而重采是唯一能拿到新值的途径。 现在已存在的评论会跟着刷新昵称（作品那边的 creator_name 早就是这么做的）。 * anonymous 的 creator_hash 保持不变：那是分组用的稳定键，不是显示名。 测试： * 三个隐私套件 + weibo 的 autouse fixture 强制把开关打开 —— 它们验的是**脱敏机制 本身**，机制仍然必须正确，所以显式打开来测，而不是让它们随部署配置漂。 * test_mask_and_hash_tools 改成两个方向都覆盖（开着脱敏 / 关着脱敏）。 * test_tieba_extractor.py 里 8 处字面量的脱敏期望值换成真实昵称 —— 提取器现在就是 返回原文的，期望值理应跟着改（这一条是行为变更的直接后果，不是测试放宽）。 * 新增一条：已入库的评论昵称会随重采刷新（且不会因刷新而重复插入）。	2026-10-10 15:48:15 +08:00
butubb	67837b407e	fix(comments): 评论栏所有博主都显示成「未知博主」 ... 现象：小红书的和抖音的评论栏，最外层分组全是「未知博主」，分不出谁是谁。 根因是分组接口漏了两个字段。api/routers/monitor.py 里按作品构造桶时只放了 note_id/note_title/note_cover/note_url/comments，而前端 groupByCreator 是用 bucket.creator_hash / bucket.creator_name 分组的 —— 两个都是 undefined，于是所有 博主塌成同一个 key，标签取空串回退成「未知博主」。 数据一直都在：每条评论上都带着 note_creator_hash / note_creator_name （service.py:540-541），只是没往桶上搬。TS 的 CommentBucket 里也声明了这两个字段， 所以是后端没兑现自己的契约，不是前端写错。 修：构造桶时把作品的创作者一并放上去（同一个桶里的评论必然同属一个作品，取哪条都一样）。 测试：种子数据改成「两个作品属于不同博主」（原来是同一个 hash，测不出这个 bug）， 新增一条断言每个桶带上自己那个博主、且两个博主的 hash 确实不同。	2026-10-10 15:41:42 +08:00
butubb	f3ea088c75	fix(monitor): 从界面上建的任务永远是小红书任务，平台从没被传上去 ... 现象：站在抖音页面上新建任务，任务跑到小红书列表里去了；界面上还写着「笔记」。 根因在前端：TaskCreatePayload 里**根本没有 platform 字段**，handleSubmit 拼的 payload 自然也不带它，而后端是 `payload.get("platform") or PLATFORM_XHS` —— 于是不管在哪个 平台标签下建任务，落下来的都是小红书任务。以前只支持小红书，两边都看不出问题。 * TaskCreatePayload 补上 platform（并在注释里写明为什么它是必填），handleSubmit 带上 当前平台。 * 更新任务时不带 platform：平台创建后不可更改，带着会让「平台能改」看起来像真的。 * 三处写死的「笔记」改成按平台取措辞（能力矩阵的 target_hints.note_label）： · 任务编辑器的类型选择项「笔记（批量监控指定内容）」 · 「笔记模式下此项不生效」那句提示 · 任务卡片上的类型徽章 —— 它按**任务自己的**平台取词，不是当前平台，因为卡片未必 只出现在同平台的列表里 抖音管它们叫「作品」，小红书叫「笔记」，写死一个对另一个就是错的。 测试 +1：后端这一半也守住 —— 建任务时显式给了平台，就必须落到那个平台，且不得出现在 另一个平台的列表里。前端那半边是 UI，测不了，但后端守住能挡住「给了不用」这类退化。 注意：这次是纯前端漏传，后端那个「缺省回退小红书」的行为本身没变（有测试断言它是 有意为之的兼容行为）。要彻底消灭这类静默错误，可以把缺省值去掉、让 platform 必填 —— 那会破坏 API 兼容性，目前没有任何别的调用方，需要的话说一声。	2026-10-10 15:13:37 +08:00
butubb	e77e5e2f15	fix(report): 空的任务集合被当成了「不限制平台」，导致报表串平台数据 ... 现象：切到抖音，报表里显示的是小红书的数据。 根因是报告聚合里的一行真值判断： scope = list(task_ids) if task_ids else None 空列表是假值，而空列表在这里的含义是「这个平台一个任务都没有」，不是「不限制平台」。 于是 platform=dy 且抖音还没有任务时，_resolve_scope 返回的 [] 被翻译成了 None， 聚合范围从「抖音的任务」变成了**全部任务** —— 小红书的数字就这么显示在了抖音页面上。 顺带 task_ids 也回成 None，界面会显示成「全部任务」。 改成 `is not None`。空列表进去就让 in_([]) 恒假，结果为空，这才是对的。 排查时把所有同类写法过了一遍，只有这一处错，其余（service.py 的 10 处作用域judgement、 _resolve_scope、export）用的都是 `is not None`。 测试：新增两条，并且**验证过它们在修复前会红**（失败信息就是 assert 42 == 0 —— 查一个没有任何任务的平台，却返回了小红书那条作品的 42 个赞）。 同时修掉一条空跑的测试：test_a_platform_with_no_tasks_yields_empty_not_everything 原先种了任务却没有作品/指标数据，于是过滤生效与否结果都是 0，什么都测不出来 —— 这正是这个 bug 能活下来的原因。现在它会真的塞一条作品+快照进去，并在末尾断言 「小红书自己的报表看得到那条数据」，用来证明前面那两个 0 是过滤出来的而不是没数据。	2026-10-10 15:00:12 +08:00
butubb	06718a1351	feat(monitor): 抖音接入博主监控 ... 上游爬虫本身不缺抖音能力（三模式、四项指标、二级评论都与小红书对等、指标还是同名同列）， 缺的全在监控层的适配。这次把「平台之间不一样」的管子集中到一个新模块，再把散落的 xhs 硬编码接上去。 * 新增 api/monitor/adapters.py：产物目录名、jsonl 字段别名、目标链接形态与正则、 通知链接模板。不放进 platforms.py 是因为那个模块被 describe_all() 整个序列化进 /api/config/platforms 交给前端，塞进正则和目录名会让爬虫内部细节漏进 API 载荷。 代价是两个注册表可能漂移，用一条测试钉住「声明接通就必须有适配器」。 * 两个必须知道的坑，都在这版里处理掉了： 1) 抖音的平台 id 是 dy，而 store 把产物写在 douyin/ 下（store/douyin/_store_impl.py:47）。 不改就是 ingest 一个文件都读不到 —— 不报错，只是 0 条，然后被冒充成「疑似登录失效」。 2) 抖音的作品没有 note_id（叫 aweme_id）、评论也用 aweme_id 指作品。ingest 第一步是 `if not note_id: continue`，不映射就逐条全丢。 另外抖音顶层评论的 parent_comment_id 是字符串 "0"，归一成空串，免得前端多出悬空的父节点。 * 顺带把「东西抓到了、只是没落在期望目录里」单独识别出来。这类故障的现象和登录失效 一模一样，按登录失效报会把人指去查完全错误的方向。 * 修两个既有 bug（今天只有小红书所以无害，加抖音就踩响）： - service.py update_task 换目标时漏传 task.platform，回落到默认小红书 - scheduler.py 取 cookie 没传 platform，抖音任务会读着小红书那份 cookie 不动 * 行为变更（已与用户确认）：cookie 闸门改成「没 cookie 且没开 CDP」才跳过。 CDP 模式下登录态来自被接管的浏览器，粘不粘 cookie 由不得它决定；不放行的话， 选了「接管已有 Chrome」却没粘 cookie 的用户会看到任务永远不触发，而且不报错。 副作用是开启了 CDP 的小红书任务也不再被该闸门拦住 —— 语义上是对的。 * 目标输入框的示例链接与措辞改由能力矩阵提供（notes_label 抖音说「作品」、小红书说 「笔记」；「建议只填纯 ID」是小红书专属劝告，抖音链接不带令牌，不再显示）。 测试 +22 条（858 通过），其中最关键的是「抖音作品/评论不被静默丢弃」与「产物目录名 不等于平台 id」两条 —— 都是把最难查的失败模式钉死在回归网里。 注意：抖音这条路的**端到端尚未验证**，需要一份可用的抖音登录态（CDP 那台 Chrome 里 登录，或导出一份 cookie）。单测覆盖的是解析与入库，真实抓取还没跑过。	2026-10-10 14:55:28 +08:00
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	44cbe8e2aa	fix(monitor): 已登录时点「同步登录态为 Cookie」要干等 30 秒 ... 顺序反了：原先先开页面、读二维码，读完才发现「已经登录、没有二维码」。而读二维码内部 会 wait_for_selector 等满 30 秒才放弃 —— 用户点一下按钮要干等半分钟，还白开一个标签页。 实测日志里就是 `Page.wait_for_selector: Timeout 30000ms exceeded`。 改成先问登录状态（那是一次接口调用，很快），已登录就直接返回，根本不碰页面。 新增测试守住这个顺序：已登录时 context.new_page 不得被调用。	2026-10-09 13:49:11 +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	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	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	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	e608b51210	test: 修正列渲染断言——SQLAlchemy 会对保留字加反引号 ... monitor_run.trigger 是 MySQL 保留字，渲染出来是 `trigger`。这比之前手写的列清单更正确： 清单里的裸 trigger 会直接语法错误。断言改为剥掉引号后比对列名。	2026-10-07 15:37:08 +08:00
butubb	d937ff5fe6	fix(db): _ensure_columns 改为按模型元数据推导，并补上漏加的调度字段 ... 上一个提交加了 4 个调度字段，却没在 _ADDED_COLUMNS 里登记，后果是生产环境： - 任务列表接口报 Unknown column，UI 打不开任务列表 - 调度器每 20 秒 tick 一次炸一次，定时任务完全不会触发 最阴险的是启动完全正常——能连库、能起来，只是随后每条查询都失败。 - _ensure_columns 不再遍历手写清单，改为遍历 MonitorBase.metadata.sorted_tables， 从根上消掉「加了字段忘了登记」这类漏 - 新增 _column_ddl：用 CreateColumn 渲染类型与可空性，并给 NOT NULL 列补 DEFAULT。 模型的 default= 是 ORM 侧行为、不会进 DDL，而给已有数据的表加 NOT NULL 列必须有值， 否则能否成功取决于服务端 sql_mode - 主键列跳过：MySQL 不允许 AUTO_INCREMENT 与 DEFAULT 共存 新增 tests/test_monitor_column_migration.py 守住：每个 NOT NULL 列都必须能生成带 DEFAULT 的合法 ALTER。	2026-10-07 15:35:40 +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	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)	380b426000	fix(dy): 补上 ArgusSecurityPlugin 要求的 x-tt-argus 请求头 ... 抖音在边缘网关新挂了 ArgusSecurityPlugin，对 aweme/detail、aweme/post 这批接口做 业务前置校验：缺少 x-tt-argus 时直接 403，响应体为 "Blocked by ArgusSecurityPlugin Uifid Not Found"；只补 uifid 参数但仍没有这个头 则是 "... Signature Not Found"——后者很容易被误判成 a_bogus / verifyFp 的问题。 网关当前不校验该头取值，传固定字符串即可（实测 "1" 就够）。 参考 https://github.com/Johnserf-Seed/f2/issues/443 注意这是权宜之计：网关哪天升级到真校验该值，会重新出现 Signature Not Found， 届时需要改为页面内注入 JS 让抖音自带 SDK 补齐 Argus 头。 验证：真实 cookie 下 get_video_by_id 恢复可用。 - client.py: 默认请求头补 x-tt-argus，cookie 有 UIFID 时带 uifid 头 （两种都没有则不发，避免被当成「有但为空」） - 新增 tests/test_douyin_argus_header.py（不发网络请求）	2026-09-19 13:25:59 +08:00
程序员阿江(Relakkes)	c7e6c9fdc0	feat(ks): 支持分享短链 /f/<token> 形式的视频输入 ... 快手分享短链 https://www.kuaishou.com/f/X9Idt15MQb9L2cv 路径里是 share_token 而不是视频 ID，它只做 302 跳转，真实地址在 Location 里。原先的解析器只认 /short-video/<id> 和纯 ID，遇到短链会抛 ValueError 被 continue 掉——只有一行 ERROR 日志，看起来像"爬了但没数据"。 - help.py: 新增 /f/<token> 分支，返回 url_type="short"（token 不是视频 ID， 必须跟随重定向），并补上第三种形式的文档 - client.py: 新增 resolve_short_url，GET 时 follow_redirects=False，读 301/302/303/307/308 的 Location - core.py: url_type == "short" 时先解析短链再解析一次，失败则跳过该条 - 新增 tests/test_kuaishou_url_parse.py（6 条，不发网络请求） 验证：两条真实短链分别解析到 3xyziwesje8e9jg / 3xbbkdxtxqm8sae，详情均成功； 带 query 的标准视频页不会被误判成短链。	2026-09-18 17:23:20 +08:00
程序员阿江(Relakkes)	1e1ae64cb4	fix(ks): 视频不可用时 photo 为 null 导致整轮爬取崩溃 ... 快手对已删除/私密/不存在的视频，返回的 visionVideoDetail 里 photo/author 是 null——key 存在、值是 null。而 detail.get("photo", {}) 只在 key 缺失时给默认值， key 存在且为 null 时拿到的仍是 None，紧接着的 photo.get(...) 抛 AttributeError。 该异常不在 get_video_info_task 的 except 列表里（只 catch DataFetchError / KeyError），会穿过 asyncio.gather 直接把整轮爬取带崩。 - core.py: 用 (x or {}) 兜住 null；photo 为空时打 WARNING 并跳过该视频， 不再返回半残的 detail 让下游存空记录、再去下载媒体 - 新增 tests/test_kuaishou_unavailable_video.py（不发网络请求） 验证：photo=null / photo 缺失 / visionVideoDetail 缺失 均返回 None； 真实 cookie 端到端确认不可用视频被跳过、正常视频照常返回详情。	2026-09-18 17:18:01 +08:00
程序员阿江(Relakkes)	cf513e70a1	fix(dy): 补上 detail 接口的 uifid/verifyFp 风控参数 ... 抖音 detail 接口的 Argus 风控要求 uifid / verifyFp / fp 三个参数，缺一则直接 403：响应体为 "Blocked by ArgusSecurityPlugin Uifid Not Found"，补上 uifid 但 verifyFp 不对时换成 "... Signature Not Found"。原实现只传 aweme_id，于是 get_aweme_detail 全线失败，详情和媒体都拿不到。 - 三个参数取自浏览器 cookie：uifid 用 UIFID（缺失时退到 UIFID_TEMP）， verifyFp/fp 用 s_v_web_id。必须用 cookie 里的 s_v_web_id——实测 uifid 搭配 自生成的 verifyFp 会被判 Signature Not Found，两者需要同源 - 新增 tests/test_douyin_aweme_detail_params.py（不发网络请求） 验证：抓包比对真实浏览器发出的 detail 请求，参数逐项一致；真实爬取中详情与 74MB 视频均下载成功。	2026-09-18 17:00:11 +08:00
程序员阿江(Relakkes)	eec25bb0a0	fix(xhs): 适配上游 EF* 分档，修复视频只下到封面 ... 小红书把 DASH 分档名从按编码命名（h264/h265/av1）改成了按内部档位命名 （EF4/EF5/EF6/EF7），同时 video.consumer 里的 origin_video_key 也没了。 extract_video_urls 写死 stream["h264"]，两条路都取不到地址，于是静默返回 空列表：笔记照常入库，但 video_url 为空、媒体只下到封面，全程不报错。 - media.py: 遍历 stream 下所有列表型分档，不再写死分档名；同一分档内含多个 分辨率（720P→4K），按 (height, avg_bitrate) 降序，最高档作主地址，其余作为 备用地址交给下载器回退；origin_video_key 分支保留 - 测试 fixture 换成真实响应结构，旧的 h264 结构另存一份确保兼容性不被改坏 验证：真实响应下旧实现取到 0 条、新实现 5 条；真实下载得到 4K 视频 （54079413 字节 / hevc 3840x2160 / 281.87s），旧结构与图文笔记行为不变。	2026-09-18 16:10:18 +08:00
程序员阿江(Relakkes)	c03ab60aac	fix(bili): 登录态判定改为校验 cookie 有效性，避免静默降级到 480P ... check_login_state 原先只判断 SESSDATA 是否存在。过期会话的 SESSDATA 会一直 留在浏览器里，于是 pong 报"账号未登录"后进入的登录流程会被立刻判成成功： 既不等待扫码，又把这份死 cookie 灌给 API client。 后果是隐蔽的：详情和评论两个接口不要求登录，照常爬到；而 playurl 依据 Cookie 决定清晰度，未登录状态会静默封顶在 480P，不报任何错。 - login.py: 抽出 is_login_cookie_refreshed()，要求 SESSDATA 被扫码换发成新值 才算登录成功；进入登录流程前记录旧值，残留死 cookie 时输出告警 - core.py: 登录流程结束后补一次 pong 校验，仍失败则明确报错退出， 不再带着未登录状态跑完全程 - 新增 tests/test_bilibili_login_state.py 覆盖上述分支	2026-09-18 15:48:06 +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)	d594c20c13	fix(xhs,bilibili): 修复访问受限异常击穿与评论采集边界问题 ... xhs: PR #958 把 IPBlockError / PlatformAccessError 加入 request() 的 retry_if_not_exception_type 后，tenacity 会直接重抛原异常而不再包装成 RetryError，core 层的 except 分支接不住，单条笔记被限流会让整批 asyncio.gather 抛出，同批已抓取但未入库的数据全部丢失。 - get_note_detail_async_task / get_creators_and_notes 捕获访问受限异常， 记录明确日志后跳过当前条目，恢复原有的"跳过并继续"语义 - 移除 request() 中已不可达的 IP_ERROR_CODE 分支 bilibili: 修复 get_video_all_comments 的两处翻页边界问题 - is_first_page 改为独立标志，接口返回 next=0 且 is_end=False 时 不再把后续页误判为首页而重复注入置顶评论 - result 无条件累加，否则开启楼中楼抓取时循环守卫永不推进， max_count 完全失效并可能死循环；截断提前到抓取楼中楼之前， 避免为已被丢弃的评论抓子评论	2026-08-11 18:10:16 +08:00
程序员阿江-Relakkes	3c25521bbb	Merge pull request #958 from ottercoconut/agent/fix-xhs-raw-response-errors ... fix(xhs): 在返回原始 HTML 前识别访问限制	2026-08-11 18:00:22 +08:00
ottercoconut	508abc504f	补全小红书响应与重试回归测试	2026-08-11 17:52:54 +08:00
ottercoconut	6937b12738	修复小红书原始响应错误分类与重复重试	2026-08-11 16:45:49 +08:00
muzimu	17c6d386b8	fix(bilibili): 修复缺失置顶评论	2026-08-08 18:01:26 +08:00
程序员阿江(Relakkes)	a06273ea6c	fix: 将平台业务ID统一改为String并自动建表 ... - 抖音、B站、快手、微博的帖子/视频/评论ID从BigInteger改为String， 避免PostgreSQL下字符串写入BIGINT报错及未来ID溢出风险 - B站dynamic_id改为String，修复API返回id_str被强转int导致的精度丢失 - 知乎提取器对content_id/question_id显式str()转换 - main.py启动数据库保存模式时自动建表，无需手动--init_db - 同步更新相关老化测试	2026-07-01 23:03:43 +08:00
程序员阿江(Relakkes)	9f4f8bf768	refactor: 教学版移除全平台用户个人信息采集与持久化 ... - 用户 ID 转为匿名 creator_hash，昵称中间脱敏，IP/头像/主页/签名/性别不再采集 - 覆盖 xhs/weibo/bilibili/douyin/kuaishou/tieba/zhihu 7 个平台 - 删除 7 张 creator 档案 ORM 表，15 张内容/评论表新增 creator_hash 列 - B 站禁用粉丝/关注/联系人列表抓取 - 新增 tools/user_hash.py 与 4 个平台的 mock+SQLite 端到端测试 测试: pytest tests/test_no_user_info.py tests/test_weibo_no_user_info.py tests/test_douyin_no_user_info.py tests/test_kuaishou_no_user_info.py (21 passed)	2026-07-01 13:09:55 +08:00
程序员阿江(Relakkes)	c9a111be73	fix: 修复已有浏览器 CDP 连接	2026-06-18 17:22:38 +08:00