为什么做它
这不是我第一次为自己的小问题写软件。我嫌简历模板调整麻烦，做了履历工坊；写公众号需要反复处理格式，做了墨排；总惦记 Codex 还剩多少用量，做了 Codex Usage HUD；Mac 和 Android 之间传文字和文件不顺手，又做了 Relay。发圈防折叠、公众号文章批量下载器和拼一下，也都来自工作或生活里真实碰到的问题。
这些作品看起来没有统一赛道，共同点却很明确：不是先找一个市场概念，而是先解决我正在重复承受的麻烦。「批量取关公众号」没有那么高频，但每次需要时都意味着上百次机械点击。低频不等于没价值，能解决真实麻烦就值得做。
实际使用时，先把一定要保留的公众号放进白名单，再通过搜索、分页和全选整理其余账号。选完只会生成一份取关清单，不会立即操作微信；再次确认后才逐个执行。最近 30 天的取关记录仍然可查，发现选错还能重新关注。
第一次真实批量执行用超稳妥模式完成了 185/185 个账号，总耗时 18 分 54 秒，平均约 6.1 秒一个。后来我用串行快速模式又实测了一小批：16 个账号用时 21.3 秒，平均约 1.33 秒一个，几十秒就能完成一次小整理。两次账号和数量不同，不是严格对照测试；快速模式省掉前后状态查询，仍需要微信成功回执，并明确标为未复核。随后用超级快速模式实测了 27 个账号，总耗时 14.2 秒；最多 3 个请求同时执行，让等待时间重叠，整批完成得更快。
批量工具首先要让人敢用。白名单会在界面、清单和执行前重复校验；账号或微信会话一旦变化，队列就暂停。超稳妥模式会在每个账号取关前后确认关注状态；快速和超级快速模式仍要求微信成功回执，但明确标为未复核。这里真正花心思的不是“全选”，而是让速度和确定性都成为看得懂的选择。
想折腾实现的话：应用外层使用 Swift 与 AppKit，通过 WMPFDebugger 建立微信小程序的本机调试连接。因为包含 GPLv2 组件，仓库也按 GPLv2 开源。当前只支持 Apple Silicon Mac，GitHub 提供可直接下载的 DMG；安装包尚未经过 Apple 签名与公证。
它现在能做什么
- 把几百个公众号放在一个可搜索、可分页的列表里
- 先保护白名单，再批量选择剩余账号
- 生成清单后二次确认，不做危险的一键清空
- 实测：快速模式 16 个 / 21.3 秒，超级快速模式 27 个 / 14.2 秒
- 保留 30 天记录，支持批量重新关注；白名单由自己选择
- 源码公开，适合愿意自己构建和折腾的同学