采集规则编写进阶：定位方式选择与常见问题规避
📱 Mozilla/5.0 (compatible; DataForSeoBot/1.0; +https://dataforseo.com/dataforseo-bot)
🔗 /ab1b12a91a47.html
📄
一套稳定耐用的采集规则，本质上是在准确性和韧性之间找平衡。规则既要命中所需要的字段，也要能扛住页面结构和加载方式的偶尔调整。很多采集任务中途夭折，往往不是方向错了，而是规则写得过于脆弱，一次页面改版就让整套逻辑失效。下文从规则的基本构成讲起，围绕定位方式的选择和高频故障的排查给出可落地的处理思路。
1. 拆解采集逻辑的三块基石
任何一套采集规则，都可以被拆解成三个相互配合的环节，清楚理解它们的边界，是写出高质量规则的前提。
- 抓取调度：明确抓取的起点和范围，它可以是写死的几个URL，也可以是根据列表页或外部文件动态生成的一批待抓取地址。
- 字段抽取：从拿到的响应内容中锁定目标数据，常用手段包括XPath、CSS选择器、正则表达式，以及针对接口返回的JSONPath。
- 数据后处理：对抽取出的原始内容做清洗，例如去掉多余的空白字符、统一时间格式、剔除重复项，并对缺失字段做兜底填充。
动手写规则前，先判断任务属于列表型还是详情型。列表页通常只需采集条目链接和少许摘要，逻辑简单；详情页字段多，且不同页面之间字段缺省情况不一，容错要求明显更高。以房产信息为例，列表页拿标题和链接就行，但进入详情页后，各楼盘在户型、面积、朝向等字段上可能有的有、有的没有，规则就得考虑缺省值如何处理。
2. 不同定位方式的适用场景
定位方式直接决定规则的生命周期和排查成本，这世上没有放之四海皆准的方案，只能根据页面本身的特征来做权衡。
2.1 XPath：结构复杂时的稳妥靠山
当页面嵌套层级深、标签结构乱时，XPath的表达能力优势明显，比如用 //div[contains(@class, 'mod')]//p 就能框选某个区块内的全部段落。不过，路径一长，调试时的阅读负担就上来了，而且它对层级变化极为敏感，哪怕只是多包了一层容器，规则就可能直接失效。
2.2 CSS选择器：扁平页面的省力工具
如果页面class命名清晰、结构又不太深，那么一句 .item-title 就能利落地拿到值。可当同一个class在页面上被大量重复使用时，就得靠子选择器或伪类来缩小范围，比如从列表里取第二个条目的标题，可以写成 .list li:nth-child(2) span 这样。
2.3 正则表达式：最后手段，务必克制
目标数据藏在非结构化文本中时，正则往往是唯一能开锁的钥匙，比如从客服聊天记录里抽出订单号。但它灵活过头，难写难读，一个疏忽就会误匹配到不想要的内容。能用XPath或CSS解决的场景，就别把正则请出来。
2.4 JSONPath：抓异步接口的聪明做法
如今很多页面内容靠接口异步加载，用开发者工具看网络面板，找到真实的XHR请求，直接解析JSON响应，远比对着渲染后的DOM树抽字段来得稳。JSONPath取值直接，语法和XPath相近，上手也不难。
这里有一个值得刻在脑子里的原则：尽量别用绝对路径。绝对路径从根节点一路写到底，页面只要哪天多套了一层div就全军覆没；相对路径只看目标元素周边的上下文关系，对改版的承受力强得多。
3. 分页与动态请求的应对套路
分页看着简单，翻车频率却极高。多数站点把页码放在URL参数里，循环替换就行。但有两类变数要注意：一是页码藏在JavaScript发起的请求体里，这时得同步修改POST数据；二是部分站点虽然URL不变，但返回内容取决于Cookie或时间戳参数，比如列表接口带了个由JS生成的签名。对此，合理的策略是先抓取首页响应，再从中提取翻页所需的参数，再拼出后续页面的请求。
4. 高频故障排查与规则自保技巧
采集跑久了，难免遇到各种怪问题。以下几条是根据实操经验整理的常见故障和处理方向。
- 页面返回非目标内容：先确认是否被跳转到验证码页或登录页，可以在规则里对响应特征做一次前置校验，比如检查标题里是否包含预期关键词，不匹配就放弃本条抓取。
- 字段内容乱码：多数是编码判断不准造成的，在发起请求时显式指定响应编码，或对抓到的文本做强制转码处理。
- 同一字段不同页面格式不一：例如有的地方时间格式是2025-01-01，有的却是2025/1/1，只靠单一抽取必然出错，应在后处理阶段统一做格式归一化。
- 数据偶发缺漏：多为目标元素在部分页面确实不存在，可以在抽取后增加空值判断，填入预设的默认值，并输出日志便于事后复核。
5. 常见问题
5.1 同一张页面，为什么XPath需要经常改？
通常是因为页面前端频繁调整DOM结构，比如改了class名、新增了嵌套层，或者把静态内容改成了异步渲染。建议优先用相对路径和包含匹配（如contains），尽量缩短路径深度，实在频繁变动，就考虑改走接口方案。
5.2 正则写不好，有没有简单的替换思路？
如果目标字段本身有明确的边界特征，可以先用XPath或CSS取到更小的文本块，再在这个小范围内用正则抓取，能降低匹配成本。另一个思路是把正则匹配的部分拆成多步：先按分隔符切分，再定位目标片段。
5.3 采集时被限制了，怎么判断是规则问题还是被封了？
关键是看响应内容。如果页面上出现了滑块、验证码图片或类似提示文字，一般是IP或账号被限流，跟规则本身无关。此时应检查请求头（如User-Agent、Referer）是否完整，并适当降低请求频率，必要时设置随机延时。
6. 总结
一套扎实的采集规则，离不开清晰的任务拆解、贴合页面情况的定位方式，以及面对动态内容和异常响应时的应急机制。建议在规则上线前，先拿一小批真实页面做试跑，确认字段完整性和容错逻辑都到位再放开全量抓取。同时，给规则留好日志输出接口，方便日后定位是哪一步出了问题。优先采用相对路径，对接口型数据直接解析JSON，处理文本时克制使用正则，这三条是让采集脚本长期稳定运行的关键。
