企业官网建设流程全解析

1. 封面图的存放原理：为什么一张图片要让爬虫专门去追

做内容运营那会儿，我经常要给一批B站视频做合辑封面，一两个视频可以靠右键另存解决，但手上攒了七八十个视频链接，手动去网页里淘封面图纯粹是浪费生命。于是我把目光放到了爬虫上。最开始我以为封面就藏在网页源码里，F12翻一圈就能搞定。真正动手后发现，B站的图片资源走的是专门的对象存储，拿到URL只是第一步，后面还有压缩参数、防盗链、请求拦截这些暗坑等着你。这篇博文就把整个实践过程完整捋一遍，代码直接给你，思路也展开说。

先说一个基本概念：B站视频封面到底存在于哪里。用户在B站投稿时上传的那张封面图，会被B站丢到自家的图床服务上，域名一般是i0.hdslb.com、i1.hdslb.com或i2.hdslb.com，路径结构类似/bfs/archive/xxxxx.jpg。这个地址和我们平时在浏览器里看到的视频封面地址是同一个，只不过浏览器会经过一层图片处理服务，按页面需要的尺寸生成压缩版。

1.1 B站封面到底存在哪里：图床地址与两处入口

封面图在B站前端有两处入口可以被爬虫触及。第一处是视频详情页的HTML源码里，有一个<meta name="og:image" content="...">标签，内容就是封面图的URL。第二处是官方API接口返回的JSON数据，里面有一个pic字段。两处拿到的地址基本相同，区别在于：HTML里取到的可能是已经被加过压缩参数的图片地址，而API返回的pic字段同样可能带压缩参数。

这就引出一个新手最容易忽略的问题：从这两处入口拿到的封面URL，经常长这样：

http://i0.hdslb.com/bfs/archive/abc123.jpg@672w_378h_1c_!web-search-common-cover

后面的@672w_378h_1c_!web-search-common-cover是B站图片处理服务的动态裁剪参数，意思是按672x378的尺寸、质量系数1.0压缩处理。如果你把这个链接原样保存下来，得到的就是一张被压缩过的图，宽度只有672像素。所谓"高清封面"，核心操作就是把@后面的部分整个切掉，拿回原始图片地址。这个细节我在第一次写脚本时踩得很深，后面细说。

1.2 view接口返回的JSON里藏着什么

我们常用的是这个官方接口：

https://api.bilibili.com/x/web-interface/view?bvid=BVxxxx

这是B站提供给前端网页播放视频时使用的详情接口，不需要登录，也不需要Cookie。请求方式是很普通的GET请求，参数就是视频的BV号。接口返回的JSON结构大致如下：

{ "code": 0, "message": "0", "data": { "bvid": "BV1xx411c7mY", "aid": 123456, "title": "视频标题", "pic": "http://i0.hdslb.com/bfs/archive/abc123.jpg", "owner": { "name": "UP主名", "mid": 12345678 }, "duration": 372, "pubdate": 1700000000 } }

那个pic字段就是我们想要的封面地址。顺带说一下data.title是视频标题，data.owner.name是UP主昵称，data.duration是视频时长（秒）。这些字段在批量整理素材时都有用，比如你可以按UP主名给封面分文件夹，或者把标题里的关键词做成检索索引。

这个接口的稳定程度其实相当高。我从2023年开始用，遇到的大多数问题都不是接口变动，而是自己的请求头没配好，触发了风控拦截。另外补充一句：如果你手头只有视频的av号，也可以用https://api.bilibili.com/x/web-interface/view?aid=xxxx，返回的JSON里一样包含pic字段。BV号是B站后来推出的替代方案，但av号并没有被完全废弃。

1.3 高清原图的暗道：去掉@后面的压缩参数

前面提到封面URL里可能带着@...后缀，这一节详细说。B站的图片URL规则可以理解为：原始图片地址 @ 处理参数。处理参数由B站图片服务动态生成，控制缩放比例、质量系数、渐进式加载等。直接下载这种带参数的地址，得到的是一张被处理过的图。

处理方式有两种。第一种是字符串切分：

def clean_cover_url(url): if "@" in url: return url.split("@")[0] return url

