A reference from another website parsing extension: https://simpread.ksria.cn/sites/

建议提供一个案例解释说明方案，并补充相关说明文档，具体可参考 NeverBehave 在 #8224 中的做法

建议提供一个案例解释说明方案，并补充相关说明文档，具体可参考 NeverBehave 在 #8224 中的做法

在pr中有给出，现在这里也补充了~

建议解释说明得更充分一些，POST 从哪来？能否提供案例？安全问题怎么解决？

说明文档是指类似 docs/joinus/script-standard.md 这样的

建议解释说明得更充分一些，POST 从哪来？能否提供案例？安全问题怎么解决？

说明文档是指类似 docs/joinus/script-standard.md 这样的

只是解析后返回了上下文对象，不存在执行，应该不会有安全问题？

这个方案只能是一个过渡方案：指在review - merge流程中的路由，可以通过用户自己配置的方式直接使用。真正解决的方案模式应该是像你所说的分离。

文档会尝试给出。非常感谢你的建议。

这个方案比较酷但其实没有解决 PR 中提到的问题。

关键还是需要核心开发者下定决心拆分为 core 和 routes 两个 repo，PR 才能真正分开处理：

• core 是 RSSHub 的核心，负责与其他组件交互，直接载入一方路由，以及载入 github repo、PR 等格式的三方路由
• routes 是官方维护的 route 推荐列表，通过 branch 或者锁定第三方 route repo commit 的方式固化路由插件版本
• 同时还需要提供一个 route-template 作为三方路由开发的起点

这样所有 routes 就分为了三个层级，可以让用户按需载入：

• built-in 内置级，官方维护的 mail/imap 等核心路由
• routes 推荐级
• 以及其他不在官方 routes 列表中，众多路由贡献者自行开发的

这个方案比较酷但其实没有解决 PR 中提到的问题。

关键还是需要核心开发者下定决心拆分为 core 和 routes 两个 repo，PR 才能真正分开处理：

• core 是 RSSHub 的核心，负责与其他组件交互、直接载入一方路由、载入 github repo、PR 等格式的三方路由
• routes 是官方维护的 route 推荐列表，通过 branch 或者锁定第三方 route repo commit 的方式固化路由插件版本
• 同时还需要提供一个 route-template 作为三方路由开发的起点

这样所有 routes 就分为了三个层级，可以让用户按需载入：

• built-in 内置级，官方维护的 mail/imap 等核心路由
• routes 推荐级
• 以及其他不在官方 routes 列表中，众多路由贡献者自行开发的

非常清晰，其中分离的想法我很喜欢。和我上面提到的分包也有相通的地方。

采用分包的方法，将routes使用monorepo的方式进行管理。可以根据引入的包来加载需要的路由。自然也能很好的支持没有merge的路由。会对结构及其他有较大改动。但觉得这好像是不错的方法。

在这里存在一个讨论点在于：三方路由的实现形式应当是怎样的？repo，pr还是npm包？

这个就看核心开发者的决断了~ 我个人偏好是 repo > npm > pr，执行起来做 repo（面向未来）和 pr（兼容现在）两个方案。

我翻了一遍 master 分支下的 routes，其实多数 route 还是比较简单的。可以考虑设计一个 .rsshub specification，然后实现单文件版的 route 加载，这个就很灵活了，从 URL 拉取或者 paste 都很方便。

单文件是我没想过的方法！

单站点多域名是可能的，我们保持使用自己的缩写，方便参照

现在的v2路由，只需要删除/只保留对应的文件夹，已经算是某种程度上的分包了把。而且默认路由都是懒加载，启动的时间是很快的