做短视频内容分析的时候最让人头疼的往往是数据来源太散。我前段时间接到一个内容盘点需求需要把新片场作品频道前20页的视频信息完整抓下来包括标题、作者、播放量、点赞数这些核心指标统一落到MySQL里方便后续做筛选和统计。整体链路我选了Scrapy来搭从请求调度、页面解析到数据入库一条龙搞定。这篇文章就把这套方案的完整过程拆开讲从环境搭建、字段抽取、翻页控制到MySQL存储都会覆盖中间还会穿插一些我实测踩过的坑适合刚接触Scrapy、想做一个完整采集项目的朋友直接参考。1. 项目目标与方案选型思路1.1 需求拆解到底要抓什么数据先把这个项目要解决的实际问题说清楚。新片场是一个视频创作人社区作品频道里会按时间或者热度不断更新视频内容。我的目标很明确把作品频道前20页的视频元数据全部拿下来持续用MySQL保存方便后续统计“哪些作者高产”“哪些视频数据表现好”。拆开来看核心数据字段大概有这些字段说明来源视频标题作品名称用于后续检索列表页作者昵称创作者名字列表页播放量播放数字可能有“万”这类缩写列表页点赞数点赞量列表页评论数评论条数列表页视频封面图封面URL用于后续生成缩略图列表页视频详情页地址唯一的视频标识可作为数据库唯一键列表页发布时间作品发布时间列表页从数据量来估算新片场每页大概展示12到16条视频取前20页的话也就是240到320条左右。这个体量对MySQL来说是毛毛雨真正需要花心思的环节是“怎么稳定地抓到页面数据”和“怎么把字段对齐入库”。如果只是拿requests写个循环也能做但可维护性太差页面结构一变就要手改所以我还是选了Scrapy。1.2 为什么用Scrapy而不是requestsBeautifulSoup很多初学者习惯用requests加BeautifulSoup写爬虫原因很简单代码直观。但这种组合在小项目里问题不大一旦涉及分页、去重、异常重试、数据管道就得自己写一堆配套代码。Scrapy的优势在于把采集流程拆分成了几层下载器负责发请求Spider负责解析Item Pipeline负责数据清洗和存储中间件负责加代理、换UA。每一层都能单独替换互不干扰。比如这次我踩到页面返回非JSON的问题只需要在下载中间件里加一个Request重试逻辑就能解决完全不用回去改Spider代码。另外Scrapy的异步并发能力很强。默认并发16个请求对于新片场这种不设太高反爬门槛的站点来说20页数据很快就能跑完。当然异步并发也得配合合理的下载延迟不然容易被封。我这里设置了1秒的下载延迟实际上就是“每秒钟最多发一个请求”的节奏整体跑下来大概20多秒能完成。还有一点Scrapy自带的去重过滤器可以避免重复请求日志系统和统计功能也能帮助确认“到底成功解析了多少条、丢了多少条”。这些能力虽然不是专题必需但在调试阶段特别有用。1.3 一整条数据流的运行逻辑我想先给出一条完整的数据流方便后面每个章节对号入座Spider发出请求目标是新片场作品列表的接口或页面。服务器返回HTML或JSON数据。Spider从响应中提取出视频字段生成Item对象。Item被交给Item Pipeline。Pipeline把Item写入MySQL数据库。翻页继续请求直到第20页为止。这个流程看起来简单但每一层都有很多细节值得展开。比如请求环节要考虑UA伪装和Referer来源解析环节要处理“播放量是字符串还是数字”这类脏数据入库环节要防止重复写入。后面章节的标题就是对这几层的逐一拆解。2. 环境准备与项目骨架搭建2.1 环境依赖清单与安装步骤开发环境我用的是Python 3.10Windows和macOS都试过这套流程。需要安装的关键库只有两个Scrapy核心爬虫框架PyMySQLPython连接MySQL的驱动安装命令很简单pip install scrapy pymysql如果你用的是conda环境也可以换成conda install scrapy -c conda-forge pip install pymysql安装完成后在命令行输入scrapy version如果能正常输出版本号就说明Scrapy基础环境已经就绪。这里插一句数据库也得提前准备好。我习惯先创建一个独立的库不跟其他业务混在一起。建议建一个spider_db数据库字符集用utf8mb4因为视频标题里很可能有特殊符号或emoji普通utf8会直接报错。CREATE DATABASE IF NOT EXISTS spider_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;2.2 初始化Scrapy项目与目录结构在命令行进入你想放代码的目录执行scrapy startproject xinpianchang_spider cd xinpianchang_spider scrapy genspider xinpianchang www.xinpianchang.com第一条命令生成项目骨架第二条命令创建一个名为xinpianchang的爬虫文件。此时项目的核心目录长这样xinpianchang_spider/ ├── scrapy.cfg └── xinpianchang_spider/ ├── __init__.py ├── items.py # 定义数据字段 ├── middlewares.py # 中间件可扩展UA/IP池 ├── pipelines.py # 数据管道负责入库 ├── settings.py # 全局配置 ├── spiders/ │ ├── __init__.py │ └── xinpianchang.py # 爬虫主逻辑初次接触Scrapy的朋友看到这么多文件不用慌实际开发中90%的时间只改四个文件items.py、spiders/xinpianchang.py、pipelines.py、settings.py。其他文件默认就能用。items.py负责定义“一条数据长什么样”相当于给数据先定个模板。pipelines.py负责“数据拿到后做什么”我这里是写入MySQL。spiders/xinpianchang.py负责“从页面哪里拿数据”。这三个文件各司其职正好对应爬虫的采集、解析、存储三层。2.3 settings.py里那些必须改的配置Scrapy默认配置偏向保守和安全直接跑大概率拿不到数据。拿到一个新项目我一般会先改这五处BOT_NAME xinpianchang_spider ROBOTSTXT_OBEY False 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 DOWNLOAD_DELAY 1.0 ITEM_PIPELINES { xinpianchang_spider.pipelines.MysqlPipeline: 300, }解释一下每个配置的用意。ROBOTSTXT_OBEY默认是TrueScrapy会先去请求目标站点的robots.txt如果里面禁止了爬虫后续请求就直接不发了。做技术学习项目时为了先跑通链路我一般会临时关掉。如果后续要长期跑、甚至商用就得换成完全合规的数据获取方案这个是底线。USER_AGENT必须改成浏览器UA。Scrapy默认的UA是Scrapy/2.x这种UA太显眼服务器一看就知道是程序在访问反爬门槛稍微高一点就会直接拒绝。改成Chrome的UA是成本最低的伪装方式。DOWNLOAD_DELAY设为1秒相当于每次请求之间至少间隔1秒。这个延迟能显著降低被封的风险。新片场总共就20页请求多等20秒完全可接受。ITEM_PIPELINES这里把Pipeline的优先级设为300。Scrapy里Pipeline是一个有序调用链数字越小越先执行只要设置了这个配置后面写的MysqlPipeline就会被自动调用。3. 数据定义与页面结构分析3.1 items.py里的字段定义先定义数据模板。打开items.py写入import scrapy class XinpianchangVideoItem(scrapy.Item): title scrapy.Field() cover_url scrapy.Field() author_name scrapy.Field() play_count scrapy.Field() like_count scrapy.Field() comment_count scrapy.Field() publish_time scrapy.Field() video_url scrapy.Field()每个scrapy.Field()就代表一个字段。你可能注意到了我没有在Item里定义description因为列表页通常只给简介详情页才有完整描述这个项目聚焦前20页列表数据所以先不扩展。用Item而不是普通字典的好处是字段可追踪。当Pipeline收到一个Item时如果字段缺失或类型不对可以提前拦截避免脏数据入库。我在实际调试中就遇到过标题字段偶尔为空的情况就是通过Item字段检查发现的。3.2 先判断页面是HTML渲染还是Ajax接口返回新片场的作品频道是用前端框架渲染的这一点很多教程不会明说。直接请求列表页拿到的HTML里可能只有页面的框架代码真正的视频数据是通过接口返回的。所以在写解析逻辑之前一定要先摸清数据到底是从哪来的。我用得最多的方法是浏览器的开发者工具打开新片场作品频道。按F12进入开发者工具。切到Network网络面板刷新页面。在筛选框里选择XHR或Fetch类型。翻到下一页观察新增的网络请求。如果发现某几个接口的响应内容里直接包含视频列表的JSON数据那就说明页面走的是Ajax接口。此时只需要直接请求这个接口用json.loads解析JSON即可比解析HTML还方便。新片场的频道接口大概长这样实际开发中以你抓包的结果为准https://www.xinpianchang.com/api/channel/works?page1typelatest响应JSON的结构大致是{ data: { list: [ { title: 作品标题, author_name: 作者昵称, play_count: 12345, like_count: 327, comment_count: 12 } ] } }这里要特别说明网站改版很频繁这个接口的字段名或路径随时可能变化。我写的所有代码都基于“抓包实际看到的字段”来适配你复现的时候也一定要按自己抓包的结果来对应字段不能生搬硬套。3.3 列表页HTML解析的备用方案如果接口被限制访问或者你更想练手解析HTML也可以直接解析列表页。先解释一下页面结构的规律作品列表通常是多个卡片式div每个卡片里包含标题、作者、数据指标。一个典型的列表项结构类似div classvideo-card a classvideo-card__cover href/video/12345 img srccover.jpg alt作品标题 /a div classvideo-card__info p classvideo-card__title作品标题/p span classvideo-card__author作者昵称/span span classvideo-card__play-count1.2万/span span classvideo-card__like-count327/span /div /div对应的XPath可以写成cards response.xpath(//div[contains(class, video-card)]) for card in cards: title card.xpath(.//p[contains(class, video-card__title)]/text()).get() author card.xpath(.//span[contains(class, video-card__author)]/text()).get()XPath后面的.//表示在当前卡片节点内部查找不会跳到外部去。写这种长XPath的时候强烈建议先到Scrapy Shell里验证一下否则很容易写错一个class名导致提取结果全部为空。scrapy shell https://www.xinpianchang.com/works进入Shell后直接跑XPath表达式看到实时返回结果再复制到爬虫文件里。4. 爬虫主体与翻页逻辑实现4.1 先请求接口再解析JSON明确了数据来源是接口之后爬虫文件就好写了。打开spiders/xinpianchang.py完整代码如下import json import scrapy from xinpianchang_spider.items import XinpianchangVideoItem class XinpianchangSpider(scrapy.Spider): name xinpianchang allowed_domains [xinpianchang.com] def start_requests(self): for page in range(1, 21): url fhttps://www.xinpianchang.com/api/channel/works?page{page} yield scrapy.Request( url, callbackself.parse_video_list, headers{ X-Requested-With: XMLHttpRequest, Referer: https://www.xinpianchang.com/works, }, ) def parse_video_list(self, response): try: data json.loads(response.text) except json.JSONDecodeError: self.logger.warning(接口返回的不是合法JSON: %s, response.url) return video_list data.get(data, {}).get(list, []) if not video_list: self.logger.info(第 %s 页没有数据可能到了末尾, response.url) return for video in video_list: item XinpianchangVideoItem() item[title] video.get(title) item[author_name] video.get(author_name) item[cover_url] video.get(cover_url) item[video_url] video.get(video_url) item[play_count] self._parse_count(video.get(play_count)) item[like_count] self._parse_count(video.get(like_count)) item[comment_count] self._parse_count(video.get(comment_count)) item[publish_time] video.get(publish_time) yield item def _parse_count(self, value): if value is None: return 0 if isinstance(value, int): return value text str(value).replace(,, ).replace(, ).strip() if 万 in text or w in text.lower(): number float(text.replace(万, ).replace(w, ).replace(W, )) return int(number * 10000) try: return int(float(text)) except ValueError: return 0这里有几个关键点。start_requests里的循环for page in range(1, 21)就是前20页的直接体现。我刻意没有写start_urls而是用start_requests来动态拼URL这样可以方便地控制页码范围。如果想爬50页把21改成51就行。请求头里加X-Requested-With: XMLHttpRequest是为了模拟浏览器发起Ajax请求。很多后端会通过这个头判断请求到底是页面跳转还是异步加载不加上可能拿不到JSON数据。Referer填作品频道的地址也很重要这是服务器识别请求来源的常用字段。4.2 解析函数里处理脏数据接口返回的播放量、点赞数可能有两种情况一种是整数比如12345另一种是字符串缩写比如“1.2万”。这种脏数据如果直接塞进数据库后续做统计时根本没法排序所以我在_parse_count里做了统一清洗。清洗逻辑分三步先判断是否为None是则返回0再判断是否为int是则直接返回最后处理字符串把“万”换算成真实数字。举个例子“1.2万”会先去掉“万”字得到1.2再乘以10000变成12000。这一步看似简单作用却很大。如果没有清洗逻辑MySQL里就会出现“1.2万”和“12345”两种混合格式后续查询用ORDER BY play_count DESC排序时会完全错乱。4.3 翻页控制与终止条件翻页控制是这个项目的核心。Scrapy里翻页通常有三种做法在start_requests里一次性生成多个URL每个URL对应一页这是“静态翻页”。在解析函数里查找“下一页”链接继续请求这是“动态翻页”。在解析函数里判断页数用meta传参这是“带状态翻页”。本项目因为明确只要前20页所以用第一种方式最直接。每一页的URL是独立的请求之间没有依赖关系Scrapy的调度器会自行处理并发和顺序。如果你希望“爬完整站所有作品”可以把逻辑改成动态翻页。在解析函数里检查当前第几页如果还有下一页且页数小于20就继续yield scrapy.Request(next_url, ...)。这种写法的好处是即使每页数量发生变化也能沿着“下一页”的线索一直抓下去。不过这里要提醒一句所有自动翻页逻辑都必须设置边界条件。没有边界的翻页爬虫是最危险的万一站点有大量分页就会在不知不觉中发起海量请求徒增封禁风险也加重对方服务器压力。我这个项目里range(1, 21)就是最明确的安全边界。5. Pipeline入库从内存到MySQL5.1 建表字段类型、字符集与唯一索引数据解析出来之后只是暂存在内存里下一步就要送到MySQL。打开MySQL客户端执行建表语句CREATE TABLE IF NOT EXISTS xinpianchang_videos ( id INT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(255) COMMENT 视频标题, cover_url VARCHAR(500) COMMENT 封面图地址, author_name VARCHAR(100) COMMENT 作者昵称, play_count INT DEFAULT 0 COMMENT 播放量, like_count INT DEFAULT 0 COMMENT 点赞数, comment_count INT DEFAULT 0 COMMENT 评论数, publish_time VARCHAR(100) COMMENT 发布时间字符串, video_url VARCHAR(500) NOT NULL COMMENT 视频详情页地址, crawled_at DATETIME DEFAULT NULL COMMENT 抓取时间, UNIQUE KEY uk_video_url (video_url) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT新片场视频数据表;字段类型的选择依据标题和作者名是文本用VARCHAR播放量、点赞数、评论数已经清洗成整数用INTvideo_url作为视频的唯一标识加了UNIQUE KEY来防止重复入库。为什么要给video_url加唯一索引因为同一个视频可能因为分页交错、重新抓取等原因被重复解析。有了唯一索引配合Insert Ignore语法就能在数据库层面拦截重复数据不需要自己写去重逻辑。crawled_at字段记录抓取时间方便后续做数据时效性判断。比如你想只保留最近一周的数据就可以根据这个字段来过滤。5.2 编写存储Pipeline连接、插入、关闭打开pipelines.py写入import pymysql from datetime import datetime class MysqlPipeline: def open_spider(self, spider): self.settings spider.settings self.conn pymysql.connect( hostself.settings.get(MYSQL_HOST, localhost), portself.settings.get(MYSQL_PORT, 3306), userself.settings.get(MYSQL_USER, root), passwordself.settings.get(MYSQL_PASSWORD, ), databaseself.settings.get(MYSQL_DB, spider_db), charsetutf8mb4, ) self.cursor self.conn.cursor() def process_item(self, item, spider): sql INSERT IGNORE INTO xinpianchang_videos (title, cover_url, author_name, play_count, like_count, comment_count, publish_time, video_url, crawled_at) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s) values ( item.get(title), item.get(cover_url), item.get(author_name), item.get(play_count), item.get(like_count), item.get(comment_count), item.get(publish_time), item.get(video_url), datetime.now().strftime(%Y-%m-%d %H:%M:%S), ) self.cursor.execute(sql, values) self.conn.commit() return item def close_spider(self, spider): self.cursor.close() self.conn.close()open_spider在爬虫启动时执行负责建立MySQL连接。process_item每收到一条Item执行一次负责插入数据库。close_spider在爬虫结束时执行负责关闭连接。数据库连接参数我习惯放在settings.py里与代码解耦。在settings.py末尾追加MYSQL_HOST localhost MYSQL_PORT 3306 MYSQL_USER root MYSQL_PASSWORD your_password MYSQL_DB spider_db这里有个容易踩的坑spider.settings拿到的不是一组普通字典而是一个Settings对象调用.get()方法时传默认值才是安全的写法。如果直接写spider.settings[MYSQL_HOST]一旦settings里没配置这个键就会抛异常。5.3 批量插入优化方案上面的Pipeline每次插入一条就commit一次对240条数据来说完全没问题。但如果以后要爬几万条甚至几十万条这样的效率就会明显下降。MySQL的commit操作涉及磁盘同步频繁提交会带来不小的I/O开销。一个实用的优化方案是攒一批再提交。在process_item中先用列表收集数据攒够一定数量后再批处理:def process_item(self, item, spider): self.items.append((...)) if len(self.items) 50: self._flush() return item def _flush(self): self.cursor.executemany(sql, self.items) self.conn.commit() self.items.clear()executemany是PyMySQL提供的批量执行方法一次性提交多条记录性能比循环execute高很多。我实际测试中批量插入200条数据的时间基本可以忽略不计。不过批量插入也有个缺点如果某几条数据因为冲突或类型问题失败定位起来不如单条插入直观。建议在Pipeline里加一层try/except把异常日志记录下来:try: self.cursor.executemany(sql, self.items) self.conn.commit() except Exception as e: self.logger.error(批量插入失败: %s, e)这样既能保留批量插入的性能优势又能及时发现数据问题。6. 常见问题与排查技巧实录6.1 反爬403、UA伪装与请求频率我一开始直接用默认UA跑结果第一个请求就返回403 Forbidden。这是绝大多数爬虫新手遇到的第一个坎。解决思路很简单把UA改成真实浏览器UA把请求头补全。做过几次之后我总结出了一个相对稳妥的请求头模板headers { User-Agent: Mozilla/5.0 ... Chrome/122.0.0.0, Accept: application/json, text/plain, */*, Accept-Language: zh-CN,zh;q0.9, Referer: https://www.xinpianchang.com/works, X-Requested-With: XMLHttpRequest, }如果403问题仍然存在就说明不只是UA的问题可能是IP被临时限制。这时候最有效的策略是降低请求频率。把DOWNLOAD_DELAY从1秒改成3秒再试基本能解决。对于只有20页数据这样的小项目完全没必要上代理池低频率就能顺利跑完。6.2 页面返回空数据先怀疑接口不对如果json.loads能成功解析但video_list一直是空列表这通常意味着请求的接口URL不对或者缺少某个关键参数。我自己遇到过一种情况接口地址是对的但缺少type这个查询参数导致服务端返回了空列表。排查方法很直接在浏览器里打开接口地址对比浏览器返回的结果和Scrapy请求的结果看哪里有差异。如果浏览器能返回数据而Scrapy返回空基本就是请求头或参数的问题如果浏览器也返回空说明接口路径本身就变了需要重新抓包确认。有时候接口返回正确但字段名对不上。比如你拿到的是work而不是list或者author字段不叫author_name而叫user_info.nick_name。解决的办法是先在浏览器里找到一条完整记录把它打印出来对照字段名逐个映射。我一般会在parse_video_list里加一行self.logger.debug(json.dumps(data, ensure_asciiFalse))把返回结构完整打出来看一眼。6.3 MySQL写入报错字符集与SQL语法MySQL写入时报错最常见的是两种。一种是Incorrect string value: \xF0\x9F...这代表要写入的数据包含4字节的emoji字符。解决方法是确保数据库表、数据库连接、字段字符集都使用utf8mb4。建表时设定了CHARSETutf8mb4pymysql连接时传了charsetutf8mb4这两个都不能漏。另一种是SQL语法错误提示You have an error in your SQL syntax。这种问题一般出在拼接SQL字符串时字段名写错或者逗号少了一个。我的建议是先把SQL单独拿出来手动执行一遍确认无误后再放回Pipeline里。用参数化查询%s也是一个好习惯千万别用f-string直接拼值既容易出错也容易引发注入问题。6.4 重复数据与数据校验首次跑完采集后我用以下SQL检查了数据SELECT COUNT(*) FROM xinpianchang_videos; SELECT COUNT(DISTINCT video_url) FROM xinpianchang_videos; SELECT title, play_count FROM xinpianchang_videos ORDER BY play_count DESC LIMIT 10;第一行看总条数第二行看去重后的条数如果两个数值不一致就说明有重复。第三行验证播放量字段的清洗效果如果排序结果里出现“1.2万”这种字符串就说明_parse_count没生效。顺便说一个很实用的操作在正式跑scrapy crawl之前可以先加-o videos.json参数把数据导出到JSON文件里做一次皮测。scrapy crawl xinpianchang -o videos.jsonScrapy会把所有Item自动序列化到JSON文件中。不需要连数据库就能检查字段是否完整、类型是否正确。没问题了再依赖Pipeline入库这个习惯能帮你少踩很多坑。7. 运行、验证与后续扩展方向7.1 执行爬虫完整命令行流程环境确认无误后在项目根目录执行scrapy crawl xinpianchang如果一切正常日志里会连续输出抓取到的条目记录最后会显示item_scraped_count统计这个数字就是成功解析的Item总数。想减少日志干扰可以加--nolog参数或者把LOG_LEVEL设为WARNING。跑完后回到MySQL再验证一次SELECT COUNT(*) FROM xinpianchang_videos; SELECT title, author_name, play_count FROM xinpianchang_videos LIMIT 20;如果能看到结构化数据说明整条链路已经打通。7.2 项目运行的完整流程回顾整个项目其实就五步分析新片场接口或页面结构确定数据来源。用items.py定义数据字段。用Spider请求接口、解析JSON、清洗脏数据。用Pipeline把Item写入MySQL。执行爬虫用SQL验证数据完整性。这个流程看起来简单但它具备了一个成熟采集项目的所有核心要素请求模块、解析模块、数据清洗、存储模块、异常处理。以后换任何网站只要把Spider解析规则和字段映射改一下整个骨架都可以复用。7.3 后续还能怎么扩展跑通基础版本之后有几个非常有价值的扩展方向。第一个方向是增量抓取。当前的逻辑是每次从第一页开始完整抓20页如果每天定点运行会有大量重复数据。虽然唯一索引能去重但重复请求毕竟浪费资源。更聪明的做法是把最大视频ID记录下来下次只爬新ID对应的视频或者只抓第一页检查新作品。第二个方向是详情页扩展。列表页只有核心字段如果你需要视频简介、标签、导演名字就得再写一个详情页爬虫把video_url交给scrapy.Request去做二次请求。这时可以充分利用meta参数将列表页Item传递进回调函数在详情页回调中补充字段后再yield item。第三个方向是可视化统计。数据入库后可以写一个统计脚本算一下播放量Top10的作品、高产作者排行、发布时间分布。这种统计对内容运营来说价值很高。第四个方向是定时触发。把scrapy crawl xinpianchang写进计划任务或持续集成工具里每天早上自动采集一次让数据库始终保持最新状态。7.4 关于稳定性的一点经验每次有朋友想直接拿这套代码跑线上环境我都会多说一句任何页面采集项目的代码都不是一劳永逸的。站点结构改版、接口参数调整、反爬策略升级任何一个变化都会让你的代码立刻失效。所以我的做法是在Pipeline里尽量保留原始返回数据的日志在数据库里记录crawled_at时间点定期抽查数据是否正常。真遇到某天数据量骤减说明要么接口变了、要么封禁了这时候打开浏览器对比一下通常花几分钟就能定位问题。这套以“稳定、可复现、易排查”为目标的小项目核心不在于代码量多少而在于每一层都各司其职请求、解析、清洗、存储。把它跑通一次你基本就摸清了Scrapy的完整工作链路后面再遇到更复杂的采集需求都能在这个骨架上做增量思考。
