于是花了几天时间用 Nextjs + NextUI 写了个前端界面，顺带也是为了学一下 Next 的开发，界面功能参考了常见的一些磁力搜索引擎，顺带做了夜间模式、多语言、内容预览和搜索分词等功能
详细的部署过程可以看仓库，提供有 Docker Compose 配置可以快速部署，也可以点 Demo 链接体验，Demo 为了避免版权等问题，内容是固定的
仓库地址： https://github.com/journey-ad/Bitmagnet-Next-Web
Demo： https://bitmagnet-next-web.vercel.app/
预览：
下面是一些开发过程的记录：
原版的 Bitmagnet 自带一个 GraphQL 的 api 可以进行搜索，但用下来和 webui 遇到的问题是一样的，数量上去之后普遍搜索时间在几十秒，最重要的是返回的结果数量不准，没办法做分页
关于搜索和索引问题我问过 bitmagnet 的开发者，他回复是已经结合种子标题和文件内容，在 torrent_contents.tsv 里创建了向量索引。研究后发现是先转罗马音然后存的向量，这样好处是可以用 pg 原生支持的 tsquery 来查询，而且转成罗马音后对应中文的是拼音，可以做到错字也能搜到，坏处是只要同音字就能搜到，就算同音字很离谱也是一样
另外就是 bitmagnet 用了 go-unidecode 这个库做罗马音化，但这个库在 node 上没有一比一对应的，转罗马音的过程和 bitmagnet 做不到完全一致，影响搜索效果
综合以上问题，决定自己写后端代码直连 DB 来查询，但之前没怎么搞过后端，更没搞过搜索这种东西，总之边写边测边改，搞出来了 gin 索引+传统 like 模糊匹配+分词，并根据每个关键词的词性确定为必须或非必须，生成对应的 SQL 查询这种野路子方案。至于为什么不上 ES ，还有个考虑是想侵入性的修改尽量少点，后面 bitmagnet 库表结构有升级时好适配，所以没选 ES 这种重的方案
结果比较多的情况下基本在几百毫秒到几秒内就能返回，部分收录少的词可能要跑全表，要等十几秒，这个性能还算能接受，暂时是我能想到的最好的方案了，等有空了研究一下 discuz 之类的论坛怎么做的搜索
