7 Commits

Include renames

Author	SHA1	Message	Date
butubb	20e672834c	feat(monitor): 博主的粉丝数，以及给作品起备注 ... 两件都是「作品栏里把这东西认出来」的延伸： * **账号级指标**：作品列表只会说「这条涨了多少赞」，说不了「这个人整个 账号的粉丝在涨还是在掉」。抖音的资料接口本来就有粉丝数/总获赞/作品数， 每轮顺手记一条快照（`monitor_creator_stat`，粒度 = 任务×博主×轮次， 和作品指标同形）。组头显示最近一条。 快照在「一条作品都没采到」的早退**之前**落：作品列表被风控挡住的那一轮， 正是「粉丝还在涨、但新作品没在发现」最该被看见的时刻。 * **作品备注**：博主备注回答「这个账号是谁」，这条回答「这条我要盯着」。 一个博主底下常常只有一两件值得盯的作品，所以不能合并成一条。键取 (platform, note_id)，跨任务共用一份。 两边都守住同一条口径：**不知道就是 null，不写成 0** —— 0 在趋势图上是一条 砸到底的线，和「还没采到」是两回事。	2026-10-10 18:09:03 +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	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	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	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	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