mss 的随便记录

同一集下载两次，得到一份损坏的音频

Wed, 11 Nov 2026 00:00:00 GMT

流声里有个 bug：开着「自动下载最新一集」，某天又手动点了同一集的下载，结果那集音频是坏的，点取消也没反应。

这个 bug 值得写，它是三个小问题叠在一起，漏掉哪个都修不干净。

两条路径撞在一起

开了「自动下载最新一集」的节目，刷新缓存时会自动把最新一集存到本机。这时候我正好手点同一集，两条下载路径就同时起来了。

两条路径各自先判断一下「这集是不是在下载」。问题是这个判断和真正的下载之间，隔了两个 await——一个查 WiFi 设置，一个读存储。await 会让出事件循环，另一条路径就在这个空隙里挤进来。

于是两边都看到「没在下载」，都往下走。

两个字节流写同一个文件

下载用 Dio，先写到一个临时文件 .part，下完再改名。这个临时文件的名字只由 guid 决定，所以两条路径打开的是同一个文件。

两个 Dio 各自按自己的节奏收数据、往里写，字节流交错落地。下出来的文件是坏的。

取消为什么没反应

cancel token 原本按 guid 存一个。第二条路径启动时，把先启动那次的 token 顶掉了。

顶掉之后，先启动的那次再也取消不掉——点取消，取消的是后启动的那个。用户看到的就是「按了没反应」。

三处修法

临时文件加唯一后缀。 时间戳加序号，两次并发下载各写各的，不再撞车。

cancel token 按 guid 存集合。 一个 guid 可能挂着好几个 token，取消时全停掉。清理时只摘掉自己那个，不能整条 remove，否则又把并发的那条抹了。

判重和占位不能跨 await。 这才是根子：

// 判重和占位之间不能跨 await
if (_inflightFeedByGuid.containsKey(episode.guid)) return;
_inflightFeedByGuid[episode.guid] = feed.id;   // 先占位
final wifiOnly = await ...;                     // 再 await

把「占住这一集」前移到第一个 await 之前，另一条路径进来时看到的就已经是「在下载」。

占位还有个细节：如果 WiFi 检查不通过要还回去，不然这一集永远下不了。

之后

现在同一集的并发下载各写各的临时文件，取消时一起停。损坏音频和「取消没反应」都没再出现。

这种事以后大概还会犯。教训就一条：判重和占位之间，别跨 await。

HTTP 200 不等于能播

Wed, 11 Nov 2026 00:00:00 GMT

精选列表里放着一个台，URL 看着没毛病，点进去转圈。这种源我遇到得多了，最后搞清楚一件事：HTTP 状态码说明不了能不能播。

200 会撒谎

不少源会返回 200，但正文根本不是音频。可能是 JSON 错误信息，也可能是一个漂亮的 HTML 错误页——服务器挂了，状态码照样 200。

所以探测得读正文。我的规则是读前 2048 个字节，看它到底像什么。

探测看什么

先发一个普通 GET，不带 Range，模拟真实播放。读够 2048 字节就断开，最多等 4 秒——直播流会一直推数据，不主动断就卡住了。

判断规则：