第二种是用正则替换掉@后面的所有内容。实测下来字符串切分已经足够，因为B站图片服务对@的处理很统一，没有出现过URL本身含@的情况。但要注意：少数老视频的封面URL不带任何后缀，直接就是原图，所以clean_cover_url里加一个判断很有必要。

切完之后你拿到的就是图床上最原始的封面图文件。B站投稿时对封面的原始分辨率要求不高，但原图通常都在1280x720以上，比压缩图清楚一个档次。我之前用这个逻辑处理一批音乐区MV封面，切掉参数后的图片尺寸从672x378恢复到了1920x1080，打印出来做海报都够用。

2. 环境准备与请求头：避免403/412的第一步关卡

既然目标是写一个Python爬虫，环境方面不需要很复杂。Python 3.8以上的版本都可以跑，核心第三方库只有一个requests。如果你要顺带用xpath解析HTML，再装一个lxml。安装方式没什么特殊：

pip install requests lxml

这些库搞定之后，先别急着写业务逻辑。我强烈建议你先把请求头配好再来考虑代码结构。B站对不带请求头的裸请求非常敏感，我见过不少人在自己机器上跑同样的代码，有的人能出数据，有的人直接拿到403，差别往往就在请求头的完整度上。

2.1 Python环境和requests/lxml的准备

关于Python本身的安装，我多说一句：去python.org下载官方安装包，安装时一定勾选"Add Python to PATH"。很多新手装完Python之后在命令行输入python没反应，十有八九是漏了这一步。装好之后在终端里执行：

python --version pip --version

两条命令都有输出说明环境正常。如果你用的是Anaconda之类的一体化发行版，那么requests通常已经集成，装不装lxml看你自己需求。项目里只需要requests这一个库就能完成API请求和图片下载，所以依赖非常轻，这也是整个脚本我只用一个.py文件就能跑通的原因。

在开始写爬虫之前，我建议你手动测试一遍API连通性。拿一个你收藏的BV号直接在浏览器地址栏访问：

https://api.bilibili.com/x/web-interface/view?bvid=BV1xx411c7mY

如果能看到{"code":0,"data":{...}}的JSON，说明你的IP和网络环境访问该接口完全正常。这一步的意义在于：把"接口本身能不能通"和"我的代码有没有写错"两个问题分开，后面排错时能省很多时间。

2.2 请求头三件套：UA、Referer与Accept的实践顺序

B站的接口风控主要看你三个方面：User-Agent、Referer、请求频率。这三个配合起来，基本能模拟出真实浏览器请求的样子。

HEADERS = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36", "Referer": "https://www.bilibili.com/", "Accept": "application/json, text/plain, */*" }

这里面最有讲究的是Referer。B站的图片服务i0.hdslb.com会校验请求来源，如果请求头里没有合适的Referer，图片接口会直接返回403。很多人下载封面失败，卡的就是这一步，他们从API拿到了图片URL，却在下载图片时忘了带Referer。

UA的选择也值得留意。我测试过用默认的python-requests/2.31.0直接请求，短时间内可以成功，但批量请求时更容易触发-412拦截。换成最新版Chrome的UA字符串后，稳定性明显提升。至于Accept，对API接口影响不大，但保留application/json是个好习惯，能让B站返回纯净的JSON数据，偶尔还能避免返回压缩格式。

2.3 网页xpath解析和官方API的方案对比

有些朋友学爬虫是从xpath入手的，觉得解析HTML总比调API"正规"。实际上对B站封面这个需求来说，HTML解析和API各有优劣。先给结论：首选API。

用xpath解析B站视频页HTML，核心代码大致是这样：

from lxml import html import requests page = requests.get("https://www.bilibili.com/video/BV1xx411c7mY", headers=HEADERS) tree = html.fromstring(page.text) cover = tree.xpath('//meta[@name="og:image"]/@content')

这里注意一个细节：提取的是meta标签的content属性，不是标签文本，所以用@content而不是text()。很多新手写xpath时会把text()和@attribute搞混，用text()去取属性值往往会拿到空列表。这个坑当年我也踩过。

HTML解析方案的问题在于：B站视频页是重前后端交互的页面，HTML结构改动频繁，而且页面里嵌入大量脚本标签和动态数据，一旦某个版本更新改了meta标签的位置，你的xpath表达式就要跟着调。API方案则是面向数据的接口，字段变更相对克制，出现问题时排查成本低得多。下面这个表格是我在实际使用中总结的对比：

