44 Commits

Include renames

Author	SHA1	Message	Date
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	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	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	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	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	5484e5a3ae	fix(creator): 详情接口用了 MySQL 5.7 不支持的 NULLS LAST ... 1064 语法错误。nullslast() 是 PostgreSQL 语法，MySQL 5.7 不认；而 MySQL 把 NULL 视为比任何值都小， 所以 DESC 本身就把它排在最后，不需要额外声明。 这个 bug 只在真机上暴露：SQLite 从 3.30 起支持 NULLS LAST，本地测试环境测不出来。	2026-10-07 16:32:53 +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	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	bcc7361145	refactor: 镜像只装依赖，代码改为挂载 ... - Dockerfile: 去掉 COPY . .，镜像退化为纯依赖层，改代码不再需要重建镜像 - Dockerfile: 补 libgl1 / libxcb1 / libglib2.0-0 等 X11 库。opencv-python 在导入时需要它们，而 tools/utils.py 会经 slider_util 导入 cv2 —— 缺了不是某个边角功能挂掉，是整个应用起不来（已在真机冒烟中验证） - Dockerfile: 补 tzdata，否则 TZ=Asia/Shanghai 被静默忽略，所有时间戳落成 UTC - Dockerfile: apt 与 pip 均改走国内源。deb.debian.org 实测约 13 kB/s，96 MB 构建依赖要跑半小时以上 - docker-compose: 挂载 ./ 到 /app，部署流程从「重建镜像」变成「重传 + 重启」 - main.py: 启动时若缺 api/webui/index.html 就打印警告，避免只返回一段 JSON 却看着一切正常	2026-10-07 10:57:44 +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
程序员阿江-Relakkes	165776886f	Merge pull request #900 from zanmeipaul/main ... feat: 启动任务接口添加帖子/视频数量与评论数量覆盖支持	2026-05-29 21:34:07 +08:00
程序员阿江(Relakkes)	8e93438fe5	Keep PR 900 overrides bounded and opt-in ... The PR adds API limit overrides and static proxy support, but the review found that the default proxy provider changed to an invalid static placeholder and the new API fields accepted unbounded values. This keeps the existing proxy default intact, makes static proxy explicit via config or CLI, validates API limit ranges, and adds focused regression coverage for both paths. Constraint: PR branch must remain contributor-branch compatible and avoid adding dependencies Rejected: Keep static as the default provider | breaks existing --enable_ip_proxy defaults with an invalid placeholder URL Rejected: Accept arbitrary integer limits | lets API callers request negative or excessive crawl sizes Confidence: high Scope-risk: narrow Directive: Do not change proxy provider defaults when adding new providers; new providers should be opt-in and covered by provider-specific tests Tested: uv run pytest tests/test_api_limits.py tests/test_static_proxy_provider.py Tested: uv run pytest tests Tested: uv run pytest test/test_utils.py Tested: uv run python -m compileall api cmd_arg config proxy tests Tested: git diff --cached --check Not-tested: Live crawler run against external platforms or real proxy vendor endpoints	2026-05-29 21:27:52 +08:00
🐟Jaryán🍋	5ad5a93e00	Update main.py ... sys	2026-05-21 15:37:46 +08:00
🐟Jaryán🍋	5ddd969a8e	Update main.py ... 修复Asyncio Windows兼容性	2026-05-20 22:54:27 +08:00
钟保罗	ec432eb63e	feat: 启动任务接口添加帖子/视频数量与评论数量覆盖支持	2026-05-19 20:57:07 +08:00
程序员阿江(Relakkes)	0282e626c9	feat: 新增 JSONL 存储格式支持，默认存储格式改为 jsonl ... JSONL（JSON Lines）每行一个 JSON 对象，采用 append 模式写入， 无需读取已有数据，大数据量下性能远优于 JSON 格式。 - 新增 AsyncFileWriter.write_to_jsonl() 核心方法 - 7 个平台新增 JsonlStoreImplement 类并注册到工厂 - 配置默认值从 json 改为 jsonl，CLI/API 枚举同步更新 - db_session.py 守卫条件加入 jsonl，避免误触 ValueError - 词云生成支持读取 JSONL 文件，优先 jsonl 回退 json - 原有 json 选项完全保留，向后兼容 - 更新相关文档和测试	2026-03-03 23:31:07 +08:00
Doiiars	70a6ca55bb	feat(database): add PostgreSQL support and fix Windows subprocess encoding	2026-01-09 00:41:59 +08:00
程序员阿江(Relakkes)	57b688fea4	feat: webui support light theme	2026-01-06 11:16:48 +08:00
程序员阿江(Relakkes)andClaude Opus 4.5	157ddfb21b	i18n: translate all Chinese comments, docstrings, and logger messages to English ... Comprehensive translation of Chinese text to English across the entire codebase: - api/: FastAPI server documentation and logger messages - cache/: Cache abstraction layer comments and docstrings - database/: Database models and MongoDB store documentation - media_platform/: All platform crawlers (Bilibili, Douyin, Kuaishou, Tieba, Weibo, Xiaohongshu, Zhihu) - model/: Data model documentation - proxy/: Proxy pool and provider documentation - store/: Data storage layer comments - tools/: Utility functions and browser automation - test/: Test file documentation Preserved: Chinese disclaimer header (lines 10-18) for legal compliance 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>	2025-12-26 23:27:19 +08:00
程序员阿江(Relakkes)	11500ef57a	fix: #799	2025-12-24 11:45:07 +08:00
程序员阿江(Relakkes)andClaude Opus 4.5	508675a251	feat(api): add WebUI API server with built frontend ... - Add FastAPI server with WebSocket support for real-time logs - Add crawler management API endpoints (start/stop/status) - Add data browsing API endpoints (list files, preview, download) - Include pre-built WebUI assets for serving frontend API endpoints: - POST /api/crawler/start - Start crawler task - POST /api/crawler/stop - Stop crawler task - GET /api/crawler/status - Get crawler status - WS /api/ws/logs - Real-time log streaming - GET /api/data/files - List data files - GET /api/data/stats - Get data statistics 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>	2025-12-19 00:02:08 +08:00