编写一个爬虫的思路，当遇到反爬时如何处理

写了这么多年爬虫了，经常还是会撞上反爬机制。虽然大多数时候都能解决，但是毕竟反爬机制多种多样，有时候遇到一个许久不见的反爬机制，也会感到手生，一时想不上来应对方法，而浪费不少时间。最近写了不少爬虫，接下来一段时间又不写了，趁着手还比较熟，记录一下备忘，方便大家也方便自己。

之前写过一篇常用的反爬虫封禁手段概览, 但是主要是从反爬的角度来的，这篇主要从写爬虫的角度来说说。

开章明义，当遇到反爬机制时，想要做到把数据爬下来，无非四个方法：

1. 加代理
2. 降速度
3. 破解接口
4. 多注册几个账户

好多文章为了显示自己高大上，吹些什么高并发呀，分布式，机器学习破解验证码的幺蛾子，都是扯淡。与其扯这些东西，不如老老实实把数据爬下来才是王道，如果非要扯上一些 fancy 的东西，那把监控做好比啥都重要。

补充说明一下，本文探讨的是数据收集型的小型爬虫，也就是你要对少数站点在较短时间内收集大量信息。而非搜索引擎型全网爬虫，即对大量站点在较长时间内收集综合信息。（全网当然要上高并发了）

为什么说爬虫不要扯高并发？

我们知道计算机程序按瓶颈不同大概分为两类，CPU 密集型和 IO 密集型。CPU 密集型就是偏重计算的任务，比如说编解码啥的；IO 密集型就是偏重于网络的任务，比如说下载或者 web 服务器。那么爬虫是哪种呢？你估计要回答 IO 密集型，恭喜你答对了。但是这不是我想说的重点，重点是爬虫不光是 IO 密集型的任务，实际上我想把它称作 IP 密集型任务。

什么是 IP 密集型任务呢？按照上面的定义我们知道，也就是说，对爬虫来说，**最瓶颈的地方其实是你持有的 IP 的数量！**作为一个合格的爬虫编写者，你肯定已经擅长伪造各种 HTTP headers, 破解 JS 的加密参数，但是唯独一个 -- 来源 IP -- 你是无法伪造的。好多看起来很难搞的事情，如果对方站点的小霸王服务器撑得住，只要加上足够的 IP 就很简单啦，不用绞尽脑汁去想各种策略了。

为什么不要用现成的框架？

上面说了，所谓的"高并发"对爬虫没有任何卵用，那么像是 Scrapy 这种采用了协程以便提高并发的框架我就不是很懂了。以前我专门写过一篇为什么不要用 Scrapy 的文章，所以这里就不再展开细说了。

另外如果你爬虫写多了肯定有自己的一套东西了，这时候你可能会有自己的一个小框架，这是可以的。但是我还是想提两点：

1. 千万不要做成从模板生成新的爬虫项目的功能。假如你改了模板里的一个 bug 怎么办？以前生成的爬虫还挨个修改吗？
2. 框架尽量简单，把可以复用的功能提取成单独的 utility 函数或者库。难免有需要改框架或者不适用框架的时候，这时候依然可以复用单独的模块。

拿到