FastPeopleSearch 返回 200 却没有正文？识别验证页，避免采集空数据

程序统计显示请求全部成功，数据表里却出现一排空值。若在获准的 FastPeopleSearch 读取任务中遇到这种现象，先别急着修改选择器：HTTP 200 说明收到了成功状态的响应，不证明返回的就是你想要的正文。

验证提示、站点说明页或其他正常返回的页面，都可能不满足当前任务。本文讨论结果验收，不声明该站当前一定存在某种验证，也不将任何平台视为可随意批量获取个人资料的数据源。

先确认正文身份，再考虑提取字段

为获准测试目标定义正向证据，例如预期页面类型、固定结构和自己的测试标识。不要只写一份“验证码关键词黑名单”：页面可能包含相关文字的帮助说明，验证提示也可能换一种表达。正向证据与异常线索需要结合使用。

最终地址也应核对。请求被转到首页、说明页或其他资源时，内容可能完全有效，却不是本次任务要读取的对象。能打开页面与完成任务，是不同的验收标准。

将结果放进不同通道

这些是应用自己的分类，不是某个 API 的实际状态码。根据接入文档解释服务返回，再映射到业务结果，避免多个模块各自猜测同一份正文。

空字段不等于“资料不存在”

如果没有取得正确正文，就没有足够证据对目标内容作出存在或不存在的判断。不要把访问失败转成空记录，更不要用它覆盖已有的有效结果。把本次尝试状态与上次成功观察分开保存，并明确时间。

即便正文正确，正常字段缺失也可能是合法情况。必需字段、允许空值和不适用字段应分别定义；不要为了让通过率好看，把所有字段都设为可选。

先用自己的样本测试验收器

无需额外访问个人资料，就可以构造四种本地输入：预期页面、抽象验证提示、普通说明页、结构残缺页面。确认每种输入进入正确通道。再增加“页面类型正确但测试标识不匹配”的样本，检查身份判断是否真正生效。

测试程序还应覆盖错误处理：校验未通过时是否停止写入，日志是否给出可解释分类，以及敏感参数是否已被删除。把判断规则集中管理，比在每个解析器里复制几行字符串判断更容易维护。

穿云API接入完成，也要通过同一套验收

若实际问题指向可处理的验证流程，可评估穿云API。用同样的获准目标和验收规则比较结果，而不是因为换了服务就放宽“有效正文”的定义。站点兼容性需要单独确认，不以一次状态码变化替代测试。

最后分别统计获取结果、正文校验结果和字段校验结果。这样看到“200 很多、有效内容很少”时，能直接定位问题所在。采集系统的价值不是请求计数漂亮，而是只让可以证明正确、且符合使用范围的结果进入下一步。