接手一个几十个域名的后台系统时，最难搞的不是业务，是 Favicon。每个站的 HTML 写法都不一样，有的在<link rel="icon">里，有的藏在 CSS 里，有的干脆只留一个/favicon.ico。于是我花了一天，把爬虫工具从设计到实现做了一遍，核心代码和踩坑点全部整理出来。适合两类人读：一类是刚接触爬虫，想通过一个真实项目把 requests + BeautifulSoup 用熟；另一类是在网上找过 favicon 抓取方案，但发现现成工具要么是线上服务，要么是重型库，想自己维护一个轻量版本。
这篇文章不打算从头讲 HTTP 基础，而是直接围绕"怎么把一个网站的小图标稳定摘出来"这一件事展开。我会把全流程拆解开，讲清楚每一步为什么这么设计，再给出完整可跑的代码，最后附上我拿 50 个站点实测后统计出来的问题分类。你可以直接复制代码去改，也可以只学思路。
1. 为什么单独写一个 Favicon 爬虫工具，而不是直接调现成接口
1.1 我在什么场景下开始写这个工具的
我们后台有个模块，要用卡片形式展示外部站点，卡片左上角需要显示对方的小图标。站点数量一多，人工维护根本不现实：新增一个域名就要去查一次图标，查完还要手动下载、重命名、放到静态目录。更麻烦的是，图标这类资源经常改路径，今天写死的路径明天就 404。
后来我把需求抽象了一下：输入一个 URL，输出一个"可直接使用的图标地址"，必要时直接把图标文件下载到本地。听起来很简单，但真正动手后发现，这里面的细节比预期多得多，尤其是不同站点的 HTML 写法差异和网络异常处理。与其到处找半成品，不如自己写一个可以被业务反复调用的工具类。
1.2 现成方案看着省事，实际坑更多
我先对比了几条路，结果都不太满意：
| 方案 | 优点 | 真实痛点 |
|---|---|---|
| 第三方在线 favicon 服务 | 省事，传个域名就返回图标 | 依赖外网，隐私不可控，高频调用有限流，返回的尺寸往往由对方决定 |
| 通用爬虫框架（Scrapy、Crawlee） | 功能强，健壮性好 | 维护成本高，杀鸡用牛刀，没有专门针对 icon 的语义处理 |
| 浏览器截图工具 | 一定能拿到真实渲染结果 | 太重了，要跑无头浏览器，内存开销大，不适合服务端高频调用 |
| 自己写 requests 脚本 | 完全可控，逻辑透明 | 需要自己处理各种边界条件 |
我最后选了最后一条。核心原因不是"自己写更厉害"，而是只有自己写才能把需求做成刚好能用的形状：一个不到 200 行的类，放进项目里不碍事，又能在任何地方被调用。
1.3 自己写要抓住的核心设计目标
动手之前，我先列了四个必须满足的目标，后面所有设计都围着它们转：
- 输入容忍度高：用户传
example.com、https://example.com/abc都能处理。 - 必须有兜底：就算 HTML 里一个 icon 链接都没有，也要尝试
/favicon.ico。 - 错误不能被吞掉：找不到图标就明确返回空，而不是抛一串堆栈让上层崩溃。
- 可被复用：同事不想了解内部实现，直接
fetch(url)就能拿到结果。
这四个目标看起来简单，但它们直接决定了代码结构。尤其是"错误不能被吞掉"这条，我在后文会专门展开讲。
2. 全流程拆解：从 URL 到图标文件一共要过几道关
2.1 第一关：页面地址的清洗与补全
用户丢过来的地址五花八门：有人给example.com，有人给http://example.com，还有人给example.com/path/to/page。我要做的第一件事，就是把字符串变成一个可以安全发起请求的地址。
如果地址里没有协议头，我会默认补上https://。注意，优先用 HTTPS 而不是 HTTP，因为现在大多数站点都强制跳转 HTTPS，补了也不亏。补完之后必须用urlparse检查netloc是否为空，否则像https://这种半吊子输入会直接引发异常。
from urllib.parse import urlparse def normalize_url(url: str) -> str: url = url.strip() if not url: raise ValueError("URL 不能为空") if not urlparse(url).scheme: url = "https://" + url if not urlparse(url).netloc: raise ValueError(f"无法解析 URL: {url}") return url这里有个容易忽略的点：urlparse("example.com/path")会把example.com当 path，scheme 为空，所以我们要先补 scheme 再解析 netloc。顺序反了就会出错。
2.2 第二关：拉取 HTML 并找出所有 icon 链接
地址干净了，就要真实去请求一次页面。这里我用requests.Session而不是裸requests.get，因为同一个工具类可能被多次调用，Session 会复用底层连接，速度快不少。请求时要带一个像样的 User-Agent，很多站点对空 UA 的请求直接拒绝。
拿到 HTML 后用 BeautifulSoup 解析，遍历所有带href的<link>标签，过滤出rel属于图标类型的候选。这一关是核心，我在第 3 节会重点讲那些写法差异，这里先只看主干逻辑：
from bs4 import BeautifulSoup from urllib.parse import urljoin def extract_candidates(html: str, base_url: str) -> list: soup = BeautifulSoup(html, "lxml") found = [] for link in soup.find_all("link", href=True): rel = link.get("rel") if not rel: continue if isinstance(rel, str): rel_values = {rel.lower()} else: rel_values = {v.lower() for v in rel} if not (rel_values & ICON_RELS): continue href = link.get("href", "").strip() if not href: continue absolute_url = urljoin(base_url, href) found.append(absolute_url) return found为什么要用urljoin(base_url, href)？因为很多站点写的是相对路径，比如/icons/favicon.png，或者./favicon.png。而 base_url 不能用请求前的地址，要用请求结束后response.url的地址。如果页面从example.com302 跳到了www.example.com/page.html，后续所有相对路径都必须以跳转后的地址为准。
2.3 第三关：候选链接的去重、排序与校验
从 HTML 里可能筛出好几个候选：icon、apple-touch-icon、shortcut icon，它们可能指向同一个资源，也可能指向不同尺寸。这时要做的第一件事是去重，否则后面会重复请求浪费带宽。
去重之后，我会给候选按sizes属性排序。Apple 的触摸图标尺寸通常是 180x180，标准 icon 可能是 32x32。如果最终业务端需要的是高清图，优先取大尺寸；如果只要一个通用小图标，排序后取第一个即可。
真正请求候选图标之前，还要做一次"校验请求"。这一步的目的是确认：这个链接真的能返回图片，而不是一个 404 页面。我用stream=True发起请求，检查状态码、Content-Type以及文件二进制头。为什么要看二进制头？因为有些服务器的Content-Type会写application/octet-stream，甚至text/plain，但实际内容确实是图片。
def is_valid_icon_url(url: str) -> bool: try: resp = session.get(url, stream=True, timeout=(5, 10)) if resp.status_code != 200: return False content_type = resp.headers.get("Content-Type", "").lower() if content_type.startswith("image/"): return True # 看一眼文件头 first_bytes = next(resp.iter_content(16), b"") if first_bytes[:4] == b"\x00\x00\x01\x00": # ico return True if first_bytes[:4] == b"\x89PNG": # png return True return False except requests.RequestException: return False finally: resp.close()这里有个细节：校验是带stream=True的 GET，不是 HEAD。因为有些服务器 HEAD 请求的响应头不完整，甚至不允许 HEAD，用 GET 判断最保险。但由于只读了 16 字节就关闭连接，实际下载的开销很小。
2.4 第四关：真正的下载与本地落盘
校验通过后，剩下的事情就是二次请求并写入文件。写文件时要以wb二进制模式打开，不能写文本模式，否则图片会被换行符破坏。
def download(url: str, output_path: str) -> None: resp = session.get(url, timeout=(5, 10)) with open(output_path, "wb") as f: f.write(resp.content)注意，这里的第二次请求不是浪费。第一次请求是校验，只读了 16 字节；第二次才是完整下载。如果你对吞吐量有更高要求，可以在校验时直接把内容 split 成两份，一份做魔数检查、一份保存，彻底省掉二次请求。我这个工具为了逻辑清晰，选择了二段式，实际性能损失完全可以接受。
3. 真正折磨人的不是爬，而是 HTML 里的那些写法差异
3.1 rel 属性的排列组合比想象中多
规范文档里的 favicon 写法是<link rel="icon">，但现实世界根本不按规范来。我见过的写法包括：
rel="icon"rel="shortcut icon"（IE 时代的老写法）rel="apple-touch-icon"（iPhone 主屏图标）rel="apple-touch-icon-precomposed"rel="mask-icon"（Safari 的墨迹图标）
处理时必须把这些都纳入识别范围。但要注意，rel="mask-icon"通常需要配color属性，而且只有 Safari 会用到；如果你不想收集这种非通用格式，可以在 filter 阶段去掉。
还有一个特别容易踩的坑：BeautifulSoup 对rel属性的解析结果可能是列表也可能是字符串。在 HTMLParser 标准里，rel是多值属性，所以多数情况下它是['icon']，但若遇到<link rel="shortcut icon">，它可能是['shortcut', 'icon']。我在代码里统一转 set 再判断交集，这样不管它返回什么结构都不会出错。
3.2 href 的相对路径、协议相对与 data URI
href的多样性是第二个坑。常见的有四种：
- 绝对地址：
https://example.com/favicon.ico - 协议相对地址：
//cdn.example.com/favicon.ico - 相对地址：
/static/images/favicon.png - data URI：
data:image/svg+xml;base64,....
前三种都能用urljoin(base_url, href)解决。只要 base_url 正确，协议相对地址也会被自动补成完整 URL。
data URI 则比较特殊，它是一个"把图片内容直接嵌在 HTML 里"的格式。遇到这种情况，你要做的不是去下载，而是从data:后面把内容解析出来，去掉逗号前的 MIME 声明，然后 base64 解码后直接保存文件。如果 HTML 里用了 data URI 还带上引号或者换行，解析前需要先清理一下。
def handle_data_uri(uri: str) -> bytes: # 格式: data:[<mediatype>][;base64],<data> if "," not in uri: raise ValueError("不识别的 data URI") header, payload = uri.split(",", 1) if ";base64" not in header: raise ValueError("暂时只支持 base64 编码的数据") import base64 return base64.b64decode(payload)3.3 有些网站根本不写 link 标签，只能靠兜底路径
这是最让人头疼的一类。有些站点把 icon 写在 CSS 里，比如给body设了background: url(favicon.png)；有些站点甚至是在 JavaScript 运行后才动态插入<link>。对于静态爬虫来说，这些情况很难优雅处理，除非你动用无头浏览器。
所以我在设计里加了一层"默认路径兜底"：当 HTML 里找不到合法 icon 链接时，依次尝试https://域名/favicon.ico和https://域名/favicon.png。这两条路径是 90% 站点默认放置图标的位置，命中率很高。
默认路径兜底听起来简单，但它有个副作用：每次都要发起多一次请求，遇到 404 页面也要等超时。所以兜底路径不宜列太多。网上有人会把十几条常见路径全试一遍，比如/assets/favicon.ico、/images/favicon.ico，效率太低了。真要支持这类站点，应该建一个域名到路径的映射配置，而不是无脑穷举。
4. 网络层的容错策略：超时、重定向、SSL 与假 200
4.1 超时和重定向：不是越快越好，也不是越慢越好
爬虫最怕的不是失败，而是挂在一个请求上半天不返回。所以我所有请求都用了元组形式的超时设置：timeout=(5, 10)。这表示连接超时 5 秒，读取超时 10 秒。为什么分开？有些站点连接很快但响应很慢，有些站点连接就卡住。分别设置能更精准地控制。
重定向方面，requests默认会跟随 30 次重定向。对 favicon 抓取来说，30 次太多了，很容易掉进死循环。比较好的做法是让Session.max_redirects限制在 5 次左右，超过就当失败处理。虽然请求页面时合理重定向是常态，但一个 icon 链接连续跳转 5 次还拿不到图，就得怀疑是恶意循环了。
4.2 SSL 证书校验到底开不开
网上很多爬虫代码喜欢直接verify=False，把 SSL 警告一关就完事。我不太推荐全局这么做。你永远不知道目标站点是不是被人做了中间人，关闭校验等于把整条链路的安全都交给了运气。
我见过最合理的做法是：默认verify=True，如果遇到证书过期的站点，单独在异常处理里提示，而不是直接放行。如果你实在要处理自签证书站点，也应该维护一个域名白名单，只对白名单内域名关闭校验。
DEFAULT_VERIFY = True INSECURE_DOMAINS = {"self-signed.example.com"} def should_verify(url: str) -> bool: host = urlparse(url).netloc.lower() return host not in INSECURE_DOMAINS4.3 状态码 200 不代表内容真的是图标
这个坑我刚开始写时经常踩。很多老旧站点对所有缺失资源都统一返回 200，但页面内容其实是一段默认 HTML。你高高兴兴地把resp.content存成.ico文件，结果浏览器解析失败。
我处理这个问题靠两层检查：
Content-Type是否以image/开头。如果返回text/html，基本可以断定不是图标。- 如果
Content-Type不清晰，看文件魔数。这样就算服务器把图片当成二进制流返回，也能正确识别。
| 格式 | 魔数特征 |
|---|---|
| PNG | \x89PNG\r\n\x1a\n |
| JPEG | \xff\xd8\xff |
| ICO | \x00\x00\x01\x00 |
| WEBP | RIFF+WEBP |
| SVG | 文本内容以<svg开头 |
之所以检查文件头而不是只信Content-Type，是因为有些 CDN 会把所有文件都打成application/octet-stream，但内容依然是图片。如果不检查魔数，这类站点就全废了。
5. 完整代码实现：一个 200 行左右的 FaviconFetcher
5.1 依赖安装与项目结构
这个工具只需要三个依赖，我建议用虚拟环境安装：
pip install requests beautifulsoup4 lxml项目结构非常简单，全部逻辑放在一个模块里：
favicon_fetcher/ ├── fetcher.py ├── requirements.txt └── cli.pyfetcher.py放核心类，cli.py放命令行入口，requirements.txt放三个依赖。如果你只是想在业务代码里调用，甚至不需要 cli.py。
5.2 核心类完整代码
下面是fetcher.py的完整实现，我加上了类型注解，方便后续维护：
from __future__ import annotations import base64 import logging import re from dataclasses import dataclass from typing import Optional from urllib.parse import urljoin, urlparse import requests from bs4 import BeautifulSoup logger = logging.getLogger("favicon-fetcher") ICON_RELS = { "icon", "shortcut icon", "apple-touch-icon", "apple-touch-icon-precomposed", "mask-icon", } DEFAULT_USER_AGENT = ( "Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "AppleWebKit/537.36 (KHTML, like Gecko) " "Chrome/124.0 Safari/537.36" ) @dataclass class FaviconCandidate: url: str rel: str size: Optional[str] = None class FaviconFetchError(Exception): pass class FaviconFetcher: def __init__( self, timeout: tuple = (5, 10), user_agent: str = DEFAULT_USER_AGENT, verify: bool = True, ) -> None: self.timeout = timeout self.verify = verify self.session = requests.Session() self.session.headers.update({"User-Agent": user_agent}) self.session.max_redirects = 5 @staticmethod def normalize_url(url: str) -> str: url = url.strip() if not url: raise ValueError("URL 不能为空") if not urlparse(url).scheme: url = "https://" + url if not urlparse(url).netloc: raise ValueError(f"无法解析 URL: {url}") return url def _get(self, url: str): try: resp = self.session.get(url, timeout=self.timeout, verify=self.verify) resp.raise_for_status() return resp except requests.RequestException as exc: raise FaviconFetchError(f"请求 {url} 失败: {exc}") from exc def get_favicon_url(self, page_url: str) -> Optional[str]: page_url = self.normalize_url(page_url) resp = self._get(page_url) html = resp.text base_url = resp.url candidates = self._extract_candidates(html, base_url) candidates += self._default_candidates(base_url) seen = set() unique_candidates = [] for candidate in candidates: if candidate.url not in seen: seen.add(candidate.url) unique_candidates.append(candidate) unique_candidates.sort(key=lambda c: self._size_score(c.size), reverse=True) for candidate in unique_candidates: if candidate.url.startswith("data:"): return candidate.url if self._is_valid_icon_url(candidate.url): return candidate.url return None def _extract_candidates(self, html: str, base_url: str) -> list[FaviconCandidate]: soup = BeautifulSoup(html, "lxml") candidates = [] for link in soup.find_all("link", href=True): rel = link.get("rel") if not rel: continue if isinstance(rel, str): rel_values = {rel.lower()} else: rel_values = {v.lower() for v in rel} if not (rel_values & ICON_RELS): continue href = link.get("href", "").strip() if not href: continue candidates.append( FaviconCandidate( url=urljoin(base_url, href), rel=" ".join(rel_values), size=link.get("sizes"), ) ) return candidates def _default_candidates(self, base_url: str) -> list[FaviconCandidate]: parsed = urlparse(base_url) origin = f"{parsed.scheme}://{parsed.netloc}" return [ FaviconCandidate(url=urljoin(origin, "/favicon.ico"), rel="default"), FaviconCandidate(url=urljoin(origin, "/favicon.png"), rel="default"), ] @staticmethod def _size_score(size: Optional[str]) -> int: if not size: return 0 match = re.search(r"(\d+)\s*x\s*(\d+)", size) if not match: return 0 return int(match.group(1)) * int(match.group(2)) def _is_valid_icon_url(self, url: str) -> bool: try: resp = self.session.get( url, timeout=self.timeout, stream=True, verify=self.verify, ) if resp.status_code != 200: resp.close() return False content_type = resp.headers.get("Content-Type", "").lower() if content_type.startswith("image/"): resp.close() return True first_bytes = next(resp.iter_content(16), b"") resp.close() if first_bytes.startswith(b"\x89PNG"): return True if first_bytes.startswith(b"\xff\xd8\xff"): return True if first_bytes.startswith(b"<svg"): return True if first_bytes.startswith(b"RIFF") and b"WEBP" in first_bytes: return True if len(first_bytes) >= 4 and first_bytes[:4] == b"\x00\x00\x01\x00": return True return False except requests.RequestException: return False def download(self, url: str, output_path: str) -> None: data = self._download_bytes(url) with open(output_path, "wb") as f: f.write(data) def _download_bytes(self, url: str) -> bytes: if url.startswith("data:"): try: _, payload = url.split(",", 1) return base64.b64decode(payload) except Exception as exc: raise FaviconFetchError(f"无法解析 data URI: {url[:60]}") from exc resp = self._get(url) return resp.content这段代码一共不到 160 行，核心逻辑都在get_favicon_url和_is_valid_icon_url这两个方法里。你不用担心它过度设计：每个方法职责单一，后面想加缓存、加代理、加超时配置都不需要改结构。
5.3 怎么把这个类变成命令行工具
如果只做一次性抓取，命令行入口也很简单，写一个cli.py：
import argparse from fetcher import FaviconFetcher, FaviconFetchError def main(): parser = argparse.ArgumentParser(description="Favicon 爬虫工具") parser.add_argument("--url", help="目标站点 URL", required=True) parser.add_argument("--output", help="输出文件路径，默认不保存文件") args = parser.parse_args() fetcher = FaviconFetcher() try: icon_url = fetcher.get_favicon_url(args.url) if not icon_url: print("未找到可用 Favicon") return print(f"找到 Favicon: {icon_url}") if args.output: fetcher.download(icon_url, args.output) print(f"已下载到: {args.output}") except FaviconFetchError as exc: print(f"抓取失败: {exc}") if __name__ == "__main__": main()使用示例：
# 只打印图标地址 python cli.py --url example.com # 下载到本地 python cli.py --url example.com --output favicon.ico在这个阶段，工具已经可以满足大部分日常需求。但我还是要提醒一句：命令行工具好写，真正的稳定性要靠"批量跑过真实站点"来验证。
6. 实测反馈：我拿这个脚本跑了 50 个站点
6.1 测试结果分类
写完代码后，我从业务后台里随机抽了 50 个域名跑了一遍，结果大致分成四类：
| 结果类型 | 占比 | 说明 |
|---|---|---|
| 直接在 HTML 里命中 icon 链接 | 52% | 大部分现代站点不会偷懒 |
没有 link 标签，但/favicon.ico可用 | 30% | 中规中矩，靠兜底路径救回 |
| 命中了 data URI 图标 | 10% | 多出现在小型个人站 |
| 彻底失败 | 8% | 超时、404、证书异常、假 200 |
52% 的直接命中率听起来不高，但如果把兜底算上，整体成功率已经到 92%。对业务来说，剩下的 8% 直接用默认图兜底即可，完全不影响展示。
6.2 最常出现的三个失败模式
第一是"站点本身响应很慢"。首页 HTML 超过 5 秒才返回的站点确实存在，但它们未必不可用。对付这类站点，单纯把超时调大不理智，更合理的做法是在调度层做并发控制，把慢站点踢到重试队列。
第二是"服务器把缺失图标伪装成 200"。我遇到过几个老站，请求/favicon.ico时返回 200，但内容是 404 页面本身，Content-Type是text/html而不是图片。这正好验证了必须要做Content-Type和魔数双重校验，不能只看状态码。
第三是"CDN 或域名本身无法解析"。这类问题没有任何代码能完全规避，唯一的经验是：批量抓取时给每个域名记录失败原因，而不是简单打印一个异常。后来我把失败原因分类保存，方便上游运营同事去和对应站点联系。
6.3 值得按需增加的进阶功能
跑完这 50 个站点，我会顺手理一下哪些功能属于"最好有"而不是"必须有"：
- 并发版本：把
requests.Session替换成httpx.AsyncClient，用 asyncio 并发抓取，能显著提高批量速度。但注意控制并发数在 20 左右，否则容易被对方限流。 - 结果缓存：以域名为主键，把成功或失败结果缓存到 SQLite。第二次请求同一个域名时，直接返回上一次结果，避免重复消耗目标服务器资源。
- 图标归一化：
apple-touch-icon通常是大图，格式多为 PNG；如果业务端需要统一输出.ico，可以引入 Pillow 做格式转换。 - 合规性处理：如果抓取范围进一步扩大，建议在请求前读取目标站点
robots.txt，对明确禁止的路径做跳过处理。这既是基本礼貌，也能减少不必要的纠纷。
我不建议一开始就把这些功能全部放进代码里，因为我们很容易高估项目的复杂度。先把核心工具跑稳，再去按真实反馈逐步加功能，这才是更务实的路线。
最后分享一个实际经验：不要为了追求 100% 成功率而把所有异常都吞掉。这个工具我用到现在最稳的做法，是让它找不到图标时返回None，上层业务拿到空结果后自动展示一张默认图，而不是强行用一个假图标或者报错。宁可没有，也别给错，这个原则在很多数据采集场景里都成立。
