我的笔记现在会自动发到 X —— 靠一个只读 Redis 旁观者
我有一个手动发推的 CLI（Playwright 驱动登录状态的 Firefox 网页，所以不需要 X API key），还有一个多用户笔记应用（HappyNotes）把新笔记推入 Redis 队列同步到 Mastodon。想让它俩连起来：笔记一发，自动发推。但不想动共享后端、毕竟这是一个很私人的hack，也没法子支持其他用户。
演进三步
1. CLI → 微服务。 把发推核心抽成库，Node 内置 http 起一个服务，只监听 Tailscale IP（100.x.y.z:8090）——内网即鉴权，零依赖、零鉴权代码。任何 tailnet 机器都能入队：
curl -X POST http://100.x.y.z:8090/add \
-H 'content-type: application/json' \
-d '{"text":"hello","post_at":"2026-09-07T09:00:00+12:00"}'
2. 图片走 data URL。 别的机器没有你这台的文件系统，multipart 又要新依赖——所以图片在 JSON body 里以 data:image/png;base64,... 传输，Playwright setInputFiles 喂内存 buffer，最多 4 张。
3. 只读 Redis 旁观者。 这是关键设计：不 LPOP（会偷走 Mastodon 消费者的消息），只每秒 LRANGE queue + ZRANGEBYSCORE processing，用 redis-cli 子进程（还是零新依赖）。然后三道过滤：
userId == OWNER_USER_ID && action == "CREATE" && isPrivate == false
task.id 落盘去重（先写 seen 再发布，失败绝不重试——重试 = 重复推文），冷启动基线首轮只记已见不发布，防止积压刷屏。
代价：一个有意的竞态窗口
队列项最多活 5 秒（消费者 LPOP 后成功后 ZREM，删了就没了，没有 deleted 队列可拣漏）。所以旁观者"几乎不漏但不保证"——如果任务在两次轮询之间被消费完，就错过了。要修复的话要动HappyNotes后端（加一个 synced 队列，成功时 LPUSH + 1 小时 TTL），但只为我一个人需求改全站代码不太值，先接受这个妥协看看。