为什么要接入bitmagnet？因为网盘资源受限且失效快，现在好像公开可供采集的磁力资源也很少。
只提供大概的思路和部署流程，不详细写（主要是也没法写🤣）具体细节，坑太多了，憔悴。。。
最初把bitmagnet部署在一台闲置的3c3g VPS上，结果cpu一直打满被主机商暂停了，把bitmagnet停掉才给解封。后来把bitmagnet部署在自家nas上，结果没几天nas风扇坏了，返厂维修了一个多星期回来数据库又不能同步了，数据库好不容易能同步了，bitmagnet又不更新数据了。。。然后VPS的cpu又被打满了，于是又陷入无穷无尽的优化中。。。
BitMagnet（项目地址：https://github.com/bitmagnet-io/bitmagnet）是一款自托管的BT资源管理神器，集成了三大核心功能：
- DHT网络爬虫：自动抓取全网种子资源
- 智能分类引擎：自动识别影视/音乐/软件等资源类型
- 可视化Web界面：支持关键词搜索+分类筛选
不依赖任何第三方平台，直接通过DHT网络抓取种子，资源新鲜度吊打传统种子站，自动识别种子内容类型，还能通过TMDB匹配影视剧信息（需申请API密钥），完美对接Prowlarr/Sonarr/Radarr等工具，打造自动化影音库，所有数据本地存储，再也不用担心资源突然404！
最终稳定的形态
- 使用frp连接VPS和NAS，VPS安装frps，NAS安装frpc
- 苹果CMS / 一键搜片
调用一个 PHP 接口，前端模板传入关键字参数。 - Nginx（fastcgi microcache）
对这个 PHP 接口做 10s～900s 的微缓存，把“高并发重复查询”挡在 Nginx 层。 - PHP
- 连接 VPS 上的 PG 搜索库（不是 NAS 上的主库）
- 执行搜索 SQL（拆分 name/path/content 三路匹配并 union），返回 JSON 给苹果CMS。
- VPS 上的 PG 搜索库（docker 容器）
只承担查询压力，不承担采集写入压力。 - NAS 上的 PG 主库（bitmagnet 实时写入）
用 逻辑复制把必要数据同步到 VPS 搜索库（“瘦身”只同步必要表/必要行）。
为什么要这么做
- 写入与查询分离：bitmagnet 写很重普通VPS根本承受不住所以把bitmagnet 安装到NAS上 ，VPS通过frp查询NAS数据库容易超时，所以VPS上建一个瘦身的副本，直查副本库更稳。
- 缓存 + 索引：Nginx microcache 抵消重复请求；VPS PG 索引解决单次查询速度。
- 逻辑复制可控：必要数据才同步，减少网络、WAL、apply 负担。
苹果CMS → PHP 搜索接口 → Nginx microcache → VPS PG（只读） 是主链路。
NAS → VPS 用逻辑复制（瘦身 insert-only + 行过滤 + 必要索引） 负责提供数据。
避免大坑的关键三点：
- 参数/编码/路由一致（kw/wd、URL encode、cache key）
- 订阅端表结构不要乱改（尤其 generated/PK/replica identity）
- 用 microcache 把并发吸收掉，配合“快速失败/快速降级”避免慢查询拖死全局
- VPS 上的 PG 搜索库索引要尽可能齐全
