MediaWiki API：opensearch与query、generator与list的差异及疑问

Hey，我之前折腾MediaWiki API的时候也被这些参数绕晕过，刚好能给你掰扯清楚这些问题！

简单说，这俩是定位完全不同的接口：

• OpenSearch是专门为「快速搜索展示」设计的，返回的是固定结构的数组（搜索词、标题数组、摘要数组、URL数组），不用你再去解析复杂的嵌套JSON，直接就能拿来做搜索框的下拉提示或者简单搜索结果页，比如你调用的第一个接口，拿到的就是现成的可展示数据，非常省心。
• Query是MediaWiki API的「核心万能查询入口」，它的功能不止于搜索，还能查页面详情、编辑历史、分类、图片等等。它返回的是结构化的嵌套JSON，包含pageid、命名空间（ns）这些元数据，灵活性极高，适合你需要自定义数据、或者要获取更多页面相关信息的场景。比如你调用的第2、3个接口，都是基于Query来做搜索，但可以搭配不同参数拓展功能。

这俩都是Query接口下的参数，但逻辑完全不一样：

• List是直接返回「符合条件的结果列表」，比如你用list=search，API会直接给你搜索到的条目集合，每个条目包含标题、匹配度这些搜索相关的属性，就是单纯的搜索结果输出。
• Generator是一个「数据源生成器」——它不会直接返回搜索结果，而是先根据你的搜索条件生成一组页面ID（pageid），然后把这些pageid交给Query的其他模块（比如prop=info、prop=extracts）去查询更详细的页面信息。比如你调用的第2个接口，单独用generator=search时，返回的是pages对象，里面是每个匹配页面的基础信息，这是因为generator默认会让Query返回这些页面的基础数据，而不是搜索结果本身。
  举个实用场景：如果你想搜索“Albert”相关页面，同时还要拿到每个页面的编辑时间、页面长度，那用generator=search搭配prop=info就很合适，直接一次性搞定；而如果只是要搜索结果列表，用list=search更直接。

因为gsrprop是控制搜索结果本身属性的参数，但在generator模式下，API的逻辑是「先找到匹配的页面ID，再去查页面数据」，它不会保留搜索结果的snippet信息。如果想要在generator模式下拿到摘要，你需要搭配prop=extracts模块，同时设置摘要相关的参数，比如：

en.wikipedia.org/w/api.php?action=query&generator=search&gsrsearch=Albert&prop=extracts&exintro=true&format=json

这里exintro=true表示只返回页面的引言部分（也就是摘要），这样就能拿到每个页面的摘要内容了，gsrprop=snippet在generator模式下是无效的哦。

因为inprop=url是prop=info模块的参数，而list=search是独立的列表模块，它有自己的参数体系。要在list=search里拿到URL，你需要用srprop参数来指定要返回的属性，比如：

en.wikipedia.org/w/api.php?action=query&list=search&srsearch=Albert&srprop=snippet|url&format=json

这里srprop=snippet|url表示让搜索结果返回摘要和URL，这样就能得到你想要的内容了。inprop只在查询页面基础信息（比如用prop=info查询某个pageid的页面）时生效，和list=search不搭哦。

内容的提问来源于stack exchange，提问作者firefiber