正文以 { 或 [ 开头，或 Content-Type 带 json：死。
正文是 HTML（<!doctype html>、<html>）：死。
URL 带 .m3u8 或正文含 #EXTM3U：算 HLS，但还要再查一层——播放列表里至少要有一条非注释的地址，光有 #EXTM3U 没用。
剩下的才算能播。

有个坑是 gzip。有的源（新城电台走 cdn77）把 m3u8 压缩了返回，不解压看到的是一团乱码，会被误判成「不是播放列表」。所以先看 Content-Encoding，是 gzip 就先解开再判断。

Range 那次翻车

最早我按常规思路来：探测就发 Range: bytes=0-2047，只要前 2KB，省流量。

结果蜻蜓的 CDN 对 Range 请求回 404，普通 GET 却能正常出音频。一批本来能播的台，被我自己判死了。

现在反过来：普通 GET 优先，Range 只在普通 GET 失败、而且这个 URL 不是 HLS 的时候兜底——探测模拟的是真实播放。

两轮探测

精选列表不是抓下来就用。重建的时候，每个 URL 要过两轮全量探测，两轮都过才算数；中间某一轮抽风（超时、限流）的台，直接不要。

采编来源是蜻蜓、央广网、tingfm、radio5 的公开页面，抓完按 URL 和规范化台名去重，一个台只留一条，最后 409 个。

两件事值得单独说。

403 不能当死链。 央广 ytlive 的链接带 key 和 time，大约两周过期，过期后探测拿到 403。但这不是台死了，是签名过期，换个新签就行。要是因为一个 403 就把整张表删了，那才叫出事。

探测本身也会挂。 清理死链的工具里有个保险：如果要删的台超过一半，直接中止，不写回。这种情况多半是探测环境出了问题，不是列表坏了。

App 里怎么用

App 只在三个时候探测：首次启动选完收听范围、下拉刷新、设置里点「检测可播放的源」。其他时候沿用上次的结果，不重复折腾。

探测是并发的，测通的台立刻出现在列表里，能马上听，不用等全部测完。进度条旁边有「停止检测」，按下去保留已经测到的，剩下的不测了。

测失败的台会从主页隐藏，但能在设置「电台管理 → 连不上的电台」里看到，长按就能换个地址。换完只存在本机，不用等我发版。

想听电台和播客，所以我写了个 App

Wed, 11 Nov 2026 00:00:00 GMT

我想听电台。手机应用商店里下了一堆，没一个顺手。

蜻蜓、喜马拉雅、小宇宙这类，内容是授权目录，我想听的不一定在里面，直播电台反而弱，还要开会员。专门听电台的 App 呢，国内台不全，列表看着挺长，能播的没几个。播客客户端倒是成熟，可它们不管电台，我还得再装一个。

装来装去不如自己写。流声（Liusheng）就是这么来的，Android 和 Windows 都做，前身叫澄波（Chengbo），2.2.1 改的名。

几条后来管了大部分设计的规矩

能播比数量多重要。 我宁可要一份测过的台清单，也不要一份没验证过的大全。精选列表现在 409 个台，每一个都是手工重建、两轮探测全过的。判断能不能播不能看状态码——有的源返回 200，内容其实是 JSON 或网页，那也是死的，删掉，不为了凑数留着。

就做公共电台。 只播公开直播流和公开 RSS，版权点播库不碰，没授权。直播音频只在内存里缓冲，绝不存成文件。

死链得让用户自己能修。 第三方的流一定会过期。所以台坏了不用等我发版，长按换个地址就行，换完只存在他自己设备上。精选列表和手动添加两条路都留着，就是不想让「能播」完全靠别人。

借鉴了谁

这项目借了不少东西，得说清楚。

播放器的样子照 Spotify 做的。 底部一条迷你播放器，点开上滑出 Now Playing，这套交互我直接用了。但我不想整个抄。拓展计划里写了一条：不整体复刻 Apple Music / Spotify——用 Spotify 式的交互，视觉保持 Material 3，不照任何一家。Apple Music 那个方向撞了三条硬约束，而且它的视觉是围着版权曲库搭的，跟「公开直播流 + RSS」这个形态不对路。

代码基本是轮子。 音频用 just_audio 加 audio_service，Windows 端是仓库里自己 fork 的 just_audio_windows（UI 线程回调得自己处理）；状态管理是 Riverpod；界面是 Google 的 Material 3。

数据来源分几路。 电台发现用 Radio Browser，社区维护的电台目录 API，元数据是公共域的；只取中国大陆、中文和港澳台，当成全球目录用就偏了。播客发现是三级兜底：先搜 iTunes，不行查 Podcast Index，再不行翻本机目录（GetPodcast 精选加 xyzrank 前 1000，大概 1250 个中文节目）。那 409 个精选台是从蜻蜓、央广网、tingfm、radio5 的公开页面一个个采下来的，每台都实测过。

没碰的也算借鉴。 蜻蜓、喜马拉雅、小宇宙、荔枝的点播库要授权，不碰。但它们自己的公开 RSS 可以用——实测发现喜马拉雅、荔枝、蜻蜓返回的其实是平台自己的标准 RSS 2.0，跟第三方转接源不是一回事。

现在

2.2.4，双端，一套 Material 3。电台、播客、收藏、最近、统计、本机备份、Windows 托盘和浮条、Android 桌面小组件都有了。

这东西是为我自己做的。谁要是也想听，拿去用。

微博实况图，一个 43 字节的假 mp4

Mon, 09 Nov 2026 00:00:00 GMT

做社交存档的时候，微博实况图是整条链路上最麻烦的一块。实况图在微博上显示成一个格子：静图打底，鼠标悬停播放几秒动态。存档得同时拿到静图和那段视频，否则这个"归档"就是残的。

下面几个坑，按踩到的顺序记。

直接下载是 403

API 返回的 pic_infos 里有个 video_url，看着就是视频地址。直接 GET，403。

微博对这个域名的媒体做了来源校验，从别的上下文请求一律拒绝。真正能用的是播放接口：

GET https://video.weibo.com/media/play?livephoto=<urlencode 后的原始地址>
Referer: https://weibo.com/

三个必须：

Referer 必须是 https://weibo.com/，别的值直接 403
不要带 Cookie，带了反而被拒
不要自定义 Host，用 requests 时如果顺手把 API 请求的 Host 头带过去，同样 403

这三点都写进注释了。因为每次重构都有机会手贱把 Host 加回去。

接口会返回假文件

更麻烦的是，它不总是返回视频。限流、签名过期、目标不存在的时候，它返回一个 HTTP 200 的 JSON 错误体。把响应直接写进文件，磁盘上就多一个 .mp4：43 字节，内容是 {"code":"403",...}。

播放器打开一片黑。校验脚本也看不出来——文件存在、大小非零、扩展名对。

所以落盘前必须验：

if size < 64 or head[:1] in (b"{", b"<", b"["):
    # 不是视频，重下

三个条件缺一不可：空文件靠大小识别，JSON 和 HTML 错误页靠首字节识别。

签名地址不能剥参数

video_url 上带 Expires 和 ssig，是短时效签名。很容易想到：既然最终要换成 play 接口，那先把查询参数剥掉再拼，干净。

不行。签名参数是播放接口校验的一部分，剥了就 403，跟第一条同一个下场。

所以元数据里存的一直是 API 返回的原始带签名地址，下载时才转 play URL。这样重跑、校验、迁移都不会因为地址被改坏而失效。

HEVC 在窗口里放不了

下载下来的是 H.264 QuickTime，正常情况下 Electron 能播。但有一部分是 HEVC（hvc1）。

而这个应用启动时关掉了 GPU——历史上 WebGL 崩过几次，直接一刀切。代价就是 Chromium 解不了 HEVC。

这不是下载失败，是渲染限制。所以卡片上得给一个"用系统播放器打开"的兜底，走 shell.openPath。判断依据也简单：文件在、ftyp 有、视频元素报错。

另外本地文件走自定义协议 social-archiver://，返回的 MIME 一律标 video/mp4，否则 <video> 连认都不认。

整条链路

API 元数据（带签名 URL）
  → 下载时转 play URL（Referer + 无 Cookie + 无 Host）
  → 落 .part
  → 校验大小与首字节
  → os.replace 成正式文件
  → 自定义协议 + video/mp4 给渲染进程
  → 解不了就交给系统播放器

每一步都能失败，每一步失败的表现都不一样，而且大多不报错，只是"没东西"。

写下来是因为下次改这块的时候，我大概会忘掉其中至少两条。

限流是别人的，退避是自己的

Fri, 06 Nov 2026 00:00:00 GMT

抓别人平台的内容，第一原则不是"快"，是"别把对方搞死，也别把自己搞死"。

这条原则写进代码之后，整个抓取流程会变得很慢。慢到你第一次用会怀疑是不是卡住了——所以最后还得专门做"等待可见"。

微博的节奏

翻页间隔 8 到 13 秒，随机。

每连续 3 页，额外停 45 到 75 秒。

失败的时候，任务内最多再等 3 分钟，然后把断点保存下来。

这不是我拍的数，是社区里被风控教育出来的经验（RSSHub 和几个微博爬虫的 issue 里都是类似量级）。微博的翻页风控按频率和深度双重判断：短时间内连续翻，几十页就触发；慢慢翻，能翻几百页。

所以「深度回溯」这个功能，文档里写着请隔 30 到 60 分钟再跑。早年内容不是一次能拉完的，得多次续跑。

打满 200 页要明确提示"更早的没拉到"。这一点比限流本身重要——如果界面显示成功，用户会以为存全了，实际上只存了一半。

X 和 Instagram 交给 gallery-dl

这两个不用自己控制节奏，gallery-dl 的配置项够用：

配置	值	含义
`sleep`	1.5 – 4s	每个请求之间
`sleep-request`	6 – 12s	请求间隔的另一个档位
`sleep-429`	60s	遇到 429
`ratelimit`	wait: 300	触发速率限制时等 5 分钟
下载线程	2	上限

最要紧的一条：429 不要手动杀进程。

gallery-dl 收到 429 会自己退避重试。你一看日志不动就杀掉重启，等于把它已经排好的等待重置了，下次更快撞墙。看起来"重启一下更快"，实际是越来越慢。

批量任务：失败要能重来，但不能立刻重来

批量缓存几十个用户，中间挂几个是正常的。

失败自动重试，指数退避，默认最多 3 次，设置里可关。

有些错误重试有用（网络抖动、临时 5xx），有些没用（Cookie 失效、账号私密）。指数退避的作用是让前者过关，至于后者，重试三次之后失败，日志里能看见真实原因。

等待要有反馈

30 秒没有任何输出，主进程会往日志里发一条心跳，提示"可能正在限流或重试"。

这条是给用户看的，不是给机器看的。因为未知的等待比慢更难受——你不知道它是卡住了还是在老老实实地睡。

这个项目里慢的地方几乎都是刻意的。真正该优化的不是抓取速度，是让用户知道自己在等，而且等得有意义。

本地文件怎么喂给 video

Tue, 03 Nov 2026 00:00:00 GMT

存档里全是本地文件。要让它们在 Electron 窗口里像网页一样播放，比想象麻烦。

为什么不用 file://

渲染进程里直接 <video src="file:///D:/archives/xxx.mp4">，会遇到两个问题：

一是路径。存档根目录是用户自己选的，可能在任意盘符，中文路径、空格、特殊字符都有。手拼 URL 很容易漏转义。

二是安全。现代 Electron 默认不允许渲染进程随便读本地文件，绕过限制要么放宽配置（等于开门），要么改架构。

自定义协议

最后用了一个注册协议：social-archiver://asset/?path=<绝对路径>。

有两个必须先做的事：

在 app.whenReady() 之前调 registerSchemesAsPrivileged
两个标志都要带上：standard 和 stream

少任何一个，<video> 拿到的响应就不支持流式读取，拖动进度条直接失败。standard 让它有正常的 URL 语义，stream 让它支持 Range。

Range 是重点

视频能拖进度条，靠的是 HTTP 206 和 Content-Range。

这里有个分界：100MB。

小于 100MB 的文件，直接把整个文件读进内存 Buffer，自己实现 Range 解析和切片。简单、可靠，反正内存扛得住。

超过 100MB 的走流式。流式下 Range 要自己算，而且要考虑边界：bytes=0-、bytes=-500、超出文件长度、多段 Range——这些都得处理，不然播放器会贴心地让你看到"无法播放"。

那个不该踩的坑

有段时间用过这个写法：

const stream = Readable.toWeb(fs.createReadStream(filePath));
return new Response(stream, { headers: { 'Content-Type': 'video/mp4' } });

看起来很现代：Node 的 Stream 转成 Web Stream，直接喂给 Response。

结果：视频能播，但拖进度条就断。

原因是这个转换出来的流是"一次性的"——它已经按顺序把数据推出来了，再去要第二段拿不到。Range 请求本质是"重新给我 0 到 1000 字节"，不是"接着上次的地方继续"。

现在这条写在交接文档里，用加粗标着。

其他细节

MIME 类型：.mov 一律标 video/mp4。Chromium 对 QuickTime 容器不认，标错就不播。

缓存：加了长期缓存和 ETag。同一个文件反复打开不重复读盘。

路径校验：协议处理里要 path.resolve 之后检查是否在存档根目录内。不然就是任意文件读取漏洞——social-archiver://asset/?path=C:/Windows/System32/config/SAM 这种请求本来能成。

播不了的那些

有些实况图是 HEVC 编码的，而应用启动时禁用了 GPU（历史上 WebGL 崩过几次）。结果是 Chromium 里解不了 HEVC。

这不是下载失败，是渲染限制。

所以卡片上有个兜底：检测到播放失败就显示「打开实况」，走 shell.openPath 交给系统播放器。判断依据是文件存在、有 ftyp 头、但 <video> 报错。

本地文件协议这件事，最花时间的不是写代码，是搞清楚为什么明明能播却不能拖。

把 Electron 和 Python 塞进一个 zip

Sat, 31 Oct 2026 00:00:00 GMT

这个应用的形态是：Electron 34 套一个 Vue 3 界面，真正的抓取逻辑全是 Python。

开发的时候很舒服：改 Vue 热更新，改 Python 下次点按钮就生效。打包发给别人是另一回事——对方电脑上没有 Python。

两层打包

第一层，Python 冻成 exe。

PyInstaller onedir 模式，输出到 build-backend/backend/，里面是一个 backend.exe 加一个 _internal/ 目录。

用 onedir 不用 onefile：onefile 每次启动都要把整个运行时解压到临时目录，启动慢，而且杀毒软件对"自解压的程序"格外敏感，误报率高得多。

第二层，electron-builder 把这个目录拷进 resources/backend/。

最终产物：

dist-electron/
  SocialArchiver-1.2.5-win.zip     # 解压即用
  SocialArchiver-1.2.5-win.exe     # NSIS 安装包
  win-unpacked/                    # 同内容，本机直接跑

坑一：只拷 exe 一定坏

这是我这项目里被问得最多的问题。

有人从 win-unpacked 里把 Social Archiver.exe 单独拷到桌面，双击，报错。

Electron 的 exe 只是入口，它要去找同目录下的 resources/app.asar、resources/backend/backend.exe、_internal/ 里几千个 DLL 和 Python 模块。少任何一个都起不来。

所以文档里反复写：必须保留整个目录，要么发 zip，要么发安装包。

坑二：gallery-dl 装了两份

X 和 Instagram 都靠 gallery-dl。它被打进了冻结的后端里——但冻结的版本永远是打包那天的版本。

gallery-dl 更新很勤，平台一改接口它就得跟。冻结版没法 pip install -U。

所以运行时的策略是：先用 shutil.which('gallery-dl') 找系统里装的，找到就用系统的（用户可以自己升级）；找不到才用冻结的兜底。

这样既能"解压即用、不用装 Python"，又能"想升级随时升"。

坑三：中文乱码

打包版有一段时间日志全是乱码。

原因：subprocess 在 Windows 上的默认编码跟着系统区域走，中文系统是 GBK，而管道里传的是 UTF-8。

修了两处：cli.py 里 _force_utf8_stdio() 强制重设 stdin/stdout，spawn 的时候显式指定编码。

还有个连带问题：stdout 是 JSON Lines，一行一条。如果缓冲区没行缓冲，一条消息可能被切成两半发出来，前端解析失败，界面一直转圈。所以 spawn 时开了行缓冲。

坑四：SmartScreen

安装包没有代码签名。

第一次运行，Windows 会弹「Windows 已保护你的电脑」。处理方式是「更多信息」→「仍要运行」。

这是预期行为，不是中毒。想消掉只有一条路：买 Authenticode 证书签 exe，一年几千块。个人项目不值当，所以在 README 里写清楚怎么绕过。

企业环境部署的话，可以在组策略里给这个 exe 加路径排除。

坑五：环境门卫

PyInstaller 打包前检查 Python 版本，低于 3.9 直接报错退出。

不检查的话，低版本打出来的包能生成，但运行时一堆语法错误，排查起来很痛苦。

坑六：输出目录被占用

win-unpacked 里的 exe 还在跑，再打包就失败——文件被锁。

解决方法是要么先关掉，要么指定临时输出目录：

npm run electron:build -- --config.directories.output=%TEMP%\sa-electron-out

打完再拷回来。

打包本身的代码量不大，但它决定了别人能不能用。开发环境跑得通，和发给朋友能双击打开，中间隔着的全是这类细节。

三个平台，三套 Cookie，一堆坑

Sun, 25 Oct 2026 00:00:00 GMT

社交存档要访问三个平台，每个平台认的东西都不一样，也都不肯好好说。

各自要什么

平台	必需项	特别要求
微博	`SUB`	必须是 `m.weibo.cn` 的，不是 weibo.com 桌面站的
X	`auth_token` + `ct0`	两个都要，缺一个就是游客态
Instagram	`sessionid`	只认这一个，不支持用户名密码登录

微博这个坑我踩过：从 weibo.com 复制出来的 Cookie 里也有 SUB，看起来一样，但拿去请求 m.weibo.cn 的接口就是不认。移动端和桌面端是两套会话。

坑一：一个账号一套 Cookie

最初只有「每个平台一个 Cookie」的设计。测试多账号的时候立刻出问题：缓存完 A 用户，切到 B 用户，用的还是 A 的会话。

改成 per_user 键，格式是 platform:userId：

"cookies": {
  "per_user": {
    "instagram:username": "sessionid=...",
    "twitter:123456789": "auth_token=...; ct0=..."
  }
}

取值顺序是：先找 per_user，没有就回退到平台全局键。全局键是「这个平台我登的谁」，per_user 是「这个用户我要用谁的登录态」。

顺便说一个细节：验证 TTL 的存储用的是对象数组而不是 Map 加字符串 key。因为 userId 里可能有 : 或者别的特殊字符，用 platform:userId 拼成字符串 key 再拆分解析，迟早切错位。

坑二：验证太勤，网络一抖就弹登录框

每次切换任务都去 x.com / instagram.com 打一次远端校验，网络稍微抖一下，就返回失败，界面弹登录窗。你根本没掉登录态，只是刚才那次请求超时了。

解决办法是进程内 30 分钟 TTL：任务完成、或 checkCookie 明确返回有效之后，30 分钟内信任本地缓存，不再打远端。

浏览页也加了短路：ensureCookie 先问「最近验证过吗」，命中就直接跳过校验。

坑三：从浏览器导入，别顺手覆盖用户级 Cookie

Edge 导入是个很实用的功能——不用手抄 Cookie。但它写的是平台全局键。

早期版本顺手把该平台下所有 per_user 也一并更新了。结果是你为某个号单独准备的登录态，被一次导入全冲掉。

现在只更新 cookies[platform]，per_user 一个不动，导入完清掉这个平台的 TTL 记录，下次任务重新校验。

坑四：X 的 ct0 会自己换

这是最阴的一个。

X 的 ct0 是 CSRF token，会轮换。auth_token 不变。gallery-dl 在下载过程中会刷新 ct0。

于是你缓存完 A 用户，本地存的还是那个旧 ct0；下一个任务用 B 用户，同一个 auth_token，带着过期的 ct0，直接失败。

现在的做法：gallery-dl 刷新后的会话 Cookie 写到 {root}/twitter/.session-cookies.txt，同一个 auth_token 换用户时沿用这份。任务结束再写回设置和缓存页输入框。

另外批量队列每个任务开始前会重读一次最新 Cookie，不用入队时的快照。

坑五：Instagram 的应用内登录分区

应用内登录会往一个 Electron partition 里存 sessionid。有个看起来理所当然的逻辑：缓存前把分区里的 Cookie 同步到设置里。

问题是切到另一个 IG 账号时，分区里还是上一个的 sessionid，一同步就把 per_user 里这个账号的凭据覆盖了。

现在改成：缓存里已有可用 sessionid 就信任它；只有缓存为空或不可用时，才从分区回填。

坑六：Cookie 不要出现在命令行

python xxx.py --cookie "auth_token=...; ct0=..." 会把整个 Cookie 写进进程命令行，任何能看进程列表的程序都能读到。

改成走临时文件 --cookie-file，用完删掉。

这套东西最后散在四处：session.js 的可用性判断、electron/cookie-rules.js 的平台规则、cookie_check.py 的远端校验、cookie-validation.js 的 TTL。三处平台规则必须保持一致，改一个地方就得三个一起改。

增量归档：第二次跑得比第一次快

Mon, 19 Oct 2026 00:00:00 GMT

第一次缓存一个用户，可能要走几百页、下几千个文件。第二次只该花几秒钟。

这听着像优化，其实是能不能用的分界线：每次更新都要重走整条时间线，你就不会去点那个更新按钮。

微博：连续 5 条命中就停

微博的翻页接口是 m.weibo.cn/api/container/getIndex，containerid=107603{uid}，靠 since_id 往前翻。

判断「已经存过了」最直接的办法是看这条的原帖 id 在不在本地。但直接拿这个当停止条件会出事：

置顶帖永远在第一条，会误判成"到头了"
转发的 id 和内容归属不一致，容易算错
帖子标题在，但媒体只下了一半，也算不上完整

所以停止条件是：连续 5 条「已缓存且媒体完整」的非置顶原创。连续，不是累计——中间夹一条新的就清零重算。

5 这个数字是试出来的。1 条太容易误判，10 条在白翻好几页。

另有一条保底：翻到 200 页就停，并明确告诉用户「更早的内容没拉到」。这个提示很重要，否则界面显示"完成"，你会以为全在了。

断点：别让中断等于白干

微博的翻页有风控（后面单独写），跑到一半断掉是常态。

所以 _profile.json 里记三个值：lastSinceId、lastPage、fetchStatus。fetchStatus 只有三种：complete / partial / page_limit。

下次点「更新」，从 lastSinceId 继续，不用从头来。

换日期范围不会重置断点，只按新范围过滤。这条是为了避免"改个日期就重新爬一遍"。

媒体：`.part` 加 Range

帖子层面能续，单个文件层面呢？

微博的媒体下载现在这么走：

下到 {文件名}.part
已经存在有效的 .part 就用 Range: bytes=N- 接着下
服务端忽略 Range（回 200 而不是 206），就从零重下
校验通过后 os.replace() 改名成正式文件

关键在于最后那步用 os.replace 而不是 rename 加判断——同一个文件系统内它是原子的，要么旧的要么新的，不会出现半个文件。

进度条也分两种：知道总大小的显示百分比，不知道的（gallery-dl 的很多场景）显示「已完成 N 个」加一个不确定态的动画条。不伪造百分比，转了半天的 99% 比没有进度更让人焦虑。

原子写入

不只是媒体，JSON 也一样。

断电、强杀进程、写到一半磁盘满——都会留下一个语法不完整的 settings.json，下次启动直接崩。

所有元数据写入都改成：写临时文件 → flush() → os.fsync() → os.replace()。

fsync 那步不能省。flush 只是把数据从 Python 的缓冲区交给操作系统，fsync 才是真正落盘。省掉它，断电的时候文件系统里可能只有一个空文件。

X 和 Instagram：交给 download-archive

这两个走 gallery-dl，增量不用自己实现——它在存档根目录维护 .download-archive.sqlite，已经下过的媒体直接跳过。

不加这个文件的话，缓存一个几千条的大号，每次更新都要把整条时间线走一遍，光请求就要几十分钟。

增量做对之后，日常使用的手感完全不一样：日更的账号，点一下更新等十几秒；半年没动的，第一次慢，之后也快。

第一次慢是应该的，每次都慢是设计错了。

收藏不等于存档

Tue, 13 Oct 2026 00:00:00 GMT

微博和 X 上都有一个「收藏」按钮。按下去，你会觉得东西存住了。

其实没有——收藏夹存的只是一个 id，内容还留在对方服务器上。

收藏夹的问题

它存的是指针，不是内容。原帖被删、账号注销、平台改版，收藏夹里就剩一行「该内容不存在」。收藏得越久，失效的越多。

你也看不到原文的真实样子。图片经过压缩和转码，视频清晰度看你当时的网络，长文被折叠，评论区的上下文丢了。你以为存的是那条微博，其实存的是它的一个渲染结果。

它还不能离线。没网就是空的。平台哪天关站、哪个地区被墙、哪个功能下线，都不在你控制范围内。

「存档」应该是什么样

我给这个词定了几条硬标准，后来变成这个工具的设计原则。

文件在你自己磁盘上。 不是数据库、不是云端、不是「导出成 PDF 存进某个 App」，就是 {平台}/{用户}/ 目录下的一堆 jpg、mp4 和 json。

重跑要加深它，不能分叉它。 同一个用户第二次缓存，新内容进同一个目录，已有的跳过。跑一百次也只有一个文件夹，不会变成 user_2026-08-29、user_2026-09-01 这样满地都是。

脱离 App 也能读。 每个用户目录里有一个 index.html，双击就能在任何浏览器里按时间线看，样式和 App 里一致，浅色深色都跟着系统走。哪天这个 Electron 程序跑不起来了，存档本身还是活的。

文字是内容，不只是媒体的附属品。 纯文字帖不会被跳过。很多人做下载器只存图，把配文扔了——那是把一半的原始信息丢了。

边界

只存原创，不存转发。转发的内容属于别人，把它当成目标用户的原创存下来，等于伪造。

只存公开内容，靠你自己的 Cookie 访问，不做账号池、不做代理池、不碰别人的隐私。

不做云端同步，不做账号体系，不上传任何东西。Cookie 只留在本机 %APPDATA% 里。

这不是一个备份服务，是给自己留一份。

开张

Wed, 07 Oct 2026 00:00:00 GMT

这里是 mss 的随便记录。

不是每篇都正经排版、认真配图的博客，更像个草稿本：写代码时踩的坑、做东西时的想法、看到的觉得有意思的东西。想到哪写到哪，不保证有主线。

大概会写这几类：

项目记录：自己写的东西怎么设计、为什么那么设计、哪里翻车了
工具折腾：环境配置、脚本、还有那些"本来十分钟结果搞了一下午"的事
随手记：读书、看片、想到的一些没头没尾的东西

更新频率随缘。写这个只是因为有些东西记在脑子里会忘，写下来至少以后自己搜得到。

mss 的随便记录

同一集下载两次，得到一份损坏的音频

两条路径撞在一起

两个字节流写同一个文件

取消为什么没反应

三处修法

之后

HTTP 200 不等于能播

200 会撒谎

探测看什么

Range 那次翻车

两轮探测

App 里怎么用

想听电台和播客，所以我写了个 App

几条后来管了大部分设计的规矩

借鉴了谁

现在

微博实况图，一个 43 字节的假 mp4

直接下载是 403

接口会返回假文件

签名地址不能剥参数

HEVC 在窗口里放不了

整条链路

限流是别人的，退避是自己的

微博的节奏

X 和 Instagram 交给 gallery-dl

批量任务：失败要能重来，但不能立刻重来

等待要有反馈

本地文件怎么喂给 video

为什么不用 file://

自定义协议

Range 是重点

那个不该踩的坑

其他细节

播不了的那些

把 Electron 和 Python 塞进一个 zip

两层打包

坑一：只拷 exe 一定坏

坑二：gallery-dl 装了两份

坑三：中文乱码

坑四：SmartScreen

坑五：环境门卫

坑六：输出目录被占用

三个平台，三套 Cookie，一堆坑

各自要什么

坑一：一个账号一套 Cookie

坑二：验证太勤，网络一抖就弹登录框

坑三：从浏览器导入，别顺手覆盖用户级 Cookie

坑四：X 的 ct0 会自己换

坑五：Instagram 的应用内登录分区

坑六：Cookie 不要出现在命令行

增量归档：第二次跑得比第一次快

微博：连续 5 条命中就停

断点：别让中断等于白干

媒体：.part 加 Range

原子写入

X 和 Instagram：交给 download-archive

收藏不等于存档

收藏夹的问题

「存档」应该是什么样

边界

开张

媒体：`.part` 加 Range