对封面爬虫这种轻量需求，官方API几乎是唯一理性选择。它返回的就是结构化JSON，代码不用解析乱七八糟的HTML，出错位置一目了然。

3. 从单个BV号到落地文件：API解析与图片下载的完整链路

核心逻辑其实就三步：拿到BV号、请求API、下载图片。但每一步都有细节需要处理到位，尤其是输入格式的鲁棒性。用户给你的链接可能五花八门，有的带前缀后缀，有的是短链，有的甚至是av号，这都要求你在输入层做好容错。

3.1 面对"BV号、链接、短链、av号"四种输入时如何稳定提取

先说最标准的情况：用户提供完整视频链接，比如：

https://www.bilibili.com/video/BV1xx411c7mY/?spm_id_from=333.999.0.0

BV号是固定格式：字母B和V开头，后面接10位大小写混合的字母数字。用正则提取非常稳：

import re def extract_bvid(text): text = text.strip() if text.startswith("BV"): return text[:12] match = re.search(r"BV[0-9A-Za-z]{10}", text) if match: return match.group(0) return None

注意BV号的总长度是12个字符，包括开头的"BV"。这个正则模式BV[0-9A-Za-z]{10}可以匹配绝大多数真实BV号。但有一个冷门情况：小写"bv"开头的输入，用户从某些平台复制过来的链接可能经过转码导致首字母变小写。稳妥做法是在匹配前统一转换成大写。不过BV号本身区分大小写，转成大写后后面的字母如果原本是小写也会失配。折中方案是保留原文匹配两次：

match = re.search(r"[Bb][Vv][0-9A-Za-z]{10}", text)

这样可以兼容大小写。如果输入是b23.tv短链，例如https://b23.tv/xyz123，正则匹配不到BV号，因为短链里根本不含BV号。这种就要先做重定向展开：

resp = requests.get(url, headers=HEADERS, allow_redirects=True, timeout=10) real_url = resp.url # 重定向后的完整链接里含BV号

从real_url再走一遍extract_bvid就能拿到了。实测b23短链会302跳转到完整视频页，这个办法没什么技术含量，但很实用。

如果输入是av号，情况又不一样。av号是纯数字，正则提取数字后调用aid参数的接口即可，前面已经提过。为了让脚本通用性更好，我在代码里做了个分流：先试BVID，提取不到就找数字当成aid。

3.2 调用view接口并解析封面的最小代码

请求接口的代码很简单，但要注意两点：先检查requests.get的状态码，再检查业务层的code字段。这两个不是一回事。HTTP 200只代表请求到达服务器并正常返回，但业务层可能返回code=-404表示视频不存在。

def get_video_info(bvid): url = f"https://api.bilibili.com/x/web-interface/view?bvid={bvid}" resp = requests.get(url, headers=HEADERS, timeout=10) if resp.status_code != 200: print(f"[请求异常] {bvid} HTTP状态码 {resp.status_code}") return None data = resp.json() if data["code"] != 0: print(f"[接口错误] {bvid} {data.get('code')}: {data.get('message')}") return None info = data["data"] return { "bvid": info["bvid"], "title": info["title"], "pic": info["pic"], "author": info["owner"]["name"] }

这里我加入了错误分支打印，方便批量跑的时候快速定位问题。实测中遇到最多的错误码是-404（视频已删除）和-412（风控拦截）。前者直接跳过即可，后者后面专门展开讲。

3.3 下载原图时的防盗链处理与文件命名

拿到pic字段后，先走一遍clean_cover_url去掉压缩参数，然后发起图片下载。这里的关键仍然是请求头，而且必须具备Referer防盗链校验。代码示例：

def download_cover(info, output_dir="covers"): os.makedirs(output_dir, exist_ok=True) raw_url = clean_cover_url(info["pic"]) resp = requests.get(raw_url, headers=HEADERS, timeout=15) if resp.status_code == 200 and len(resp.content) > 1024: filename = f"{info['bvid']}_{safe_filename(info['title'])}.jpg" filepath = os.path.join(output_dir, filename) with open(filepath, "wb") as f: f.write(resp.content) print(f"[下载成功] {info['bvid']} 大小 {len(resp.content)//1024}KB") return True else: print(f"[下载失败] {info['bvid']} HTTP状态码 {resp.status_code}") return False

