采集规则编写进阶：定位方式选择与常见问题规避
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2f9de0ec3db0.html
📄
编写网络采集规则时，最让人头疼的不是拿不到数据，而是规则刚跑两天就失效。页面结构微调、反爬机制升级、字段格式不统一，任何一个环节出问题，都会让整个采集任务停摆。要写出稳定可用的规则，关键不在于掌握多少花哨语法，而在于搞清楚不同定位方式的适用场景，以及提前避开那些反复踩过的坑。
1. 套采集规则由哪几部分组成
任何一套能正常运转的采集规则，都离不开三个基本模块的协作。把这三块理清楚了，后续写规则时思路会清晰很多。
- 入口地址：决定第一步从哪里发起请求。可以是单条URL，也可以是一个包含多条地址的待抓取列表，通常还附带请求头、Cookie或登录态信息。
- 字段提取逻辑：负责从返回内容中锁定目标数据。常用工具有XPath、CSS选择器、正则表达式，以及针对接口返回的JSONPath。
- 结果清洗环节：对提取出来的原始值做后处理，比如去掉两端多余空格、把日期统一成固定格式、剔除重复记录、给空字段补默认值。
动手之前，先判断任务属于列表页还是详情页。列表页往往只需要抓取标题和跳转链接，逻辑简单；详情页则要面对多个字段并存、部分字段缺失的情况，对容错处理要求更高。拿招聘网站举例，列表页只要职位名称和详情页URL，而详情页要处理薪资区间、学历要求、经验年限等字段在不同公司间的表达差异。
2. 如何选择适合的字段定位方式
定位方式的选择直接决定规则的寿命。没有哪个方法绝对优秀，关键看页面结构和你对稳定性的要求。
2.1 XPath：复杂结构下的通用解法
当页面嵌套层级较深，比如要提取某个区域内的所有段落，用XPath写一句 //div[contains(@class,'content')]//p 就能搞定。它的表达能力在四种方式里最强，但长表达式写起来繁琐，而且对层级变化非常敏感，页面改版稍大，整条规则可能就报废了。
2.2 CSS选择器：规整页面的轻量选择
如果页面class命名规范，一句 .item-title 就能取到核心数据，代码短、执行也快。但遇到多个元素共用同一个class时，就得靠追加子元素或顺序修饰来缩小范围，比如写成 .list li:nth-child(2) span 来定位第二个子项。
2.3 正则表达式：最后的兜底手段
当数据混杂在没有结构的文本里，比如从一段对话记录中抽取订单号，正则就成了唯一选择。但它极难调试，边界条件考虑不周就会误匹配。能用地定位方式解决的问题，尽量不要优先上正则。
2.4 JSONPath：应对异步加载页面的利器
现在很多页面内容由接口异步返回，与其去啃渲染后的HTML，不如打开开发者工具，找到真实的网络请求，直接解析JSON响应。JSONPath语法贴近键值结构，写起来直观，而且接口一旦稳定，比解析HTML更抗改动。
一个需要牢记的原则：尽量用相对路径定位。绝对路径从根节点一路下探，页面多包一层容器就全盘失效；相对路径只关心目标元素与附近节点的相对关系，抗变化能力强得多。
3. 分页参数与动态内容的应对思路
分页看似简单，实际藏着不少细节问题。翻页参数通常以查询参数的形式出现在URL里，这是一种常见且易处理的模式。但有些网站采用JavaScript异步翻页，URL不变，数据靠接口返回，这时需要从XHR请求中找出真实的翻页参数。还有一部分站点使用偏移量或游标翻页，参数是加密的或经过编码，需要先弄清楚参数生成规则，才能保证后续请求能取到数据。
无论采用哪种方式，都要注意给每次请求留出合理的间隔时间，避免短时间高频请求触发流量限制。一旦发现返回内容与预期不符，先检查请求是否被重定向或返回了验证码页面，再排查参数是否有误。
4. 高频踩坑点与对应的解决办法
规则写好只是第一步，真正磨人的是运行时暴露的各种问题。以下是实操中最常见的情况。
- 页面结构变动导致规则失效：解决思路是给关键字段设置多个备用定位表达式，比如优先级从高到低，依次尝试；同时定期巡检，发现取不到数据时及时切换备选方案。
- 反爬机制拦截请求：遇到403或频繁要求验证时，先检查请求头是否完整（User-Agent、Referer），必要时补充Cookie或登录态，并合理控制请求频率。
- 字段内容格式混乱：比如日期一种页面是“2024-03-15”，另一种是“2024/3/15”。统一在清洗环节处理，用固定表达式做标准化，而不是等到入库后再补救。
- 接口返回字段变动：约定字段在特定条件下会缺失或变为null，为JSONPath配置默认值，保证后续流程不因空值中断。
另外，调试时尽量用单个样本页面反复测试，确认所有分支情况都覆盖后再批量跑。上线后做好日志记录，一旦数据量异常，能快速定位是哪一层出的问题。
5. 常见问题
5.1 规则刚开始跑正常，过几天突然抓不到数据了怎么办
先检查返回状态码，确认是不是被反爬策略拦了，比如出现403或频繁跳转验证码页。再看页面结构是否改版，可手动打开目标页面，用浏览器开发者工具检查目标元素是否还在原来的位置。如果结构确实变了，需要更新定位表达式；如果是反爬问题，调整请求头或增加间隔时间后再试。
5.2 同一个class被大量复用，选择器总是选错元素怎么办
不要只依赖class，可以往上找父级容器，通过包含关系缩小范围，比如 .list-item > .title 比单独的 .title 更精确。如果页面结构有规律，也可以结合位置关系，比如用 nth-child 或相邻兄弟选择器。必要时改用XPath，利用文本内容或属性组合来定位目标元素。
5.3 用XPath写的表达式太长，页面一改就失效，有没有更好的写法
尽量缩短依赖路径的长度，不要从根节点一层层写到底，多用相对路径。可以把提取目标放到离数据最近的父容器上，然后配合子元素去取。另外，为关键字段准备一套备用的CSS或正则方案，当主方案失效时自动切换，减少人工介入的频率。
6. 结语
稳定的采集规则不是一蹴而就的，它需要前期对页面结构的细致分析，也需要在运行过程中持续维护。建议先从小规模样本页开始调试，确认所有字段和边界条件都覆盖到位再上量。定位方式优先选择相对路径，动态内容优先考虑解析接口，同时为关键字段保留备用方案。这样即使页面调整或接口变动，规则也能有足够的缓冲空间，不至于立刻瘫痪。
