WebCrawler搜索入口

1994年，华盛顿大学的入口一个实验室里，Brian Pinkerton写了个小脚本，搜索叫WebCrawler。入口它做的搜索事很简单：顺着超链接爬，把网页文本存下来，入口然后让人在框里敲关键词去搜。搜索那是入口第一个对公众开放的全文搜索引擎。今天你打开Google、搜索Bing、入口或者百度，搜索那个输入框的入口祖先就是它。

但“搜索入口”这四个字，搜索放在爬虫的入口语境里，意思经常被搞混。搜索有人以为说的是爬虫程序从哪个URL开始爬——种子URL嘛，教科书上都这么讲。有人以为说的是搜索引擎首页那个搜索框。还有人觉得是API接口，你调一下，返回一堆JSON。这三种理解都对，但指向完全不同的东西。

我最早接触爬虫的时候，卡在一个很具体的问题上：requests.get()写好了，解析规则也写好了，但第一个请求该打到哪里？当时想爬一个电商网站的商品列表，首页是动态加载的，直接请求www.example.com只拿到一个空壳。后来在Chrome的Network面板里翻，发现真正返回数据的接口藏在/api/v2/items?page=1这样的路径下。这个API地址，就是那个项目的“搜索入口”。

所以入口不一定是给人看的页面。它可能是XHR请求的端点，可能是移动端App调用的私有接口，也可能是站点地图里列出的XML文件。robots.txt里写的Sitemap: https://example.com/sitemap.xml，这行字经常被忽略，但它其实是网站主动告诉爬虫“从这里开始”的邀请函。可惜很多人不看，上来就暴力遍历，结果被封IP。

另一个容易踩的坑：入口不等于入口页。你从/list?page=1进去，翻到第二页变成/list?page=2，第三页是/list?page=3……这种分页参数看起来有规律，但有些站点会在中间插入随机token，或者用POST请求带上一堆你看不懂的header。这时候入口就变成了一个“会话”——你得先拿到cookie，再带着referer去请求下一页。单纯把URL当入口，爬不了几页就断了。

“爬虫的入口不是一扇门，而是一串钥匙。你得先找到锁孔在哪。”

我见过最隐蔽的入口，藏在一个招聘网站的JavaScript文件里。整个站点用React写的，首页HTML里没有任何职位数据。翻遍Network面板，发现它请求了一个/graphql端点，POST body里带着query语句。那个GraphQL端点就是唯一的入口。没有它，你连一条职位信息都拿不到。后来我把这个发现写在博客上，有人留言说：“原来搜索入口还能是GraphQL。”对，它可以是任何东西。

说到搜索，还有一个层面：当你自己写爬虫去抓搜索引擎的结果页时，那个搜索框的URL构造方式本身就是入口。比如https://www.google.com/search?q=keyword，把keyword换成你要查的词，请求这个地址就能拿到结果页HTML。但Google现在对爬虫很敏感，频繁请求会弹验证码。所以很多人转向Bing，https://www.bing.com/search?q=keyword，相对宽松一些。更别说还有DuckDuckGo的HTML版，https://html.duckduckgo.com/html/?q=keyword，结构干净，几乎没有反爬。这些URL模板，就是爬虫工程师口中的“搜索入口”。

入口找对了，后面的事才顺。找错了，写再多解析代码都是白费。我现在的习惯是：拿到一个站点，先看robots.txt，再看sitemap.xml，然后打开开发者工具，把Network面板里的XHR请求按大小排序，最大的那几个通常就是数据接口。最后才去翻HTML。这个顺序帮我省了很多时间。

WebCrawler那个1994年的小脚本，入口就是一个硬编码的URL列表。今天的爬虫入口，可能是API、可能是GraphQL、可能是WebSocket、可能是你根本没想过的某个CDN边缘节点。入口在变，找入口的方法也在变。但核心没变：你得先知道数据从哪来，才能把它拿走。