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