采集规则编写进阶：定位方式选择与高频问题规避指南
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /df19f56829e9.html
📄
编写网络数据采集规则时，最核心的诉求无非是两点：数据能稳定抓到，且页面调整后规则不至于立刻失效。很多初学者把精力全放在正则表达式上，结果页面结构一变就束手无策。实际上，一套成熟的采集规则，从入口配置到字段提取再到结果清洗，每一步都有讲究，而定位方式的选择更是决定了整个规则的寿命。
1. 套完整采集规则的基本架构
在动手写规则之前，先要清楚一套规则由哪些部分组成。多数采集框架都会涉及以下三个模块，它们彼此独立，却又环环相扣。
- 请求入口：决定首轮请求发往哪个地址，可以是单个URL，也可以是一批待抓取的种子链接。
- 字段提取逻辑：从返回的响应内容中精准锁定目标数据，常用的技术手段有XPath、CSS选择器、正则表达式以及用于接口数据的JSONPath。
- 数据后处理：对提取到的原始内容做二次加工，例如修剪空白字符、统一时间戳格式、剔除重复项、为缺失字段填补默认值。
开始编写前，最好先判断任务是“列表页抓取”还是“详情页抓取”。列表页的目标通常很少，只需要链接和摘要，规则轻量简单；详情页则要面对多个字段并存、部分字段缺省的情况，对容错能力的要求会高出一个量级。举个例子，抓取电商平台搜索结果的列表页，只需提取商品名称和详情链接；而进入详情页后，不同商品可能有的有促销价、有的没有，有的带规格参数、有的只有文字描述，规则就需要针对这些差异做兜底处理。
2. 如何挑选合适的元素定位方式
定位方式的选择没有绝对的对错，只有合不合适。不同方案在表达能力、执行效率和抗页面变化的能力上各有优劣，需要结合具体页面结构来判断。
2.1 XPath：应对深层级嵌套结构
当页面DOM层级很深，或者目标元素被多层容器包裹时，XPath几乎是无二之选。例如要提取某区块内的所有段落，一句 //div[contains(@class, 'article-body')]//p 就能覆盖多个层级。但XPath表达式一旦写得过长，调试起来会非常头疼，而且对层级变动极为敏感——开发者哪怕只在外层加了一个div，整条规则就可能瞬间失效。
2.2 CSS选择器：处理规整页面的轻量方案
如果页面class命名规范且结构扁平，CSS选择器的高效率就体现出来了。像是 .product-title 这种写法，简洁直观，执行速度也快。不过遇到大量复用相同class的情况，就得靠子元素或属性修饰来做限定，例如 .list li:nth-child(2) span，只取列表里第二个子项的span内容。
2.3 正则表达式：无结构文本的最后手段
当目标数据隐藏在一大段没有标签结构的文本里，比如日志文件或客服聊天记录，正则就成了唯一可行的办法。它的强大之处在于灵活，但代价是表达式复杂难懂，边界条件稍有不慎就会产生误匹配。一个建议是：只要能靠XPath或CSS解决的问题，就不要优先动用正则。
2.4 JSONPath：动态加载页面的最佳突破口
如今绝大多数页面内容都由接口异步返回，直接在浏览器开发者工具里找到真实的XHR请求，再解析JSON响应，往往远比分析渲染后的HTML要稳定。JSONPath的语法和XPath有些类似，但更适合键值对结构，可以直接用 $.data.list[0].title 这种路径式写法直达目标字段。
还有一条值得记住的实操原则：尽量用相对路径而非绝对路径。绝对路径从根节点层层下探，页面只要多包一层就全盘崩溃；相对路径只关注目标元素的相对位置，抗页面微调的能力明显更强。
3. 分页参数构造与动态加载内容的应对
分页操作看似简单，实际上藏着不少坑。多数网站会把页码编在URL查询参数里，比如 ?page=2，这种情况下只需要在循环中递增参数值即可。但有些站点使用POST请求或JavaScript动态拼接参数，此时就得分析请求负载，复制同样的参数结构，别抱着URL不放。
此外，还有一种常见情况是“下拉加载更多”，这类交互通常通过无限滚动触发新的接口请求。处理这类页面时，建议直接找出发出请求的接口，构造分页参数循环请求，而不是模拟滚动操作——后者不仅效率低，还容易触发反爬机制。判断标准很简单：如果在网络面板里能看到清晰的JSON响应，就优先走接口解析路线。
4. 反爬机制与页面改版下的规则加固
规则写好了只是第一步，能扛住运行环境变化才是关键。页面改版和反爬升级是常态，在设计规则时就该为这些情况预留余地。
- 设置超时与重试：对每个请求设置合理的超时时间，并对失败的请求做有限次重试，避免单次网络抖动导致整个任务中断。
- 使用相对宽松的定位条件：避免依赖过于精确的层级路径，多用 contains() 或属性匹配来定位，减少因细微结构调整导致的失效。
- 模拟真实请求头：补全User-Agent、Referer等基础头信息，必要时加入Cookie保持会话，降低被服务器直接拒绝的概率。
- 控制请求频率：在连续请求之间加入随机间隔，切忌固定间隔地匀速抓取，那是最容易被识别的行为特征。
以某资讯网站改版为例，页面从传统的分页导航改成了无限滚动加载。原本基于URL页码的规则立即失效，但通过抓包发现新接口返回的是JSON格式数据，改用JSONPath提取后，规则不仅恢复了，还比以前更快。这个案例说明，定位方式的选择不仅要看当前结构，还要考虑页面可能的发展方向。
5. 常见问题
5.1 为什么我的XPath在浏览器里能定位到元素，但在采集工具里却取不到数据？
这通常是因为浏览器里定位的是渲染后的DOM，而采集工具读取的是服务器返回的原始HTML源码。很多内容由JavaScript动态渲染生成，在源码中根本不存在。解决办法是切换到JSONPath或直接解析XHR接口数据，或者使用支持JavaScript渲染的采集方式。
5.2 页面结构频繁变化，有什么长期有效的应对策略？
没有一劳永逸的策略，但可以显著降低维护频率。核心思路是：尽量用数据特征而非结构特征来定位，比如用稳定的属性值或文本内容来锁定目标，而不是依赖层层嵌套的路径。同时可以给重要字段配置多个备用选择器，主选择器失效时自动切换备用方案。
5.3 采集时总是触发验证码或IP被封禁，该如何处理？
首先排查请求头是否完整，是否缺少浏览器指纹信息。其次检查请求频率是否过快，建议改为随机间隔并加上延迟。如果仍被封，可以尝试使用代理IP池轮换出口地址，但要注意代理质量参差不齐，效率未必理想。最根本的原则是：尊重目标网站的robots规则和服务条款，控制采集强度，优先通过正规API获取数据。
6. 总结
编写稳定的采集规则，核心在于做对三个选择：任务类型判断清楚（列表页还是详情页）、定位方式选对（XPath、CSS、正则还是JSONPath）、对动态内容和反爬机制有预案。具体操作上，从相对路径开始写，优先解析接口JSON，给请求加超时和随机延迟，并为关键字段准备备用选择器。不要指望一套规则永远不过期，但通过合理的设计，可以把维护频率降到最低。