为什么要判断len(resp.content) > 1024？B站部分视频的封面如果不存在，接口可能返回一张默认占位图或者干脆给你一段JSON字符串。判断文件大小能避免把错误响应内容存成jpg文件。正常封面图的体积至少在几十KB以上。

文件命名这里有个小坑：视频标题里经常出现/、\、?、:这些在Windows文件系统里非法的字符，比如标题叫"某某up主/新作/预告"，如果你直接把标题拼进路径，文件写入时会报错。所以我加了一个safe_filename函数：

def safe_filename(name): return re.sub(r'[\\/:*?"<>|\r\n]', "_", name)

把非法字符统一替换成下划线。文件名采用BV号_视频标题.jpg的格式，BV号保证唯一性，标题提供可读性。如果你只想要封面素材不关心标题，也可以只存BV号。

4. 批量保存的核心设计：输入组织、命名去重与断点续传

从单个视频扩展到批量处理，真正影响体验的是任务怎么组织。理解了输入来源和异常恢复这些问题，才能让脚本稳定跑完几百个视频而不需要人盯着。

4.1 三种常见批量输入方式与取舍

批量输入最常见的方式是本地文本文件，每行一个BV号或完整链接。这种方式对用户最友好，写在记事本里就能用。脚本读取的核心逻辑：

with open("bvid_list.txt", encoding="utf-8") as f: lines = f.readlines()

第二种方式是从浏览器收藏夹或B站收藏夹导出HTML文件，用正则把所有BV号一次性提取出来。B站收藏夹网页版的页面数据里含有一批BV号，可以把整页保存为HTML然后统一提取。不过B站的收藏夹接口需要登录态，这个方案适合读导出的文件，不适合实时拉取。

第三种方式更进阶：遍历某个UP主的全部投稿视频，动态获取视频列表再加封面。这个需求不是不能做，但B站的用户空间接口引入了较复杂的签名参数（现在叫WBI签名），需要额外写签名逻辑。我给一个简化版思路：先用Up主空间的公开API拿到视频列表，再对每个BV号调view接口抓封面。但这块涉及签名算法，代码量会明显上升，新手阶段不建议一上来就碰，等基础流程跑通了再考虑扩展。

4.2 以BV号+标题为文件名的去重逻辑

批量处理时，最怕两件事：同一个BV号在列表里出现多次导致重复下载，以及已下载的文件被覆盖。BV号本身的唯一性天然适合做去重键。

我的做法是在主循环里维护一个seen集合，输入列表中只要BV号重复，直接跳过。这个设计简单但很有效，尤其在处理从收藏夹导出的大列表时，同样的链接往往会出现两三次。

为了进一步避免重复下载已经处理过的BV号，在写入文件名时用BV号作为前缀也起到了保险作用。即使脚本意外重跑，文件名还是同一个，重复下载会覆盖同名文件，虽然浪费一点流量，但不至于留下堆积如山的垃圾文件。

4.3 断点续传的实现思路

批量爬取最痛苦的场景是你跑了一半，网络断了或者被B站临时拦了一下，脚本中断。如果每次重启都要从头再来，那几百个视频的列表简直折磨人。

断点续传的思路是：已经成功下载的封面文件名里带有BV号，那么下次启动时，先扫描covers目录里已有的jpg文件名前缀，把这些BV号收集起来，遇到它们直接跳过。

def get_downloaded_set(output_dir): if not os.path.exists(output_dir): return set() return {f.split("_")[0] for f in os.listdir(output_dir) if f.endswith(".jpg")}

主循环里：

downloaded = get_downloaded_set(output_dir) for line in lines: bvid = extract_bvid(line) if not bvid or bvid in seen or bvid in downloaded: continue ...

这个做法的好处是：断点续传不依赖额外的状态文件，下载结果本身就是状态。即使写日志的代码出了问题，只要文件名有BV号前缀，就能从文件系统中恢复进度。我在实际使用中还试过另一个方案：把处理进度写进SQLite数据库。但那明显是过度设计，对封面爬虫这种轻量任务来说，文件系统就是最好的持久化层。

4.4 请求频率控制的节奏与重试策略

