关于「列表页深度有上限」：要不要内置一种不绑定站点的搜索型信源？

[CochraneK]

这是 #280 的讨论版。#280 里放了完整数据（覆盖面实测、入池倍率、成本口径）和设计细节，这里不重复，只问方向——因为这条如果不该进上游，数据再全也没用。

问题一句话

现有的 5 种采集器都要求先有一个稳定入口：一个 feed、一个栏目列表、一个接口。但很多值得知道的东西并不长在入口上——部委的批复、法院判决、检察院未保案例、行政复议决定，都不进任何列表页；而列表页本身半年还改一次版。

我在自己的站上加了一种 search kind 绕过去：不绑定站点，用查询词打网页搜索接口，把结果列表当条目读回来。效果是同一批源里它带回的条目比列表页源多一个数量级。但这不构成「上游也该有」的理由，所以想问三个问题。

三个想问的

1. 要不要内置？ 也可能它天然属于各站的定制层，上游只需要保住采集器的扩展点，不必自己实现。

2. 如果要，最小的形状是什么？ 完整 kind 大约 450 行，外加一个新依赖（一个按次计费的搜索接口）。更轻的做法是只抽一层 searchProvider 接口：上游定义形状和幂等/落位语义，各站自带实现，默认不启用——这样零依赖也能落地。

3. 计费口径怎么记？ 按次计费的第三方工具要不要进 service_prices / receipts？不进的话成本对不上账，进的话现有价格表只有 token 口径。

我自己的顾虑

引入付费接口，等于给所有部署加一个「要么充值、要么这类源不可用」的分支。如果上游的取向是默认零外部依赖，那这条就不该进，我也接受——把它留在各站的定制层，反而是更干净的边界。

另外想知道：有没有别的 fork 已经自己写过这一层？ 如果有，直接对比实现比我从零提 PR 省事得多。

（如果方向认可、也接受第 2 条的轻量形状，我可以按 upstream/main 重写成最小 patch 提 PR，去掉所有领域相关内容。）

[KKKKhazix]

感谢把方向问题单独拎出来问，三个问题都问在点上。这件事要先在产品上定一下，定了我在这里和 #280 一起答复。

[KKKKhazix]

定了，三个问题一起答：

1. 不内置。 这个缺口主要在你这类方向上。内置之后，所有部署都要多一个“充值或者这类源不可用”的分支，你的顾虑我也认同。
2. 只留 searchProvider 接口也先不做。 开源版里没有实现在用，CI 测不到，形状也定不准，容易放着放着就坏了。
3. 计费口径就不用动了。 这部分留在你的定制里记账。

有没有别的 fork 写过这一层，我这边不掌握。#280 已关闭，实测数据还留在那里，方便后来的人查。谢谢你先问方向，省了一轮白写的 PR。