butubb
2112c1a870
移植自 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 必须当场报错」也是刻意写死的：放过去它会在下游变成「这个博主没作品」，
把一次失败伪装成一条正常结果 —— 爬虫那条路正是这么栽的，还被翻译成「账号被封」。
测试 +11：cookie 解析、请求头成套性（含 uifid 缺失/回退）、产物键名与 store 对齐、
以及 _get 的三条失败路径（空 body / 403 带网关原话 / 正常返回）。
2.3 KiB
2.3 KiB
采集与展示分离方案
当前问题
身份与账号页面的每个平台行都有 👤 采集按钮，点击后打开浏览器实际采集。但：
- 采集和展示耦合在一起，用户分不清是"重新读取文件"还是"重新打开浏览器"
- 每次想看最新状态都得重新采集（打开浏览器耗时几十秒）
- 展示数据已经在 profiles.json 中，但缺少"仅刷新展示"的入口
当前数据流
采集（打开浏览器）
│
douyin_ops 执行
│
▼
profiles.json
│
▼
api_sms_accounts 读取
│
▼
loadSmsAccounts 展示
目标：采集与展示分离
命令与任务 身份与账号
───────────────────── ─────────────────────
信息采集 TAB 卡片展示
├─ 选账号（单/多/全部） ├─ 状态：登录/昵称/同步 ✅❌
├─ 执行采集（开浏览器） ├─ 昵称名称
└─ 查看采集状态 └─ [🔄 刷新展示] 按钮
│
▼
只重新调 API，不打开浏览器
从 profiles.json 读最新数据
改动点
1. 身份与账号页面
- 去掉每行平台的 👤 采集按钮（移到命令与任务）
- 卡片底部保留「👤 全部采集」（批量操作）
- 增加「🔄 刷新展示」按钮（只重调 API，不打开浏览器）
- 增加「🔄 刷新状态」按钮在页面右上角（已有）
2. 命令与任务页面
- 新增「信息采集」TAB（第四个 TAB）
- 内容：账号下拉选择 + 执行采集 + 采集状态日志
3. 后端 API
- 现有
POST /api/matrix/accounts/{id}/collect-profile— 保留（采集用） - 现有
GET /api/matrix/sms/accounts— 保留（展示用） - 不需要新增 API
好处
- 展示秒级刷新（只读文件，不开浏览器）
- 采集集中管理（在命令与任务统一操作）
- 用户不混淆"刷新展示"和"重新采集"