说完断点续传，再聊聊防封。B站对同IP短时间内的高频请求有明确的风控逻辑，表现为接口返回code=-412。批量处理时我是这样控制频率的：每请求一次视频信息接口，至少暂停0.8到1秒。这个节奏模拟了人工浏览的间隔，实测跑几百个BV不会触发拦截。

import time for i, line in enumerate(lines, 1): bvid = extract_bvid(line) if not bvid: continue info = get_video_info(bvid) if info: download_cover(info, output_dir) time.sleep(0.8) if i % 50 == 0: print(f"[进度] 已处理 {i} 条，休息10秒") time.sleep(10)

每处理50条主动休息10秒，是给IP的冷却时间。这个习惯是从一次被-412拦截的教训里学到的：当时我图快，把间隔压到0.2秒，结果跑了100多个BV之后接口突然全部返回-412，整整等了一个多小时才恢复。风控惩罚不是一次性的，而是把你这个IP标记为"高风险"，后续几十分钟内所有请求都被拦。所以频率控制一定要有耐心，批量任务跑得慢没关系，跑得断才是麻烦事。

关于失败重试，我的策略是：单个BV请求失败后不立即重试，因为大部分失败原因是视频不存在或权限受限，重试也难以成功。只有遇到网络超时这类临时性错误才值得重试。可以在get_video_info里对Timeout异常做三次重试，其他异常直接跳过。

5. 实测翻车记录：第三方工具失效、-412拦截与链接提取残局

再成熟的代码也是在和真实环境的对抗中打磨出来的。这里把我在实践中踩过比较有代表性的坑展开说一说，有些坑跟具体接口强相关，有些则能给其他爬虫项目做参考。

5.1 从Downkyi登录失效看B站风控收紧对我们的启示

近期有不少人在讨论B站下载工具登录失效的问题。以Downkyi为代表的桌面端工具，它们的核心逻辑是借助用户的登录Cookie或扫码登录态拉取视频流和弹幕数据。但B站近期明显在收紧风控策略，登录态的有效期变短，Cookie校验的逻辑也更严格，于是这类工具频繁出现"登录失败""账号未授权"的提示。

对比之下，封面爬虫完全没有这个烦恼。原因在于封面图、视频标题这类基础元数据属于B站的公开内容，走的是前端网页自己调用的公开接口，不需要用户身份信息。这个思路的启示是：做任何B站相关的自动化脚本，尽量把对登录态的依赖降到最低。能通过公开接口解决的问题，绝不去动Cookie；能读JSON的服务，绝不去解析动态渲染的HTML。这样脚本受平台登录策略变动的影响就小很多。

5.2 code=-412请求被拦截的完整排查链路

这是爬虫代码路上必然遇到的一个标志性错误。现象是接口返回：

{"code": -412, "message": "请求被拦截"}

我整理了一个排查链路，按顺序排查能快速定位大多数情况：

第一步，检查UA。如果你的UA是python-requests这类明显的程序标识，换成最新版Chrome的UA字符串。这是最简单也最常见的修复手段。

第二步，检查Referer。API接口的Referer通常校验不严格，但带上https://www.bilibili.com/总不会错。图片下载则必须带，不带大概率403。

第三步，检查请求频率。如果前面两条都正常还出现-412，考虑是不是跑得太快。连续请求间隔拉大到2秒，再观察状态。

第四步，确认IP本身没被B站风控标记。你可以访问一下B站首页，如果首页要求滑块验证之类，说明这个IP已经处于高风险状态。这种情况下，脚本层面的调整已经无法解决，只能停止运行等待风控状态冷却，或者更换网络出口。

我个人遇到-412最多的场景是在跑大批量任务时，前面几步全做对了还是被拦，最后发现是某个循环里忘了加sleep，连续打了几十次请求。所以频率控制永远是最后一道防线，也是最重要的防线。

5.3 短链重定向与av号转BV号的实战处理

链接格式的坑比较琐碎，但用户给的数据总是五花八门。我遇到比较多的三种情况：

第一种是b23.tv短链接。前面提过用allow_redirects=True跟随重定向，从resp.url里再提取BV号就行。要注意的是短链跳转可能再跳一次，requests默认会一直跟随到最终页面。

第二种是分P视频。链接带?p=2参数，比如：

