采集规则编写实操教程：定位方式选型与避坑要点

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

写采集规则，本质是替程序回答三个问题：从哪里拿、怎么定位、拿完怎么整理。这三个问题答得越清楚，抓取流程就越稳，被对方网站拦截的概率也越低。下面直接从框架搭建讲到高频坑点，帮你把规则写得既快又耐用。

1. 采集规则的三大构成模块

不管用现成软件还是自己写代码，规则都绕不开三个部分：启动入口、字段定位和结果清洗。启动入口决定请求从哪里发出，字段定位决定从响应内容里取哪一段，结果清洗则负责把取到的数据变成统一、干净的格式。

开写之前，先想清楚目标页面是列表型还是详情型。比如做电商比价，列表页只需要拿商品短标题和详情页链接，规则很简单；但进入详情页后，价格、规格、库存、评价数这些字段可能缺失或格式不一，规则立刻复杂起来。先分清层级，再动手写，能省下大量调试时间。

• 启动入口：支持单个链接，也可以直接喂入URL清单或站点地图。
• 字段定位：常见手段是XPath、CSS选择器、正则表达式，偶尔用JSONPath。
• 结果清洗：包括去首尾空格、统一日期格式、去重、空值补默认值等。

新手可以在可视化采集工具里先拖一个简单流程，重点看它自动生成的XPath或选择器长什么样，读懂了再手写，上手会顺很多。

2. 四种定位方式选型与避坑

选定位方式是整个规则里最影响成败的环节，四种主流方式各有分工，别混着用。

2.1 XPath适用复杂结构

XPath擅长处理层级深的嵌套结构，比如 //div[contains(@class,'article')]//p 能直接抓到区块内所有段落。缺点是表达式一旦写长，维护成本高，且对页面层级变化敏感，改版后容易整体失效。

2.2 CSS选择器主打轻快

CSS选择器语法紧凑，像 .product-price 一行就够，性能通常优于XPath，适合结构扁平的列表页。但遇到同名类泛滥的情况，得靠子选择器或 :nth-child 来缩小范围，否则会抓回一堆无关元素。

2.3 正则表达式兜底用

正则适合从纯文本里挖固定模式，比如从描述中提取订单号或手机号。它灵活但易错，表达式稍长就难以阅读和调试，建议只在前两种方式搞不定时再用，比如处理JSONP回调内容。

2.4 JSONPath应对接口直取

很多现代网站的数据由Ajax异步加载，页面源码里根本看不到。此时打开浏览器开发者工具，找到XHR请求，直接用JSONPath从响应里取值，比揪着HTML分析稳定得多。

避坑要点：尽量用相对路径（比如 //div[@class='item']），别写死从根节点出发的绝对路径。页面结构只要多包一层div，绝对路径就全线崩溃，相对路径还能存活。

3. 翻页与动态加载的应对方案

翻页规则写不好，抓取量就上不去。常见的翻页有三种形态：URL带页码参数、点击“下一页”按钮触发请求、无限滚动靠滚动事件加载。

1. URL带页码：直接循环替换页码参数，最简单可靠，但要注意有些网站页码从0开始或步长为2。
2. 点击翻页：先抓取“下一页”按钮的链接，再跟踪该链接，直到按钮消失为止。
3. 无限滚动：需要模拟滚动操作或直接拦截Ajax请求，优先用后者，直接拿JSON数据。

动态加载页面的通用建议是：先看看能不能直接请求背后的API接口，能的话就别渲染浏览器，速度能快好几倍。另外，翻页循环里务必加随机延时，比如每次停留2到5秒，别固定一个数字，否则触发频率检测是迟早的事。

4. 高频踩坑点与处理方式

即使规则写对了，运行中也常会遇到以下问题，提前做好预案能省不少事。

• 页面结构微调：网站的CSS类名或层级偶尔变化，规则就抽不到数据。建议给关键字段写宽松一点的匹配规则，再配合结果校验，一旦抽空立即发告警。
• 数据重复抓取：翻页或并发时容易重复入库。在清洗阶段按业务主键去重，比如商品ID或订单号，别用标题去重，标题可能带空格差异。
• 编码乱码：部分老站点返回GBK编码。在请求入口处显式指定字符集，或者拿到响应后先检测再解码，别硬当UTF-8处理。
• 请求被限流：抓太快容易被封IP。建议限制并发连接数，配合使用代理池，并对返回的异常状态码做区分处理，比如403就换代理重试，404则直接跳过。

5. 规则维护的良性习惯

采集规则不是写完就完事，它需要持续维护。给每个规则加上备注，写明目标站点、字段含义、最后验证时间。定期跑一次自检脚本，把抓取结果数量和预期数量做对比，偏差超过阈值就触发人工检查。

另外，规则文件建议按模块拆分，别把入口、定位、清洗全塞在一段代码里。这样单个模块出问题，改起来不用翻几百行找位置，测试回归也快很多。

6. 常见问题

6.1 问1：XPath和CSS选择器到底该先学哪个？

建议先学CSS选择器，语法更短、调试更快，适合日常80%的简单场景。等遇到结构复杂的页面，再补XPath的轴和函数知识，够用就行，没必要一次学全。

6.2 问2：采集时页面加载很慢，怎么判断是规则问题还是网络问题？

先单独测试单个URL的响应时间，如果单个请求本身就慢，那就是目标服务器或网络的问题，跟规则无关。如果单请求秒回但批量并发时变慢，通常是你请求太快触发了对方的限流策略，试着降低并发数或加延时。

6.3 问3：网站改版后规则全部失效，有没有快速恢复的办法？

先打开改版后的页面源码，对比旧版的变化点。多数改版只动了CSS类名，层级没大变，此时用文本替换的方式批量更新旧类名即可。如果层级也换了，只能重新定位，但字段清洗逻辑通常可以保留，不用推倒重来。

7. 总结

把规则拆成入口、定位、清洗三个模块分别维护，优先用相对路径和API接口来降低失效风险，翻页加上随机延时，清洗阶段做好去重和编码处理，最后保留字段注释和定期的结果校验机制。按这套思路搭出来的规则，稳定性和可维护性都会明显上一个台阶。建议从单一列表页的小项目练起，跑通后逐步叠加翻页和详情页，经验积累比背理论重要得多。