当我们说到爬虫时我们在说什么呢（下）

接上文，我们来看下最麻烦的反爬对策

为什么说反爬对策是最麻烦的呢（注意这里的最麻烦不是技术上最困难）？原因有下

1. 没有明确的目标，你很难确定做对了什么或者做错了什么
2. 会引入一些外部资源，而这些资源会大幅提高爬取成本
3. 会显著降低爬取效率，而且随时可能会被封死
4. 心很累，一旦封死继续去抓包、调试吧

反爬是加剧爬虫工作者脱发的主因，它对技术的要求可能不高，但是很乏味、很枯燥、很繁琐，可能会出现大量的定制规则和无尽的逆向轮回（🐶

无目标

不仅无目标还无组织、无纪律、目中无人

这个阶段（还不用外部资源时）你

可能换一个http请求框架、更新一下header、修改一下cookie、添加一些随机值就又行了

也可能你需要深入了解一下对方的各种看起来很长的值是如何生成的

也可能你要去深入一下对方的心理（😂

外部资源

花钱的地方来喽，这里包括但不限于

1. IP池，你可能每个月要花数千到数万（相信我，短效IP每月超过5万你就可以报警了，长效IP通常也不会超过这个数）
2. 帐号池，比如去买点帐号了，或者找专门的cookie池（看帐号的损耗速度，通常不会太多）
3. 模拟登陆，如果不是专门的cookie池，需要去模拟h5等落或者app登录（算在开发成本里）
4. 接口，比如逆向不出来，去买买买（看调用频次）
5. 监控，对外部资源的监控，方便去排查问题，不必须但有必要（算在开发成本里）

外部资源是限制爬虫规模的主因，尤其是IP池和帐号池，这里有几点需要注意

1. IP池的质量参差不齐，而且随时可能跑路，慎重
2. 如果依赖IP池（好像也不可能不依赖）那么注意IP的质量监控，如果大量超时且客服处理不及时，尽早更换
3. 最好选择能在自己服务器上池化的厂商。如果财大气粗请无视
4. 帐号登录不是万能的，是最后的解决方案，请尽量去逆向出来更多不用登陆的资源
5. 帐号失效一定要及时处理，做好监控，否则就做好重试，及时终止

速度变慢

你可能会怀疑自己的请求是不是没有完全模拟用户行为？别傻了大规模爬虫怎么可能完全模拟用户行为

模拟用户行为、策略和流量特征确实可以少触发反爬，但是为此你要添加很多特定的、繁琐的代码来实现；而且会大大拖累爬取速度。但效果也只能说差强人意，只能说有总比没有强

1. 代理超时和大量结果失败是限制爬取规模和速度的主因
2. 小规模时尽量完全模拟用户行为
3. 大规模时关注下IP池和特定对策哪个更优，上了代码层面的对策后效果如果
4. 任何情况下都应该尽可能模拟流量特征，但要寻找联系而不是照抄
5. 模拟流量特征时可以叫上逆向的哥们

彻底完蛋

从我的经验来说一旦一个接口进入风控视野，离完蛋就不远了，不存在补救措施。通常

1. 在对方系统里确定无用的接口会被直接下掉或者返回错误结果
2. 在对方系统里在用的接口会加上非常严的风控策略，严格限制调用频次，甚至严到正常用户调用也会有滑动条之类的

这个时候就不用死磕了，放弃这个接口去寻找替代接口吧

如果找不到替代接口，或者发现准备好的替代接口也被一锅端时，微笑吧你就剩下这个了

身体发肤，受之父母。请善待自己的头发，及早躺平

法律风险

大家一定要明白这里是有法律风险的，非商业用途除非作死绝对没人管，商业用途好自为之

商业用途的大规模爬虫从头到位都是黑的，请慎重莫要追悔莫及