https://www.bilibili.com/video/BV1xx411c7mY?p=2

分P视频的封面通常和第一P一致，提取BV号时会被正则正常匹配，不需要额外处理。但如果你遇到多P视频需要每一P的封面，那就得换成https://api.bilibili.com/x/player/pagelist?bvid=xxx这个分P接口，它返回的JSON里每P有一段cid，再用cid去查手绘封面。这个需求比较少见，提一下给大家留个印象。

第三种是误传av号。用aid参数请求view接口同样能拿到完整信息，得到的JSON里还有对应的bvid字段。如果你希望统一用BV号做文件名，可以从响应里提取data.bvid再存，这样不同来源的视频最终文件名格式仍然一致。

6. 边界与扩展：封面爬虫的合理使用和个人经验

技术上的东西聊得差不多了，最后说点使用层面的东西。写爬虫的人都知道，能爬到什么级别是一回事，应该爬到什么级别是另一回事。封面图在B站属于公开数据，但"公开"不等于"随便用"。我个人的使用底线大概有三条：只针对公开视频、不碰任何涉及用户隐私或付费的内容、请求频率保持礼貌水平。

6.1 这些场景适合用：素材整理、合辑制作、标题监控

封面爬虫最实用的场景是个人素材库的搭建。比如做二创剪辑时要给一批视频做封面墙，或者做视频选题调研时需要横向对比一批同类视频的封面设计风格，再或者运营自己的B站账号时想参考热门视频的封面构图。把这些场景下的封面批量下载下来，用图片浏览器直接网格视图查看，比一个网页一个网页地开要高效得多。

我还拿这个脚本做过一件意想不到的事：监控某个UP主的更新。把UP主主页的投稿列表定期拉下来，新的BV号出现时自动下载封面，配合标题信息可以快速发现新作品。不过这个方案的实时性不高，毕竟没有直接用B站的推送流，但对个人关注列表的中度需求已经够用。

6.2 这些线千万别碰：商用版权、隐私数据、付费内容

爬虫真正出问题的场景，不是因为技术实现，而是因为使用目的。封面图虽然是公开资源，但著作权仍属于上传者或授权方。批量下载后用在商业宣传、印刷品、电商平台等场景，都构成侵权风险。我建议这个脚本产出的素材只用于个人学习和非盈利性质的内容整理。

隐私和付费内容就更是红线了。任何需要登录态才能看到的数据，哪怕脚本技术上能做到，也不应该去碰。B站的风控体系越来越严密，很大程度上就是在约束这类越界行为。做技术的人要明白：爬虫的能力边界和合法边界常常是两回事，守住后者的底线，技术学习才能走得更远。

6.3 进一步扩展：按UP主、按分区、按收藏夹批量拉封面

如果你跑通了基础版，想玩得更深入，有三个方向可以参考。

第一个方向是按分区批量拉热门视频封面。B站有排行类接口，比如https://api.bilibili.com/x/web-interface/ranking/v2?rid=3&type=all返回分区排行榜的视频列表，从中提取BV号再套用封面下载逻辑。这样你可以一键获取舞蹈区或科技区Top100的封面合集。

第二个方向是按UP主拉全量封面。核心是调用B站用户空间的投稿列表接口，但需要处理WBI签名。签名逻辑具体可以搜索"bilibili wbi签名"的相关资料，用Python实现有现成轮子，核心就三步：向https://api.bilibili.com/x/web-interface/nav拿动态密钥，按规则排序拼接参数，再计算MD5摘要。拿到投稿列表后，剩下的逻辑就和基础版一致了。

第三个方向是按收藏夹批量拉封面。收藏夹数据接口需要登录Cookie，实现难度和稳定性风险都高一些。我给的建议是：除非有强需求，否则别碰。收藏夹的封面，直接浏览器导出网页后用正则提取BV号，再走无登录的API流程，反而更简单。

最后分享一个我认为很值得坚持的习惯：任何爬虫脚本跑完之后，都复盘一下自己的请求日志，看看有没有异常的高频请求或者失败的请求。这不仅是保护自己不被封，也是一种对公共资源的礼貌。我跑完这批封面整理项目之后，把日志里所有4xx状态码对应的BV号都找出来逐一检查，发现大多是失效视频，顺手清理了自己的收藏夹，也算意外收获。