采集规则编写要点：定位方式选择与常见错误回避
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /403dd538000f.html
📄
编写采集规则的核心，在于用最稳妥的方式从目标页面中取出准确的数据，同时尽量降低后续维护的成本。规则写得好不好，直接关系到抓取效率和数据质量，也影响着账号是否容易被网站识别并限制。掌握几种主流定位方法的适用场景，避开那些反复出现的坑，就能让采集工作顺畅不少。
1. 套采集规则的完整构成
无论用哪种采集工具或框架，一套能正常流转的规则基本都包含三个环节：任务的起点、数据的提取、输出的整理。起点决定从哪个页面开始爬取，提取环节负责在页面代码中定位目标内容，而整理环节则让最终拿到的数据干净、可用。
动手编写前，先明确自己的数据需求：是只要列表页里的标题和链接，还是要进入每个详情页抓更完整的字段？这两种需求的规则逻辑差异很大，前者通常一条规则就能搞定，后者则要设计翻页和详情页跳转，复杂度明显上升。对新手来说，不妨先用带可视化操作的采集软件，看它根据你的点击生成了什么样的代码，这样能较快建立对XPath和CSS选择器的直观认识。
- 起点设置：可以是一个网址、一个包含多个网址的列表文件，或者站点的地图文件。
- 字段提取：根据页面结构选用CSS选择器、XPath或正则表达式来锁定目标。
- 结果整理：涵盖去空格、统一日期格式、去重、处理缺失字段等收尾工作。
2. 四种字段定位方法如何选
定位方式的选择没有绝对的对错，关键在于匹配页面特征和你对稳定性的要求。下面四种方法各有明确的适用范围。
XPath适合层级复杂、嵌套较深的页面。比如要从文章详情页里抓某个特定区块内的所有段落，用//div[@class='content']//p这种写法可以直接命中。但它的表达式通常冗长，网站只要微调结构，规则就可能失效，所以使用时要尽量写相对路径，减少对绝对层级位置的依赖。
CSS选择器胜在简洁，像.product-title这样的类名写法一眼就能看懂。它处理新闻列表这类层级较浅的页面效率很高。不过，当页面上同名类频繁出现时，就得多用子元素选择器或者兄弟选择器来缩小范围，否则很容易抓到多个结果。
正则表达式最适合从大段文字中抠出特定格式的内容，比如从一段描述里找出一个手机号或订单编号。它的匹配能力很强，但可读性差，后期维护成本高。建议只在其他方法都搞不定的时候再用，比如解析某些非标准格式的接口返回值。
JSONpath是专门对付接口数据的工具。很多网站的列表和详情内容都是通过Ajax异步加载的，此时打开开发者工具的Network面板找到数据请求，用JSONpath从JSON返回体中取值，往往比解析HTML页面稳定得多，因为接口的数据结构很少随页面改版而变动。
3. 编写过程中必须避开的几个陷阱
规则写多了就会发现，很多失败并非因为定位方法不会用，而是栽在一些不起眼的小细节上。下面这些坑几乎每个做过采集的人都遇到过。
盲目信任页面结构。不少网站的页面代码由模板生成，同一个类名可能出现在页头、侧栏等无关区域。如果直接按类名抓取，很可能把广告位或推荐位的数据也收进来。对策是先抓取后再人工核对几条数据，看看有没有混入杂质，必要时使用限定祖先节点的写法来收紧范围。
忽略动态加载的内容。当一个页面用滚动加载或点击展开更多时，直接抓取静态HTML只能拿到第一屏的数据。此时要切换到浏览器渲染模式，或者直接根据网络请求去分析接口，再决定是翻页还是模拟请求来获取完整数据。
拿不准唯一性就硬写。如果某个字段在页面上出现多次，比如同一款商品既出现在分类列表也出现在推荐位，那么规则就需要结合他字段来做唯一性判断，或者干脆放弃这个页面的抓取，转而寻找更稳定的数据来源。
4. 提升规则稳定性和可维护性的建议
一条规则能稳定运行一个月不出问题，比短时间内抓取速度快更重要。提升稳定性的一些做法，其实成本很低，却能在后续省下大量排查时间。
一是定期验证规则。建议在采集工具里设置定时任务，每次跑完后自动报告抓取成功率和空字段数量。数据量突然下降往往意味着页面结构变了，早发现早处理。二是为每条规则做好注释，记录目标站点、抓取时间、输出字段含义等信息，这样隔几个月回来看还能快速上手。三是优先抓取接口数据而非HTML，哪怕接口解析逻辑稍复杂，它的长期稳定性通常更好。
另外要养成好的请求习惯：设置合理的抓取间隔，不同页面间加上随机延迟，避免同一时间密集请求。这不仅是技术问题，也关系到采集能否长期进行下去。最好不要把单条规则写成一次性脚本，而是设计成可配置的模块，不同站点复用同一套字段提取逻辑，只是传入不同的选择器参数，这样后期新增站点会快很多。
5. 常见问题
5.1 为什么我写的XPath在测试时有效，正式抓取时却抓不到数据？
多半是页面存在动态加载或者使用了字体反爬。测试时页面已经渲染完成，所以能看到目标元素；而正式抓取时直接请求HTML，目标内容还没加载出来。建议先查看一次完整抓取时的原始HTML，确认目标字段是否存在于源码中，如果不在，就改用接口方式抓取。
5.2 CSS选择器和XPath哪个更不容易被网站改版影响？
两者都会受影响，但程度不同。XPath对层级结构依赖更强，结构一变就容易失灵；CSS选择器如果用的是类名，通常比XPath稍稳定一些。最稳妥的办法是优先使用data属性或固定的id作为锚点，同时尽量简化选择器，不写多余的空格和条件。
5.3 采集过程中经常出现重复数据，怎么处理？
重复数据可能来自多个入口重复抓取同一页面，也可能来自列表页和详情页各自采集了相同字段。建议在结果处理环节加入按主键去重的逻辑，比如以商品ID或文章URL作为唯一标识，再配合定时采集任务，对已存在的数据跳过写入，只新增变化的部分。
6. 总结
编写采集规则并不难，难在写出一条能长期稳定运行的规则。抓住三个关键点就能少走弯路：明确数据需求和页面特性，再决定用哪种定位方法；写规则时对页面结构保持不确定心态，主动验证唯一性和完整性；最后养成维护习惯，定时检查抓取质量并做好注释。建议从一个小型列表页开始练习，把上面提到的坑逐一踩过并修正，再逐步扩展到更复杂的详情页和动态页面，你的规则编写能力会提升很快。
