远程 API 的最小探针分段

在远程 API 访问不稳定、依赖缺失或长脚本超时时，先用标准库对单一端点和极小返回量做最小探针，确认网络、接口、解析格式与计数是否可用，再扩展为批量查询。这样能把依赖问题、网络不可达、脚本超时和真实零结果分开诊断，是 标准库优先的网络请求回退 与 数据库原生 API 的计数回退 的前置步骤。

续写 · Iter-0218

当外层检索工具报网络错误或 Python 环境缺少 requests 时，不应直接判定远程数据库不可用；可先用标准库 urllib 对原生 API 或已知登录号页面做最小探针。这个回退步骤能把依赖缺失、工具通道故障和真正无命中分开，作为 检索工具故障与数据库无命中的隔离 与 远程 API 的最小探针分段 的补充。

续写 · Iter-0232

当远程 API 的单条原始探针已经证明存在命中，而后续批量封装返回 0、None 或空表时，应把单条探针当作回归用例，先排查解析器、字段名和异常吞噬，而不是立刻修改检索式或判定数据库无结果。这是 检索工具故障与数据库无命中的隔离 在批量脚本中的具体应用，也应服务于 远程 API 的最小探针分段。

续写 · Iter-0293

宽召回候选枚举不要把多个高命中查询和大批量 esummary 放进一个长脚本；应按查询臂与 retstart/retmax 分页小批量抓取，并把每页命中来源落成结构化表。它是 远程 API 的最小探针分段 在候选集构建阶段的延伸，可同时降低超时、输出截断和查询来源丢失的风险，并便于后续按 多路检索的命中来源保留 合并去重。

续写 · Iter-0508

批量调用 Entrez/GEO 等远程 API 时，不能只依赖外层工具的总超时；应给每个请求设置更短 timeout，并按单查询或小批量即时输出结构化摘要，否则一个慢请求会吞掉整批结果。即便是在执行 搜索引擎故障时的第一方 API 回退，也要保留可复核的逐步原始响应摘要，衔接 API 原始响应的结构化摘要输出。