采集规则编写入门到精通：定位方式与翻页避坑指南

📍 WDQWDWQD987AAAAA:216.73.217.177
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1828597fd432.html
📄

采集规则是整个数据抓取流程的中枢，决定了你能从目标页面稳定拿到哪些字段，以及抓取过程能否长期顺畅运行。一份严谨的规则不仅提升数据获取速度，还能显著降低访问被限制的可能性。下面从规则的基本构造讲起，逐步拆解定位方式的选择与实战中常见的陷阱。

1. 采集规则的三大组成部分

无论你使用现成工具还是自行写脚本，任何采集规则都可以划分为三个紧密衔接的环节：入口发起、目标锁定与结果整理。入口发起决定从哪个地址开始请求；目标锁定负责在返回的HTML或接口数据里找出你需要的具体内容；结果整理则保证最终落地的数据干净、统一。

动手之前先想清楚你的任务边界。若只是抓取列表页中每个条目的标题与跳转链接，规则相对轻量；若还要进入每个详情页去拿规格、库存、评价等更多信息，就必须考虑字段缺失或异常的情况，规则复杂度会成倍上升。以比价场景举例，列表页规则只需要循环解析并拼接下一页地址，详情页则要为每一个目标字段写单独的处理逻辑，同时兼顾有的商品没有折扣价的现实。

新手建议先通过图形化抓取工具跑通一条简单流程，再观察工具自动生成的规则写法，这比直接啃语法文档要直观得多，也能帮你更快建立对页面结构的直觉。

2. 主流定位方式的选用与取舍

定位方式选得对不对，直接关系到规则的健壮性和维护成本。当前常用方法各有长处，也有明显局限。

2.1 XPath与CSS选择器

XPath处理层级深、结构复杂的页面最稳妥。比如只想取正文区域里所有段落，用 //div[contains(@class,'article')]//p 就能精准命中。缺点是表达式一旦写长，可读性下降，而且依赖具体标签层级，页面小幅调整就可能失效。

CSS选择器语法紧凑，多数情况下解析速度优于XPath，对结构扁平的页面（例如新闻列表）非常顺手。值得注意的是，当页面上有大量元素共享同一个类名时，需要用子选择器或相邻兄弟选择器进一步收窄范围，避免误抓。

2.2 正则表达式与JSONPath

正则表达式适合在纯文本中捞出特定格式的信息，比如从一段描述里提取手机号或单号。它灵活但容易出错，表达稍复杂就很难调试，建议只在其他定位方式难以胜任时才使用，像是处理夹杂在HTML里的JSONP回调数据。

JSONPath则是现代网站动态加载场景下的首选。如果数据来自Ajax异步请求，直接打开浏览器开发者工具，找到XHR请求返回的内容，用JSONPath取其中的字段，远比啃HTML源码稳定。接口结构通常比页面DOM固定，改版频率也低。

一个常见教训：尽量使用相对路径定位元素，而不是从html根节点写到底的绝对路径。绝对路径对包裹层异常敏感，哪怕只是多加了一个div，整条规则就会全面失效，排查起来相当耗时。

3. 翻页与无限滚动场景的规则设计

多数采集任务逃不开多页数据的获取。传统分页通常在链接或URL参数中包含页码，可以直接把下一页地址作为新的请求入口，循环直到条件结束。常见做法是先抓取页面中带有页码的链接列表，再按顺序遍历。

遇到“加载更多”式按钮或无限滚动时，观察浏览器控制台里触发了哪些网络请求。这类操作一般对应一个分页接口，返回的往往是JSON数据。把规则的重点从解析页面DOM转移到解析接口返回值，效率会翻倍，同时也降低了对页面布局变化的敏感度。

  1. 触发加载更多操作，在开发者工具中定位到对应的请求URL。
  2. 确认请求带有的参数（通常是页数或偏移量）如何变化。
  3. 直接将此接口地址作为规则入口，修改参数值循环请求。

防坑提醒：有些翻页URL在第一次和第二次点击时返回的页面结构存在差异（例如前几页带着广告位），务必对比至少两页的HTML结构差异，再固化规则，避免遗漏或重复数据。

4. 高频踩坑点与规避方法

现场排查过不少采集规则的故障，很多问题并非硬件或网络因素，而是规则自身的细节疏忽。

4.1 请求频率过快导致封禁

规则里没有写入合理的延时或请求间隔，导致短时间内发出大量请求，触发服务器防护。建议在请求入口模块中设定随机间隔，同时搭配每次请求后的状态码判断，一旦出现403或429，主动停止并拉长等待时间。

4.2 遗漏异常数据的处理

数据清洗阶段如果没有设置缺省值，碰到价格字段为空时会直接报错中断整批次抓取。提前约定好：空值填充什么字符，类型转换失败是跳过还是保留原样，这些判断要在规则里写清楚。

4.3 仅靠固定类名定位

部分网站会在不同页面复用相同的类名却展示不同内容，或者类名里带了随机后缀。此时建议结合父级结构或文本内容做二次校验，也可以优先抓取页面中嵌入的JSON数据（如基于Next.js或Nuxt.js搭建的站点的数据层），比DOM更靠谱。

5. 规则后续维护的现实问题

规则写完上线只是开始，网站结构随时可能调整，定期自检值得纳入习惯。建议把采集目标的关键字段数量纳入监控，比如某列表页昨天能取到40条商品，今天突然只有20条，那大概率是定位失效，而不是货源真减少了。

同时，尽量避免在规则里写死全部逻辑。把URL前缀、请求头参数、选择器写在配置文件中，改版时只动配置不改代码，维护成本会显著下降。

6. 常见问题

6.1 页面结构改变后，如何快速判断是哪里失效了？

打开最新页面源码，与你规则中的定位表达式做对比。优先检查类名是否变化、目标元素是否被移入新的父容器。先用浏览器控制台测试单条表达式是否能命中元素，再逐条排查多条表达式。如果页面改为前后端分离，直接改抓接口数据往往更省事。

6.2 XPath和CSS选择器，哪个对新手更友好？

如果页面结构不复杂，CSS选择器上手更快，写法直观。但涉及复杂嵌套条件时，XPath表达力更强，能实现按文本内容匹配、按位置索引等逻辑。两种都建议掌握基础，视页面情况随时切换。

6.3 采集规则频繁被封IP，是定位方式的问题吗？

多数情况和定位方式无关，而是请求行为太像机器逻辑——毫无间隔的连续请求、固定的请求头顺序、异常的访问频率。优先调整请求间隔与并发数量，并轮换User-Agent，观察是否改善。

7. 总结

写采集规则前先明确业务目标，将请求、定位、清洗三块分开设计；定位方式按场景选择，优先结构稳定的接口数据；翻页场景多利用动态请求分析；同时预留好配置项，便于应对后续的页面调整。从一个小页面练手开始，逐步完善规则细节，你会形成一套适合自己的稳定打法。

图1 图2
nginx