采集规则编写全指南：元素定位技巧与常见避坑要点

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

编写数据采集规则，直接决定抓取任务能否长期稳定地跑下去。一套经过深思熟虑的规则，不仅要能精准拿到目标字段，还要兼顾效率与账号安全。以下从规则的基本构成、定位方法选择，以及高频踩坑点三个角度，梳理一套实用的编写思路，帮你省去自己摸索的时间。

1. 套规则的基本构成与前期准备

不管用的是成熟采集器还是自写脚本，一套完整的采集规则基本都由三个环节串联而成：抓取入口、字段抽取和后处理清理。抓取入口负责定义从哪发起抓取，字段抽取负责在拿到页面后锁定具体目标，而后处理清理则是把得到的原始数据整理成统一、干净的格式。

在动手写规则前，先得想清楚抓的是列表页还是内容详情页。拿商品站点举例，列表页通常只需要提取每件商品的链接地址，再把翻页逻辑处理好；而详情页则会遇到价格、库存、参数等字段缺失或单位不统一的问题，规则会更复杂，需要留足容错空间。

如果是新手，建议先用可视化工具搭一个简单的采集任务，看看工具自动生成的定位表达式长什么样，这对理解XPath和正则的运作原理很有帮助。

2. 四种常用定位方式与适用场景

选择用哪种定位方式，往往是规则编写中最费心思的部分。这几种方案各有长处，也各有短板，得结合具体页面来判断。

XPath 对付层级深、结构复杂的页面最为拿手。比如想把文章正文里所有段落都抓出来，写一句 //div[@class='content']//p 就能一次搞定。代价是表达式往往很长，而且对层级依赖度高，页面结构稍一调整，规则就可能失效。

CSS选择器 语法简洁直接，像 .price 就能按类名提取。它在结构简单、层级平铺的页面上运行效率高，很可靠。不过当页面上同类名过多时，需要配合 ul li 这类后代选择器来限定范围。

正则表达式 适合从纯文本里抠出特定模式，比如从描述中抓出手机号或单号。优点是灵活，缺点是难读难维护，排查问题要花不少时间，建议只在CSS和XPath都搞不定时再用，例如解析接口返回的JSONP数据。

JSONpath 是解析API响应的首选。现在很多网站用Ajax异步加载数据，与其解析HTML，不如直接在浏览器开发者工具的Network面板里找到XHR请求，对返回的JSON用JSONpath提取，通常更稳妥也更高效。

这里有个重要的避坑原则：定位时尽量用相对路径，比如 //div[@class='item']，不要从根节点写死一长串绝对路径。绝对路径对结构调整非常敏感，页面随便多套一层div，整条规则就会瞬间作废。

3. 翻页与动态加载的应对办法

翻页是采集任务里最容易出状况的环节。常见的翻页方式无非几种：URL里有页码参数、需要点击下一页按钮、或者用下拉加载。

对于URL带页码的情况，处理起来最省心，直接循环拼接参数即可。比如 /list?page=1 到 /list?page=10。但要留意页码是0起始还是1起始，以及最大页数是多少，避免花大量请求去访问不存在的空页。

对于点击式翻页或下拉加载，往往要模拟浏览器行为，可以用开发者工具观察点击后发起的请求，找到真正的数据接口地址，然后直接请求接口，比真正去点按钮更快速也更稳定。如果只能靠点击，要注意控制点击间隔，避免被识别为高频异常而触发验证码。

遇到动态加载，关键是找到数据从哪来。在Network面板里过滤XHR请求，逐个查看返回内容，找到加载商品或列表的那个JSON请求，用JSONpath去提取，就能绕开复杂的页面渲染过程。需要注意的是，接口请求常常带有加密参数或时间戳，这时候往往还需要补上生成这些参数的逻辑，工作量会明显增加。

4. 常见踩坑点与应对建议

在实际编写过程中，有几个反复出现的坑，提前知道能省不少精力。

第一，结构频繁变化的页面。 有些网站会不定期改版，刚写完的规则可能过几天就失效。应对办法是给规则加一层校验逻辑，比如设定字段匹配的最少数量，低于预期就及时报警，而不是默默产出大量空数据。另外，定期检查页面结构，发现变化及时更新定位表达式。

第二，同类型元素的区分问题。 页面上往往有多个相似节点，比如价格和划线价都带price类名。这时要利用上级节点或属性来缩小范围，比如 parent 或 data-* 属性，避免抓错数据。

第三，请求频率与并发控制。 抓取太快容易被封IP，太慢又影响效率。建议设置随机延迟，比如每次请求间停顿2到5秒，并配置重试机制。遇到失败请求不要立刻重试，稍等片刻再尝试，能显著降低被风控盯上的概率。

第四，数据清洗不及时。 原始数据里经常会混入空白、换行符、HTML标签等杂质，如果不在提取阶段一并处理，后续清理会非常麻烦。建议在规则里就写好清晰的清洗步骤，比如用正则去掉多余的空白和标签属性，让输出数据开箱即用。

5. 常见问题

5.1 采集规则失效了应该怎么快速排查？

先打开浏览器开发者工具，对比当前页面结构与规则里的定位表达式是否一致。优先检查目标元素所在的div类名或id是否有变化；如果没变化，再核对是不是翻页参数或接口地址变动。建议给规则加日志输出，记录每次请求和提取结果，方便定位失效的具体环节。

5.2 XPath和CSS选择器到底选哪个？

没有绝对答案，主要看页面复杂度。如果目标元素嵌套层级不深，用CSS选择器更简洁、执行更快；如果页面层级深、想要按文本内容或者属性同时匹配，XPath更灵活。经验是：能简单就别复杂，CSS能解决的就不必上XPath。

5.3 遇到需要登录才能访问的页面怎么处理？

先确认登录后有没有独立的接口返回数据，很多站点的数据接口并不需要完整登录态，只校验一个Cookie或Token，这种情况只需要从浏览器里复制请求头即可。如果必须完整登录，可以考虑保存登录后的Cookie再模拟请求，但要注意账号安全，不建议用主账号去做频繁抓取。

6. 结语

编写一套稳定耐用的采集规则，核心在于对页面结构的理解、对定位方法的合理选择，以及对常见陷阱的提前预防。建议从一个小型的列表页任务练手，逐步上手XPath和JSONpath，在规则中加入校验与容错逻辑，再配合合理的请求间隔，就能让数据抓取任务长期平稳运行。最重要的是勤于观察页面变化，及时维护规则，才不会被突然的改版打乱阵脚。

图1 图2
nginx