采集规则实战：定位方式选对与避坑关键点

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

采集规则的好坏，直接决定了抓回来的数据是拿来就能用，还是需要花大量时间返工清洗。很多人刚开始写规则时，总觉得能抓到数据就行，结果换一个页面就失效，或者抓回大量无关内容。避开这些坑，关键在于把定位方式选对，并把细节处理到位。

1. 动手前先想清楚这三件事

写规则前别急着打开工具，先把任务拆解清楚。一套完整的采集流程，无非是入口怎么进、内容怎么找、结果怎么整理。入口决定从哪个网址开始抓，内容定位负责从页面里挑出你想要的字段，而清洗步骤则负责把格式统一，比如去空格、转换日期格式或者给缺失值补上默认内容。

判断任务复杂度有个简单标准：如果只抓列表页的标题和链接，规则可以很轻量，核心放在翻页逻辑上；如果要进详情页抓多字段信息，就得考虑不同页面字段叫法是否一致、会不会出现空值。比如商品页的价格、库存、颜色这些字段，不同商品可能名称不同，有的干脆不显示，规则里就要预埋兜底逻辑。

新手建议先用可视化抓取工具生成一条基础规则，再去看它自动生成的定位语句，这样理解起来比直接啃语法快得多。

2. 定位方式怎么选才省心

定位方式没有绝对的好坏，只有合不合适。核心判断依据是页面结构稳不稳定，以及你想要的字段是否容易被唯一识别。下面把这四种方式的适用场景和注意点分开讲。

2.1 XPath：复杂页面结构的首选

XPath擅长处理层级嵌套多的页面，比如抓取某个区块下的所有段落，一条 //div[contains(@class,"content")]//p 就能搞定。但它有两个明显短板：表达式越长越难维护，而且严重依赖元素层级顺序，页面稍微调个结构，规则就失效了。建议把XPath尽量写短，能用属性定位就别绕层级关系。

2.2 CSS选择器：简单页面的性价比之选

CSS选择器语法简洁，像 .price 这种写法一眼就能看懂，解析速度也快，适合结构扁平的列表页或博客页。但它的坑在于class重名问题，如果页面里多个元素用了同一个class，就必须通过父级元素或相邻选择器来限定范围，否则很容易误抓其他区域的数据。写完后最好在页面里搜索一下这个class出现了几次，做个快速验证。

2.3 正则表达式：兜底手段，别当主力

正则的优势是能从无结构的文本里提取特定格式内容，比如电话号码、邮箱或订单号。但它的可读性太差，错一个字符整条规则就废了。只有当CSS和XPath都处理不了，比如解析JSONP回调或者其他非标准文本时，才建议考虑用正则。

2.4 JSONpath：接口直出的最优解

现在不少页面数据是通过Ajax接口返回的，直接抓接口比解析HTML更稳定。JSONpath可以灵活提取嵌套的JSON字段，比如 $.data.list[0].title 就能拿到第一个商品标题。这种方式绕过了页面结构变化的影响，只要接口不变，规则就长期有效。

3. 写规则时最容易踩的五个坑

很多采集失败不是思路问题，而是细节没到位。下面这几点是实战中反复出现的高频问题，值得在写规则时逐条对照检查。

  1. 用了动态class：现在很多网站的class是编译生成的，比如 class="item-3f2a"，数字和字母会随版本变动，用这类class做定位，规则迟早失效。可以改用相对稳定的属性，如 data-id 或元素层级关系。
  2. 没处理懒加载：部分页面内容在滚动时才加载，直接抓只能拿到空数据。需要模拟滚动或用等待加载策略，确保内容渲染完成后再提取。
  3. 分页逻辑不完整：有些网站翻页不是简单的URL变化，而是按钮触发请求，写的翻页规则要能覆盖这种调用，否则只能抓到第一页。
  4. 编码格式没指定：页面编码可能是UTF-8、GBK或GB2312，源文件里没声明时容易乱码。采集前最好先确认页面头部信息，在请求时显式指定编码。
  5. 没有进行数据校验：规则写完后，要随机抽查10条以上的数据，确认每条记录的字段都对应正确。只检查一两条很难发现问题，尤其是遇到字段缺失或错位的情况。

4. 如何判断一条规则是否合格

规则写完后，建议按以下标准逐项验收。一是准确率，随机抽检样本，看看抓到的数据是否跟页面实际内容一致，有没有抓错邻近字段；二是稳定性，换几个不同关键词或翻到不同页码测试，观察规则是否依然有效；三是容错性，刻意模拟页面字段缺失的情况，确认兜底逻辑能正常工作，不会因为某条数据异常而中断整个任务。

另外还有一个容易被忽视的点：适度降低请求频率，给目标网站增加间隔时间。这样既能减少给对方服务器带来的压力，也能降低IP被限制的概率。采集速度不是越快越好，稳定持续才是长期目标。

5. 常见问题

5.1 页面结构改动后，规则失效了怎么办

先通过浏览器的开发者工具检查目标元素的属性是否变化，尤其是class和id是否更新。如果只是属性变化，修改定位表达式即可；如果是整体结构重构，建议重新生成基础规则，再结合原有逻辑做修补。平时写规则时多做注释，方便后续快速定位问题。

5.2 抓回来的数据里总是混进无关内容，是什么原因

多半是定位表达式写得太宽泛。比如用某个class名直接定位，但页面中同名的元素不止一处。解决方法是增加限定条件，比如结合父级元素的唯一标识，或者用相邻兄弟节点来缩小范围，确保只在目标区域内提取。

5.3 接口返回的数据和页面显示的内容不一致，以哪个为准

以接口返回的原始数据为准，因为页面上展示的可能经历过前端的二次处理，比如格式化、截断或加默认值。但要注意接口里可能有冗余字段，需要根据逻辑判断真正有用的字段，并在清洗阶段做去重处理。

6. 总结

写好采集规则并不难，核心在于定位方式选对、细节处理到位。动笔前先分析页面结构特点，选择最匹配的定位策略；写完后按准确率、稳定性和容错性逐项验收，并定期回查规则是否依然有效。建议先把一条列表页的采集规则跑通，再逐步扩展到详情页场景，每完成一次就保存一份规则记录，形成自己的踩坑清单，后续再遇到类似问题就能快速解决。

图1 图2
nginx