尧图网站建设 
后端前端网页爬虫MCP 服务AI 技能【免费下载链接】AnimeGarden動漫花園 镜像站 | 动画 BT 资源聚合站 | 动画 BT 资源开放接口项目地址https://gitcode.com/gh_mirrors/an/AnimeGarden点击查看免费下载资源查询与收藏夹查询是 AnimeGarden 开放接口HTTP API 与animegarden/clientSDK的两大核心能力。本文以 docs/client/pagination.md 为骨架讲解统一pagination元数据模型、fetchResources多页累积语义、收藏夹结果的翻页续取方式以及旧complete字段的破坏性迁移路径并结合仓库源码与测试用例佐证每个约定。统一分页模型PaginationResultHTTP API 和客户端 SDK 将资源查询的分页信息统一放在pagination中三种场景GET /resources、GET /collection/{hash}、客户端CollectionFilter查询结果态共享同一个结构interface PaginationResult { page: number; pageSize: number; complete: boolean; }page当前页号从1开始pageSize请求的每页条数实际返回的资源可能更少例如末页、或服务端命中缓存时complete: true仅表示当前页之后没有更多匹配资源不保证调用方已经取得之前各页。这个语义很关键complete描述的是「服务端已知的匹配集合」的末尾而不是「调用方的遍历进度」。若调用方跳过前面的页直接请求第 N 页且complete: true并不意味着第 1N-1 页的数据已经拿到。在 SDK 中该类型定义于 packages/client/src/types.ts并配有「Pagination metadata shared by resource lists and individual collection results」的注释说明它就是为资源列表和收藏夹结果项共用而设计的。服务端响应校验位于 packages/client/src/api/validation.ts 的isPaginationPayload它要求page、pageSize均为数字、complete为布尔值三者缺一或类型不符即判为INVALID_RESPONSE对应测试见 packages/client/test/resources.test.ts把complete改为字符串no后返回ok: false。资源查询GET /resources与fetchResourcesGET /resources返回resources、pagination、filter、timestamp等字段。当前版本移除了与resources同级的旧complete字段——这是本文档对应的破坏性变更之一详见下文迁移章节。SDK 侧fetchResources成功时同样使用result.paginationimport { fetchResources } from animegarden/client; const result await fetchResources({ subject: 1234, page: 1, pageSize: 100 }); if (result.ok) { console.log(result.resources); console.log(result.pagination.page, result.pagination.pageSize, result.pagination.complete); }入参与默认值fetchResources的入参定义于 packages/client/src/types.ts分页相关字段为PaginationOptionstypes.ts参数类型默认值说明pagenumber1请求起始页从 1 开始pageSizenumber100每页条数见DefaultPageSizecountnumber无目标资源总数-1表示拉取全部匹配资源常量的实际定义在 packages/client/src/constants.tsDefaultPageSize 100、MaxRequestPageSize 1000。单页模式与多页累积模式fetchResources的循环逻辑位于 packages/client/src/api/resources.ts它会根据入参自动切换两种模式未传count单页模式等价于count pageSize只请求一次。传了count多页模式以MaxRequestPageSize1000覆盖pageSize作为每页请求量从startPage起逐页请求直到满足以下任一条件已取到count条资源count 0时视为Number.MAX_SAFE_INTEGER即拉取全部某页返回pagination.complete true某页返回 0 条新资源请求失败或signal被中止。关键语义SDK 使用count连续请求多页时resources累积各页资源pagination描述最后一次成功取得的页。请求达到指定count后可能提前停止此时pagination.complete仍可能为false。这正是「complete不等于遍历完成」的又一体现count提前达标时遍历停止但服务端仍有后续页因此complete保持false调用方不应据此误判。多页模式下 SDK 会做两件事按href去重resources.ts并在返回前按createdAt降序排序uniq函数resources.ts。每取到一页新资源还会触发progress回调types.ts回调参数包含本页新增资源delta、当前page和searchParams回调抛出的异常不会被吞掉而是直接向外抛出测试见 packages/client/test/resources.test.ts。失败时的部分结果fetchResources失败时返回的ClientResult仍携带已取得的resources、pagination、filter、timestamp类型见 resources.ts其中pagination可能为undefined即首页就失败。约定详见 docs/client/error-model.md核心是多页请求中途某页失败已取到的页会保留返回ok: false的同时把部分结果交回调用方。测试keeps partial resources but marks the result failed when a later page fails验证了这一点resources.test.ts第一页成功、第二页 503最终ok: false、code: SERVER_ERROR、resources长度为 1。服务端的分页约束服务端在GET /resources处理器中会先解析分页参数并做合法性校验apps/server/src/server/routes/resources.ts其中assertResourcesPaginationapps/server/src/server/utils/resources-query.ts限制(page - 1) * pageSize pageSize不得超过MAX_RESOURCES_OFFSET_LIMIT 10000超过则返回 400ResourcesDeepPaginationError。也就是说资源列表的有效查询窗口约为 offset 上限 10000 条极端深翻页会直接被服务端拒绝这也是文档强调用count累积拉取而非盲目深翻页的原因之一。响应还带有Cache-Control: public, max-age3005 分钟缓存头resources.ts。收藏夹查询GET /collection/{hash}与fetchCollectionGET /collection/{hash}返回results数组其中每个results[i]与filters[i]一一对应单项结构为type CollectionResourcePage { resources: Resource[]; pagination: PaginationResult; filter: ResolvedFilterOptions | undefined; };对应 SDK 类型CollectionResourcesResult的results项定义见 packages/client/src/types.tsCollectionFilter携带查询结果态resources与pagination的类型约束见 types.ts。默认分页与「无入参」收藏夹接口的每个筛选条件默认查询第1页每页最多1000条。收藏夹接口没有新增page或pageSize入参也没有与resources同级的complete字段——分页信息只存在于每个结果项的pagination中。测试createCollectionResponse中pageSize: 1000、page: 1与文档一致packages/client/test/collection.test.ts。续取更多资源当某一筛选条件的结果超过一页、需要更多资源时文档给出的标准做法是取出该结果项results[i]用其对应的filters[i]筛选条件调用/resources或 SDKfetchResources传入page: results[i].pagination.page 1和相同的pageSize通过 HTTP 继续查询时可复用filters[i].searchParams其值为序列化后的查询字符串见CollectionFilter.searchParams类型在此基础上设置page和pageSize。这样保证翻页参数与收藏夹服务端首次查询时的分页窗口完全一致不会出现「pageSize 不一致导致页边界错位」的问题。fetchCollection的实现与校验见 packages/client/src/api/collection.ts每个结果项必须通过normalizeCollectionResultPayloadcollection.ts校验要求pagination结构合法isPaginationPayload。CollectionFilter查询结果态与会话隔离客户端CollectionFilter的查询结果态也使用resources和pagination。这两个字段属于查询结果元数据提交收藏夹generateCollection即PUT/POST /collection时会被排除请求体构造阶段显式将每个 filter 的resources、pagination以及旧客户端遗留的complete置为undefinedcollection.ts计算收藏夹哈希hashCollection时同样被排除排序后的 filters 会删除name、searchParams、resources、pagination与旧complete字段后再序列化packages/client/src/collections.ts注释「Query pagination must not change a saved collections identity」。即resources与pagination不属于保存的筛选条件不会进入收藏夹的持久化内容和身份标识。测试excludes query results and pagination from collection hashes and generation requestscollection.test.ts验证带查询态与不带查询态的收藏夹哈希一致且PUT请求体严格等于无查询态的原始 collection。破坏性变更迁移旧的分页完成字段不再保留兼容别名需要同步更新调用方、响应样例和测试断言。迁移对照表位置旧路径新路径HTTP/resources响应result.completeresult.pagination.complete收藏夹结果项result.results[i].completeresult.results[i].pagination.completeCollectionFilter查询结果态filter.completefilter.pagination.completeSDKfetchResources已有的result.pagination.*路径保持不变因此以 SDK 消费资源的调用方通常无需改动。若手动构造收藏夹结果项或CollectionFilter查询结果态需要提供完整的pagination: { page, pageSize, complete }不能只把complete挪个位置——因为isPaginationPayload要求三个字段齐备且类型正确。服务端校验层面对这一破坏性变更的执行证据十分明确fetchCollection若收到形如{ resources, complete }的旧结构缺pagination会整体判为INVALID_RESPONSE测试rejects the legacy collection result shape without paginationcollection.test.ts专门构造了把pagination.complete平移到item.complete的旧响应断言ok: false且code: INVALID_RESPONSE。迁移步骤建议先升级 SDK 到包含pagination归一化的版本让fetchResources/fetchCollection返回新结构搜索代码中的\.complete访问点逐一对照上表改为pagination.complete更新响应样例如 examples/api.http与测试断言中的旧字段若手动构造结果项按isPaginationPayload的要求补齐page、pageSize、complete三字段。小结AnimeGarden 将PaginationResult作为资源列表、收藏夹结果项与CollectionFilter查询结果态的统一分页元数据page从 1 开始、pageSize为请求值实际可能更少、complete只表示「当前页之后无更多匹配」。多页拉取请使用fetchResources的count参数-1拉取全部它会自动按 1000 条每页请求并去重累积收藏夹续取则复用对应filters[i].searchParams与page: results[i].pagination.page 1。迁移旧complete字段时务必提供完整的pagination对象服务端与 SDK 校验均不接受只有complete的旧结构。赞分享后端前端网页爬虫MCP 服务AI 技能【免费下载链接】AnimeGarden動漫花園 镜像站 | 动画 BT 资源聚合站 | 动画 BT 资源开放接口项目地址https://gitcode.com/gh_mirrors/an/AnimeGarden点击查看免费下载相关推荐Kornia 几何变换 align_corners 约定统一破坏性变更解析与迁移指南Kornia 几何变换 align_corners 约定统一破坏性变更解析与迁移指南 Kornia 在 0.9 系列引入了一次影响面极广的几何变换修正 wa计算机视觉人工智能深度学习图像处理Pillow 3.0.0 版本迁移指南破坏性变更解析与多页图像保存实战Pillow 3.0.0 版本迁移指南破坏性变更解析与多页图像保存实战 本篇技术指南基于 Pillow 仓库的 3.0.0 版本发布说明 https://li图像处理计算机视觉Prometheus 3.0 迁移指南破坏性变更全解与源码级迁移实践Prometheus 3.0 迁移指南破坏性变更全解与源码级迁移实践 本文围绕 Prometheus 3.0 的官方迁移指南 docs/migration.可观测性指标监控时序数据库告警上一篇别再让质谱数据在软件间接力MZmine 3 代谢组学分析全流程实战下一篇MZmine 3 质谱数据处理实战一天之内把 60 份样本从原始文件变成带注释的峰表创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 资源与收藏夹分页：AnimeGarden 统一分页模型与破坏性变更迁移指南
后端前端网页爬虫MCP 服务AI 技能【免费下载链接】AnimeGarden動漫花園 镜像站 | 动画 BT 资源聚合站 | 动画 BT 资源开放接口项目地址https://gitcode.com/gh_mirrors/an/AnimeGarden点击查看免费下载资源查询与收藏夹查询是 AnimeGarden 开放接口HTTP API 与animegarden/clientSDK的两大核心能力。本文以 docs/client/pagination.md 为骨架讲解统一pagination元数据模型、fetchResources多页累积语义、收藏夹结果的翻页续取方式以及旧complete字段的破坏性迁移路径并结合仓库源码与测试用例佐证每个约定。统一分页模型PaginationResultHTTP API 和客户端 SDK 将资源查询的分页信息统一放在pagination中三种场景GET /resources、GET /collection/{hash}、客户端CollectionFilter查询结果态共享同一个结构interface PaginationResult { page: number; pageSize: number; complete: boolean; }page当前页号从1开始pageSize请求的每页条数实际返回的资源可能更少例如末页、或服务端命中缓存时complete: true仅表示当前页之后没有更多匹配资源不保证调用方已经取得之前各页。这个语义很关键complete描述的是「服务端已知的匹配集合」的末尾而不是「调用方的遍历进度」。若调用方跳过前面的页直接请求第 N 页且complete: true并不意味着第 1N-1 页的数据已经拿到。在 SDK 中该类型定义于 packages/client/src/types.ts并配有「Pagination metadata shared by resource lists and individual collection results」的注释说明它就是为资源列表和收藏夹结果项共用而设计的。服务端响应校验位于 packages/client/src/api/validation.ts 的isPaginationPayload它要求page、pageSize均为数字、complete为布尔值三者缺一或类型不符即判为INVALID_RESPONSE对应测试见 packages/client/test/resources.test.ts把complete改为字符串no后返回ok: false。资源查询GET /resources与fetchResourcesGET /resources返回resources、pagination、filter、timestamp等字段。当前版本移除了与resources同级的旧complete字段——这是本文档对应的破坏性变更之一详见下文迁移章节。SDK 侧fetchResources成功时同样使用result.paginationimport { fetchResources } from animegarden/client; const result await fetchResources({ subject: 1234, page: 1, pageSize: 100 }); if (result.ok) { console.log(result.resources); console.log(result.pagination.page, result.pagination.pageSize, result.pagination.complete); }入参与默认值fetchResources的入参定义于 packages/client/src/types.ts分页相关字段为PaginationOptionstypes.ts参数类型默认值说明pagenumber1请求起始页从 1 开始pageSizenumber100每页条数见DefaultPageSizecountnumber无目标资源总数-1表示拉取全部匹配资源常量的实际定义在 packages/client/src/constants.tsDefaultPageSize 100、MaxRequestPageSize 1000。单页模式与多页累积模式fetchResources的循环逻辑位于 packages/client/src/api/resources.ts它会根据入参自动切换两种模式未传count单页模式等价于count pageSize只请求一次。传了count多页模式以MaxRequestPageSize1000覆盖pageSize作为每页请求量从startPage起逐页请求直到满足以下任一条件已取到count条资源count 0时视为Number.MAX_SAFE_INTEGER即拉取全部某页返回pagination.complete true某页返回 0 条新资源请求失败或signal被中止。关键语义SDK 使用count连续请求多页时resources累积各页资源pagination描述最后一次成功取得的页。请求达到指定count后可能提前停止此时pagination.complete仍可能为false。这正是「complete不等于遍历完成」的又一体现count提前达标时遍历停止但服务端仍有后续页因此complete保持false调用方不应据此误判。多页模式下 SDK 会做两件事按href去重resources.ts并在返回前按createdAt降序排序uniq函数resources.ts。每取到一页新资源还会触发progress回调types.ts回调参数包含本页新增资源delta、当前page和searchParams回调抛出的异常不会被吞掉而是直接向外抛出测试见 packages/client/test/resources.test.ts。失败时的部分结果fetchResources失败时返回的ClientResult仍携带已取得的resources、pagination、filter、timestamp类型见 resources.ts其中pagination可能为undefined即首页就失败。约定详见 docs/client/error-model.md核心是多页请求中途某页失败已取到的页会保留返回ok: false的同时把部分结果交回调用方。测试keeps partial resources but marks the result failed when a later page fails验证了这一点resources.test.ts第一页成功、第二页 503最终ok: false、code: SERVER_ERROR、resources长度为 1。服务端的分页约束服务端在GET /resources处理器中会先解析分页参数并做合法性校验apps/server/src/server/routes/resources.ts其中assertResourcesPaginationapps/server/src/server/utils/resources-query.ts限制(page - 1) * pageSize pageSize不得超过MAX_RESOURCES_OFFSET_LIMIT 10000超过则返回 400ResourcesDeepPaginationError。也就是说资源列表的有效查询窗口约为 offset 上限 10000 条极端深翻页会直接被服务端拒绝这也是文档强调用count累积拉取而非盲目深翻页的原因之一。响应还带有Cache-Control: public, max-age3005 分钟缓存头resources.ts。收藏夹查询GET /collection/{hash}与fetchCollectionGET /collection/{hash}返回results数组其中每个results[i]与filters[i]一一对应单项结构为type CollectionResourcePage { resources: Resource[]; pagination: PaginationResult; filter: ResolvedFilterOptions | undefined; };对应 SDK 类型CollectionResourcesResult的results项定义见 packages/client/src/types.tsCollectionFilter携带查询结果态resources与pagination的类型约束见 types.ts。默认分页与「无入参」收藏夹接口的每个筛选条件默认查询第1页每页最多1000条。收藏夹接口没有新增page或pageSize入参也没有与resources同级的complete字段——分页信息只存在于每个结果项的pagination中。测试createCollectionResponse中pageSize: 1000、page: 1与文档一致packages/client/test/collection.test.ts。续取更多资源当某一筛选条件的结果超过一页、需要更多资源时文档给出的标准做法是取出该结果项results[i]用其对应的filters[i]筛选条件调用/resources或 SDKfetchResources传入page: results[i].pagination.page 1和相同的pageSize通过 HTTP 继续查询时可复用filters[i].searchParams其值为序列化后的查询字符串见CollectionFilter.searchParams类型在此基础上设置page和pageSize。这样保证翻页参数与收藏夹服务端首次查询时的分页窗口完全一致不会出现「pageSize 不一致导致页边界错位」的问题。fetchCollection的实现与校验见 packages/client/src/api/collection.ts每个结果项必须通过normalizeCollectionResultPayloadcollection.ts校验要求pagination结构合法isPaginationPayload。CollectionFilter查询结果态与会话隔离客户端CollectionFilter的查询结果态也使用resources和pagination。这两个字段属于查询结果元数据提交收藏夹generateCollection即PUT/POST /collection时会被排除请求体构造阶段显式将每个 filter 的resources、pagination以及旧客户端遗留的complete置为undefinedcollection.ts计算收藏夹哈希hashCollection时同样被排除排序后的 filters 会删除name、searchParams、resources、pagination与旧complete字段后再序列化packages/client/src/collections.ts注释「Query pagination must not change a saved collections identity」。即resources与pagination不属于保存的筛选条件不会进入收藏夹的持久化内容和身份标识。测试excludes query results and pagination from collection hashes and generation requestscollection.test.ts验证带查询态与不带查询态的收藏夹哈希一致且PUT请求体严格等于无查询态的原始 collection。破坏性变更迁移旧的分页完成字段不再保留兼容别名需要同步更新调用方、响应样例和测试断言。迁移对照表位置旧路径新路径HTTP/resources响应result.completeresult.pagination.complete收藏夹结果项result.results[i].completeresult.results[i].pagination.completeCollectionFilter查询结果态filter.completefilter.pagination.completeSDKfetchResources已有的result.pagination.*路径保持不变因此以 SDK 消费资源的调用方通常无需改动。若手动构造收藏夹结果项或CollectionFilter查询结果态需要提供完整的pagination: { page, pageSize, complete }不能只把complete挪个位置——因为isPaginationPayload要求三个字段齐备且类型正确。服务端校验层面对这一破坏性变更的执行证据十分明确fetchCollection若收到形如{ resources, complete }的旧结构缺pagination会整体判为INVALID_RESPONSE测试rejects the legacy collection result shape without paginationcollection.test.ts专门构造了把pagination.complete平移到item.complete的旧响应断言ok: false且code: INVALID_RESPONSE。迁移步骤建议先升级 SDK 到包含pagination归一化的版本让fetchResources/fetchCollection返回新结构搜索代码中的\.complete访问点逐一对照上表改为pagination.complete更新响应样例如 examples/api.http与测试断言中的旧字段若手动构造结果项按isPaginationPayload的要求补齐page、pageSize、complete三字段。小结AnimeGarden 将PaginationResult作为资源列表、收藏夹结果项与CollectionFilter查询结果态的统一分页元数据page从 1 开始、pageSize为请求值实际可能更少、complete只表示「当前页之后无更多匹配」。多页拉取请使用fetchResources的count参数-1拉取全部它会自动按 1000 条每页请求并去重累积收藏夹续取则复用对应filters[i].searchParams与page: results[i].pagination.page 1。迁移旧complete字段时务必提供完整的pagination对象服务端与 SDK 校验均不接受只有complete的旧结构。赞分享后端前端网页爬虫MCP 服务AI 技能【免费下载链接】AnimeGarden動漫花園 镜像站 | 动画 BT 资源聚合站 | 动画 BT 资源开放接口项目地址https://gitcode.com/gh_mirrors/an/AnimeGarden点击查看免费下载相关推荐Kornia 几何变换 align_corners 约定统一破坏性变更解析与迁移指南Kornia 几何变换 align_corners 约定统一破坏性变更解析与迁移指南 Kornia 在 0.9 系列引入了一次影响面极广的几何变换修正 wa计算机视觉人工智能深度学习图像处理Pillow 3.0.0 版本迁移指南破坏性变更解析与多页图像保存实战Pillow 3.0.0 版本迁移指南破坏性变更解析与多页图像保存实战 本篇技术指南基于 Pillow 仓库的 3.0.0 版本发布说明 https://li图像处理计算机视觉Prometheus 3.0 迁移指南破坏性变更全解与源码级迁移实践Prometheus 3.0 迁移指南破坏性变更全解与源码级迁移实践 本文围绕 Prometheus 3.0 的官方迁移指南 docs/migration.可观测性指标监控时序数据库告警上一篇别再让质谱数据在软件间接力MZmine 3 代谢组学分析全流程实战下一篇MZmine 3 质谱数据处理实战一天之内把 60 份样本从原始文件变成带注释的峰表创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考