爬虫抓mobi电子书，爬虫这事儿比想象中麻烦。爬虫你以为找到个下载链接，爬虫requests.get一把梭就完事了？爬虫太天真。mobi文件通常藏在多层跳转后面，爬虫还带着各种token验证，爬虫直接怼URL多半给你返回个404或者一堆乱码HTML。爬虫

我上周试着抓某个古籍站的爬虫mobi资源。表面上看，爬虫网页结构挺干净，爬虫每个书页都有个“下载mobi”按钮。爬虫用开发者工具瞅了一眼，爬虫按钮确实指向一个直链。爬虫结果代码跑起来，爬虫下载下来的爬虫文件只有2KB。打开一看，里面写着“请使用微信扫码关注公众号获取提取码”。好家伙，玩阴的。

后来翻页面源码才发现，真正的下载地址藏在某个js变量里，而且是动态拼接的。前一半在页面里，后一半得靠ajax请求另一个接口才能拿到。这还不算完，接口那边还校验了请求头里的Referer和User-Agent，缺一个就给你返回空数据。

对付这种货色，得用selenium或者playwright模拟真人操作。但别急着上无头浏览器——那玩意儿重，启动慢，还容易被反爬识别。我一般先用requests把整个页面源码拉下来，正则或者BeautifulSoup找出所有script标签，看看有没有线索。实在不行再上playwright，但记得把webdriver标记去掉，不然人家一眼看穿你是机器人。

真正恶心的场景是文件分片。有些站点把mobi拆成几十个加密块，前端用js慢慢拼。这时候爬虫就得逆向他那个解密函数。我碰到过一次，那个函数是用obfuscator混淆过的，变量名全是_a、_b这种。硬着头皮在console里一步步调试，花了三个小时才搞明白它是用CRC32校验每个分片的完整性。最后写了个python版本的解密逻辑，总算能下载完整文件。

还有编码问题。mobi文件本身是二进制，但有些站点会在下载前做一次base64编码，塞进json里返回。你得先解析json，再base64解码，最后才能拿到真正的文件流。要是忘了处理这一步，写出来的文件铁定打不开——你会在kindle里看到满屏乱码。

再说说反爬策略。有些图书馆的站点对单个IP有下载频率限制，比如一分钟最多5次。你爬个两百本的书，得跑四十分钟。这时候就得上代理池，但免费的代理质量堪忧，经常连不上。我试过用celery做分布式爬虫，把任务分给十几台服务器跑，效率是上来了，但维护成本也高。后来学乖了，直接在代码里加个随机sleep，配合重试机制，慢是慢点，省心。

最坑的一次是某个站点用了Cloudflare的人机验证。不管你怎么伪装请求头，它都给你弹个challenge页面。最后只能上undetected-chromedriver，这玩意儿确实能过，但每次启动都要下载新的chromedriver，烦得很。

说到底，爬mobi这事儿，技术难点不在爬，而在解析。你得懂点前端，会看js，还得有点逆向思维。纯粹靠requests加BeautifulSoup硬刚，八成会碰壁。工具链倒是无所谓——python、node、甚至go都行，关键是思路。我见过有人用excel的power query干这活的，虽然慢，但也够用。

最后提醒一句，下载的mobi文件最好验证一下完整性。用python的mobi包解析一下，看看页数对不对，目录有没有乱。有些文件表面看着正常，实际缺了封面图或者目录跳转失效。这玩意儿在kindle上看不出来，导到calibre里才现原形。别问我怎么知道的，说多了都是泪。