关于 updateUrl 的想法

[aoguai]

由于网络环境的问题，导致不同用户访问规则订阅链接的效果可能不同。为了解决这个问题，我考虑了一种新的解决方案。

首先，可以考虑移除 RawSubscription 中的 updateUrl 字段。而是默认使用 checkUpdateUrl 或 添加订阅时填写的链接(规定该链接与 checkUpdateUrl 的 JSON 结构一致) 作为检查规则订阅的链接。

然后，规定将 updateUrl 移到 checkUpdateUrl 的 JSON 结构中，并允许 updateUrl 为列表。在进行更新检测时，首先检查 checkUpdateUrl 。如果 id 相等并且 version 有增加，那么遍历请求 checkUpdateUrl 中的 JSON 结构，使用第一个能够访问的 url 进行更新。

同时，如果考虑兼容旧版本的订阅源，还可以先检查 checkUpdateUrl 中是否存在 updateUrl 字段。如果不存在，则使用原来的 url 进行更新。

通过这种新的解决方案，可以更好地应对不同用户在网络环境下访问规则订阅链接的问题。这将提高用户的使用体验。同时允许规则编写者更好的利用 updateUrl 字段。（不然得针对不同的订阅链接生成不同的订阅文件）

[lisonge]

太麻烦，不支持，这是用户的问题

[aoguai]

其实可以直接通过file.ts生成多个 json5 产物，每个的 updateUrl 分别指向对应的 镜像url 即可。
但是我选择维持现状

[lisonge]

也可以，你这个方案更好，把区分度的使用度降低到了目录级别

---

但是这些都没啥必要，一开始就只提供淘宝源就没这些问题

[adproqwq]

我选择不设置updateUrl，用户用什么导入的就用什么更新。

[aoguai]

我选择不设置updateUrl，用户用什么导入的就用什么更新。

一开始我也是这样想的，然后我意识到要考虑 checkUpdateUrl ，还是无解。

一开始就只提供淘宝源就没这些问题

我考虑的是一开始就只提供 github 源，连不上的自己解决。现在也打算维持这样了。

[adproqwq]

一开始我也是这样想的，然后我意识到要考虑 checkUpdateUrl ，还是无解。

我现在公开的导入链接都是github raw的镜像，或者干脆就是gitee仓库的raw，这样基本可以将checkUpdateUrl的影响降到最低。至于用户自己找到的npm、jsdelivr那些的链接我就不管了

[lisonge]

最新版本支持相对路径，需要确保 checkUpdateUrl 相对 updateUrl 或者添加订阅时填写的链接后得到的新链接指向正确的文件地址

比如用户使用 https://registry.npmmirror.com/@gkd-kit/inspect/latest/files/dist/gkd.json5 添加后得到的检测链接是 https://registry.npmmirror.com/@gkd-kit/inspect/latest/files/dist/gkd.version.json5

但是如果使用自定义短链接 https://t.cn/xxxabcx 得到的链接是 https://t.cn/gkd.version.json5 将会映射到错误的链接