最近有个做图书出版的朋友问我怎么才能快速分析某个图书网站上的销量排行和书评口碑。他的需求很典型想做一个季度图书趋势报告但人工去翻榜单、抄评论、归档数据一整天也搞不定几十本。我说这类活儿完全可以交给脚本去做也就是圈里常说的“图书网站书评与销量排行爬取”。今天这篇文章我就把整套流程从头到尾拆开讲从字段设计、页面分析、代码实现到常见的踩坑点一次性说清楚。需要说明的是这篇文章里的思路和代码示例只适合抓取公开可访问的页面数据用于个人学习、学术研究和常规的市场观察。动手之前请一定先看一眼目标网站的robots.txt和服务条款合理控制请求频率不要碰任何需要登录才可见的信息更不要采集个人隐私数据。抱着一颗尊重规则的心去做数据采集才能走得远。1. 内容整体设计与思路拆解1.1 核心需求你到底要抓什么很多人一上来就问“怎么爬图书网站”其实这是个伪命题。图书网站的数据维度太多了榜单是一种数据书评是另一种数据详情页里还有作者、出版社、ISBN、出版时间、定价、内容简介甚至还有“XX人读过”“XX人想读”这类行为统计。如果不先想清楚最终要分析什么脚本写到一半就会变成一场灾难。以“书评与销量排行”这个标题为例核心需求至少可以拆成两个子目标销量排行数据通常来自网站首页或者图书频道页的榜单比如“销量榜”“热卖榜”“畅销榜TOP100”。这些榜单会给出图书名次、书名、作者、评论数、评分有时候还有价格。书评数据点进某本书的详情页可以看到读者长评一般包括评论标题、评论正文、评论者昵称、评分星级、评论时间、有用/无用点赞数。这部分数据才是做口碑分析的金矿。这里要特别提醒一点榜单上的“销量”是个模糊概念。很多图书网站并不直接显示销量数字而是给出“周榜第X名”“热卖指数”或者“加入购物车次数”。所以设计数据表的时候不要把“销量”写死成一个整数最好按“榜单类型排名指数值统计维度”来存储这样后续分析才有弹性。1.2 技术选型Requests够用Scrapy不背锅选型这件事我见过太多人一上来就上Scrapy最后被框架的Spider、Middleware、Pipeline绕得头晕。其实对于图书网站这种结构相对规整的页面requests lxml 的轻量组合已经足够应对大多数场景。我的建议是这样页面量在几千页以内、单机跑、需求快速验证直接用requestsparsel或lxml代码短、调试方便。页面量非常大、需要断点续爬、分布式调度再考虑Scrapy它的去重队列、自动重试、下载中间件确实能省不少事。页面内容由JavaScript动态渲染、接口数据藏在异步请求里先用浏览器的开发者工具看Network面板找到真正的JSON接口再用requests直接请求接口。实在找不到接口再考虑Playwright或Selenium做无头浏览器渲染。很多图书网站的榜单页是服务端直接渲染的HTML书评列表页也许是动态加载的评论接口。如果你一上来就开无头浏览器反而会让性能变得很差还容易被反爬策略盯上。正确做法是“静态优先、接口其次、渲染兜底”。1.3 数据存储先想清楚分析要什么爬虫项目最忌讳“先存下来再说”。图书网站的数据存进数据库之后你会发现同一个版本的图书可能有多个条目同一本书在榜单上可能同时出现在“总榜”和“分类榜”同一批书评里还有大量重复转载内容。所以采集之前务必先设计好表结构。我常用的表结构是这样的book_info图书信息表 id, title, author, publisher, isbn, pub_date, price, detail_url, created_at rank_info榜单记录表 id, book_id, rank_type, rank, score, rating_count, price, crawl_date review_info书评表 id, book_id, review_title, review_content, reviewer, review_rating, review_date, like_count, created_at注意rank_info表里加一个crawl_date字段这样你连续抓一周的榜单就能看出哪本书的排名在上升哪本书是“周榜冠军”而不是永远只保留一份最新的榜单快照。2. 核心细节解析与实操要点2.1 页面结构分析先当侦探再写代码在写任何一行代码之前建议你花半小时把目标页面从里到外摸一遍。打开榜单页按下F12重点看三样东西列表页中每本图书的HTML容器通常是一个li或者div里面包含书名、作者、评分等。找到这个容器节点后面的数据提取就顺了。每条数据的详情页URL排行榜页上一般都有“点击查看详情”的链接这个链接是后续进入详情页抓取书评的入口。书评列表的加载方式如果是翻页链接直接改URL参数就行。如果是“点击加载更多”并向后端发Ajax请求那就去Network面板里找到对应的XHR请求看它的请求参数和返回格式。我见过不少新手在详情页上栽跟头从榜单页提取到了书名和评分就以为大事搞定结果详情页的书评数据是异步加载的直接抓详情页HTML只能抓到“暂无评论”或者第一页。所以要养成习惯先看页面主题页面的完整结构再决定数据从哪个URL拿。2.2 字段设计别遗漏那些看起来不起眼的数据围绕“书评与销量排行”这个需求我建议每本书至少保留以下字段字段来源页面为什么需要书名榜单/详情页主键之一但注意同名书要结合作者区分作者榜单/详情页分析作者维度的销量表现出版社详情页分析出版社的畅销能力ISBN详情页唯一标识用于去重和后续关联出版时间详情页判断新书和老书价格榜单/详情页价格对销量影响很大榜单名次榜单页销量排行核心指标榜单类型榜单页总榜、分类榜、周榜、月榜评分榜单/详情页口碑的重要量化指标评论数榜单/详情页参与讨论的热度评论标题书评列表快速了解评论主题评论正文书评列表情感分析、话题提取的原料评论者昵称书评列表关注大V书评是否影响销量评论时间书评列表时间维度趋势分析有用数书评列表判断评论质量你可能觉得“价格”对销量排行分析没什么用但实际上通过价格区间和销量分布的交叉分析你能得出“百元以上的书在畅销榜占比逐年下降”这种非常有价值的结论。没有这些字段后面的分析就只能停留在“TOP1是哪本”这种表面信息上。2.3 反爬与礼貌抓取润物细无声图书网站的运营者也不傻榜单和书评是他们的内容资产不可能让你用脚本哗啦哗啦地白嫖。所以反爬是一个绕不开的话题。但反爬不等于去攻击对方而是要在合理范围内做到“不打扰、不激进、有退让”。我的经验是遵守三条原则请求间隔随机化不要用固定0.5秒的间隔建议在0.5到1.5秒之间随机sleep。固定间隔反而容易被识别为机器行为。设置合理的请求头带上完整的User-Agent、Accept、Accept-Language模拟浏览器环境。不要把爬虫的名字写在UA里更不要用什么“Hack”之类的UA。遇到封锁就立刻收手如果连续出现403、418、频繁跳验证码就把程序停下来等一段时间再跑而不是加大力度重试。这里想多说一句很多爬虫教程会让你去搞什么“隐藏IP”“突破验证码”我自己是不赞成把这些写进常规教程的。做数据分析的同学走正道也能拿到足够多的公开数据。真要大规模商用那就去走官方API或者商业数据合作渠道。3. 实操过程与核心环节实现3.1 用requests抓取榜单页并解析列表下面我写一个通用的示例流程以某个公开图书网站的榜单页为例。实际使用的时候请替换成你需要分析的目标网站。import requests import parsel import time import random headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.8 } def fetch_page(url): resp requests.get(url, headersheaders, timeout10) resp.raise_for_status() resp.encoding resp.apparent_encoding return resp.text def parse_rank_page(html): sel parsel.Selector(html) books [] # 这里的li.book-item是针对常见列表结构的示例实际站点请自行调整 for item in sel.css(li.book-item): title item.css(h3 a::text).get() detail_url item.css(h3 a::attr(href)).get() author item.css(p.author::text).get() rating item.css(span.rating::text).get() if title and detail_url: books.append({ title: title.strip(), detail_url: detail_url.strip(), author: author.strip() if author else , rating: rating.strip() if rating else }) return books写代码时最需要留意的就是CSS选择器是否正确。很多新手会选择抄别人的选择器换个网站就失效了。这里我建议你用浏览器开发者工具先复制一个元素的选择器然后在Python里打印前几条解析结果做核对再批量跑。3.2 详情页补全销量与书评入口榜单页只给了图书的基础信息关键的销量指标和书评数据大概率在详情页。所以下一步是遍历详情页URL把信息补全。注意这里的“销量指标”在不同网站长得不一样有的是直接显示“已售出X万件”有的是“热度值”还有的是“周榜第X名”。设计代码时最好把这些字段分离然后解析时做字符串清理def parse_detail_page(html): sel parsel.Selector(html) info {} info[publisher] sel.css(span.publisher::text).get() info[publish_date] sel.css(span.publish-date::text).get() info[isbn] sel.css(span.isbn::text).get() # 销量/热度值不同网站叫法不同这里随便取了一个示例类名 info[sales_indicator] sel.css(span.sales-num::text).get() info[rating_count] sel.css(span.rating-count::text).get() return info这里我想重点强调一个经验不要只抓一个详情页字段就去存库。因为详情页和榜单页可能出现字段重叠比如评分和评论数两边都有但数字可能不一致。榜单页的评分可能是四舍五入的详情页的评分可能更精确。所以我建议在存储时把来源字段也一并记录或者干脆统一以详情页为准避免数据分析时出现对不上账的情况。3.3 书评列表页的分页与解析书评列表通常是一个单独的频道或者TabURL往往长这样https://example.com/book/12345/review?page1每翻一页URL里的page参数就会加1。我们可以写一个循环来抓取前N页书评def parse_review_page(html): sel parsel.Selector(html) reviews [] for r in sel.css(div.review-item): reviews.append({ review_title: r.css(h4::text).get(), content: r.css(div.review-content::text).get(), reviewer: r.css(a.reviewer::text).get(), rating: r.css(span.review-rating::attr(title)).get(), review_date: r.css(span.review-date::text).get(), useful_count: r.css(span.useful-num::text).get(), }) return reviews def crawl_reviews(detail_url, max_pages10): all_reviews [] for page in range(1, max_pages 1): review_url detail_url.rstrip(/) f/review?page{page} html fetch_page(review_url) reviews parse_review_page(html) if not reviews: break all_reviews.extend(reviews) time.sleep(random.uniform(0.5, 1.2)) return all_reviews这里有个常见的坑有些书评列表页使用“评论按热度排序”和“按时间排序”两种维度默认是热度排序。同一批评论按时间翻页可能和按热度翻页的集合不一样。为了让数据口径一致建议固定一种排序方式并在数据记录里加上sort_type字段。3.4 存储与去重数据入库前的三道关卡等数据抓到本地后还得经过三道关卡才能入库清洗、转换、去重。清洗主要是处理缺失值和脏数据。比如评论正文里混入的HTML标签要用正则或者parsel再清理一遍价格字段里有“¥”和空格要转成浮点数评分字段如果是“五星”这种文本要映射成5或4.5。转换主要是统一数据格式。日期最好统一成YYYY-MM-DD时间戳统一为10位或13位数字。书名里的全角空格、作者里的多个作者分隔符也要统一。去重是数据质量的生命线。由于翻页和详情页可能重复采集建议对每条数据计算一个哈希指纹比如MD5(书名 评论者 评论时间 评论标题)。重复记录直接跳过。import hashlib def gen_fingerprint(title, reviewer, date, review_title): raw f{title}|{reviewer}|{date}|{review_title} return hashlib.md5(raw.encode(utf-8)).hexdigest()3.5 增量抓取下一次跑脚本不用全量重来如果你只是想跑一次上面的代码没问题。但如果你想每周追踪榜单变化、观察书评数增长那就必须做增量抓取。增量抓取的核心逻辑很简单每次抓取前先从数据库读取已抓过的detail_url集合。榜单页里遇到已经存在的URL时可以跳过详情页抓取只更新榜单排名和评分。书评列表页只抓取书评ID大于上次最大书评ID的新评论。当然很多网站的书评没有数字ID退而求其次用“评论时间大于上次采集时间 评论者不在已知集合”来过滤。增量逻辑虽然会增加代码量但能极大减少对目标站点的访问压力。你想想一本畅销书可能有上千条书评每周全量抓一次不仅慢也容易触发反爬。增量抓取是更专业、更可持续的做法。4. 常见问题与排查技巧实录4.1 常见错误速查表这段内容很啰嗦但真的很实用。我直接整理成表格方便你对照排查现象可能原因排查思路403 Forbidden请求头不完整或UA被识别补充Cookie、Referer降低请求频率418 Im a teapot被WAF识别为机器请求暂停程序换时间段再试不要暴力重试返回的HTML中没有目标元素页面是动态渲染或选择器写错查看Network里是否有XHR接口确认选择器是否匹配乱码页面编码不是UTF-8用resp.apparent_encoding动态识别编码评论只有第一页有数据评论列表是异步加载找XHR接口或者用Playwright渲染数据库里出现重复数据翻页/详情页数据交叉建立唯一索引或指纹去重某本书的ISBN抓不到部分条目确实没有ISBN置空处理不要丢弃整条记录请求到一半超时网络波动或对方限流增加重试机制设置指数退避4.2 反爬封锁的现场处理我在实际采集中有一次印象特别深。当时抓一个图书详情页请求频率也不算高每秒钟也就1次但跑到几百条之后突然开始出现“请通过人机验证”的页面。最开始我以为是频率太高把间隔调到了3秒结果还是一样。后来发现是同一个账号登录态导致的因为详情页里的推荐位会带上用户ID无登录态的请求反而更容易被识别。那次的解决方式很朴素换了一个公共网络出口清掉所有带用户ID的Cookie并且把程序改成随机暂停、运行时长短的批处理模式。也就是说每次跑到200条就停10分钟效果立竿见影。这里也再次强调我不建议大家去研究破解验证码或者绕过风控。遇到封锁就说明对方的访问策略触发了保护机制最好的方式就是降低访问烈度或者分时段慢慢抓。4.3 时间字段与数据口径的坑图书网站的书评时间经常会出现“3天前”“上周”“2024-05-01”这种混合格式。如果你直接存字符串后续按时间排序就会很痛苦。建议在清洗阶段把这些相对时间统一换算成绝对时间。如果是“3天前”这种就用datetime.now()往前推3天如果是“上周”就推到上一周的同一时刻。这个转换逻辑写起来比较烦但非常值得做。否则你后面做“近一个月书评数量变化趋势”时会发现数据全是残缺的。4.4 榜单类型与数据合并问题很多网站同时存在“总榜”“新书榜”“童书榜”“小说榜”等多套榜单。同一个详情页URL可能会出现在多个榜单里。如果你在存储时把榜单名次直接存在book_info表的某个字段中过几天再抓一次字段就会被覆盖掉。正确做法是像前面说的那样把榜单信息单独放到rank_info表每次抓取都新插一行记录。后续分析时你既能看“今天的总榜第一名”又能看“过去30天总榜前十里哪些书上升最快”。这就是结构设计带来的红利。5. 进一步扩展与经验分享5.1 从数据到结论几个有价值的分析角度抓完数据之后很多人就不知道下一步该干嘛了。如果把整个项目看成一条流水线爬虫只是最前端的原料采集后面的分析才是真正能产生价值的部分。我建议优先做这几个分析评分与销量排名的关系把评分分成5分以上、4到5分、3到4分等区间对比各区间在销量榜中的占比。你会发现有些高分冷门书永远进不了畅销榜而有些低分争议书却卖得不错这背后能引申出很多关于图书营销和读者心理的判断。书评情感倾向与销量涨跌用简单的情感词典或者现成的NLP库给书评打正负向标签然后按周聚合。如果某本书的负面评论比例突然上升下一周销量往往是下降的这种规律在出版行业很有参考价值。评论时间与出版周期的相关性新书发布后多长时间能达到书评量峰值峰值持续多久能帮你判断一本书的“热度曲线”。5.2 自动化与定时更新的工程化思考如果你不想每天手动跑一次脚本可以考虑用操作系统的定时任务来做。Windows下是“任务计划程序”macOS和Linux下是crontab。比如每天凌晨2点运行一次采集脚本然后自动把结果追加到数据库。# 每天凌晨2点执行采集脚本 0 2 * * * cd /path/to/project /usr/bin/python3 crawl.py logs/crawl.log 21这里提醒一个小细节定时任务跑出来的数据一定要写日志。日志里记录每次抓取的起始时间、成功条数、失败条数、异常类型。没有日志的定时任务一旦哪天数据抓漏了你根本不知道是网络问题、反爬问题还是接口改版。5.3 给新手的三个实用建议最后聊几点我踩过坑之后的体会。第一先不要追求完美先跑通一条链路。哪怕只抓一本图书详情页和它的10条书评也别急着一次抓10万条。先把数据从榜单页 - 详情页 - 书评页这个路径完整跑通确认每个字段都能对上再扩大规模。第二协议和频率的克制是对自己最大的保护。我见过太多人因为爬虫把目标网站惹毛最后连正常浏览器访问都被临时限制。图一时之快得不偿失。控制频率不仅是为了对方也是为了让自己的任务更持久。第三把代码写成可以重跑的样子。不要每次抓完就改一堆参数要把URL、字段、选择器、分页规则都配置化。这样过了一个月网站结构调整了你能快速定位哪里需要改。做图书网站的书评与销量排行抓取技术难度一点都不高但真正考验人的是对需求的拆解、对数据的敬畏以及对细节的耐心。希望这篇文章能帮你少走一些弯路把宝贵的时间花在分析图书市场这件更有趣的事情上。
图书网站书评与销量排行爬取全流程解析
最近有个做图书出版的朋友问我怎么才能快速分析某个图书网站上的销量排行和书评口碑。他的需求很典型想做一个季度图书趋势报告但人工去翻榜单、抄评论、归档数据一整天也搞不定几十本。我说这类活儿完全可以交给脚本去做也就是圈里常说的“图书网站书评与销量排行爬取”。今天这篇文章我就把整套流程从头到尾拆开讲从字段设计、页面分析、代码实现到常见的踩坑点一次性说清楚。需要说明的是这篇文章里的思路和代码示例只适合抓取公开可访问的页面数据用于个人学习、学术研究和常规的市场观察。动手之前请一定先看一眼目标网站的robots.txt和服务条款合理控制请求频率不要碰任何需要登录才可见的信息更不要采集个人隐私数据。抱着一颗尊重规则的心去做数据采集才能走得远。1. 内容整体设计与思路拆解1.1 核心需求你到底要抓什么很多人一上来就问“怎么爬图书网站”其实这是个伪命题。图书网站的数据维度太多了榜单是一种数据书评是另一种数据详情页里还有作者、出版社、ISBN、出版时间、定价、内容简介甚至还有“XX人读过”“XX人想读”这类行为统计。如果不先想清楚最终要分析什么脚本写到一半就会变成一场灾难。以“书评与销量排行”这个标题为例核心需求至少可以拆成两个子目标销量排行数据通常来自网站首页或者图书频道页的榜单比如“销量榜”“热卖榜”“畅销榜TOP100”。这些榜单会给出图书名次、书名、作者、评论数、评分有时候还有价格。书评数据点进某本书的详情页可以看到读者长评一般包括评论标题、评论正文、评论者昵称、评分星级、评论时间、有用/无用点赞数。这部分数据才是做口碑分析的金矿。这里要特别提醒一点榜单上的“销量”是个模糊概念。很多图书网站并不直接显示销量数字而是给出“周榜第X名”“热卖指数”或者“加入购物车次数”。所以设计数据表的时候不要把“销量”写死成一个整数最好按“榜单类型排名指数值统计维度”来存储这样后续分析才有弹性。1.2 技术选型Requests够用Scrapy不背锅选型这件事我见过太多人一上来就上Scrapy最后被框架的Spider、Middleware、Pipeline绕得头晕。其实对于图书网站这种结构相对规整的页面requests lxml 的轻量组合已经足够应对大多数场景。我的建议是这样页面量在几千页以内、单机跑、需求快速验证直接用requestsparsel或lxml代码短、调试方便。页面量非常大、需要断点续爬、分布式调度再考虑Scrapy它的去重队列、自动重试、下载中间件确实能省不少事。页面内容由JavaScript动态渲染、接口数据藏在异步请求里先用浏览器的开发者工具看Network面板找到真正的JSON接口再用requests直接请求接口。实在找不到接口再考虑Playwright或Selenium做无头浏览器渲染。很多图书网站的榜单页是服务端直接渲染的HTML书评列表页也许是动态加载的评论接口。如果你一上来就开无头浏览器反而会让性能变得很差还容易被反爬策略盯上。正确做法是“静态优先、接口其次、渲染兜底”。1.3 数据存储先想清楚分析要什么爬虫项目最忌讳“先存下来再说”。图书网站的数据存进数据库之后你会发现同一个版本的图书可能有多个条目同一本书在榜单上可能同时出现在“总榜”和“分类榜”同一批书评里还有大量重复转载内容。所以采集之前务必先设计好表结构。我常用的表结构是这样的book_info图书信息表 id, title, author, publisher, isbn, pub_date, price, detail_url, created_at rank_info榜单记录表 id, book_id, rank_type, rank, score, rating_count, price, crawl_date review_info书评表 id, book_id, review_title, review_content, reviewer, review_rating, review_date, like_count, created_at注意rank_info表里加一个crawl_date字段这样你连续抓一周的榜单就能看出哪本书的排名在上升哪本书是“周榜冠军”而不是永远只保留一份最新的榜单快照。2. 核心细节解析与实操要点2.1 页面结构分析先当侦探再写代码在写任何一行代码之前建议你花半小时把目标页面从里到外摸一遍。打开榜单页按下F12重点看三样东西列表页中每本图书的HTML容器通常是一个li或者div里面包含书名、作者、评分等。找到这个容器节点后面的数据提取就顺了。每条数据的详情页URL排行榜页上一般都有“点击查看详情”的链接这个链接是后续进入详情页抓取书评的入口。书评列表的加载方式如果是翻页链接直接改URL参数就行。如果是“点击加载更多”并向后端发Ajax请求那就去Network面板里找到对应的XHR请求看它的请求参数和返回格式。我见过不少新手在详情页上栽跟头从榜单页提取到了书名和评分就以为大事搞定结果详情页的书评数据是异步加载的直接抓详情页HTML只能抓到“暂无评论”或者第一页。所以要养成习惯先看页面主题页面的完整结构再决定数据从哪个URL拿。2.2 字段设计别遗漏那些看起来不起眼的数据围绕“书评与销量排行”这个需求我建议每本书至少保留以下字段字段来源页面为什么需要书名榜单/详情页主键之一但注意同名书要结合作者区分作者榜单/详情页分析作者维度的销量表现出版社详情页分析出版社的畅销能力ISBN详情页唯一标识用于去重和后续关联出版时间详情页判断新书和老书价格榜单/详情页价格对销量影响很大榜单名次榜单页销量排行核心指标榜单类型榜单页总榜、分类榜、周榜、月榜评分榜单/详情页口碑的重要量化指标评论数榜单/详情页参与讨论的热度评论标题书评列表快速了解评论主题评论正文书评列表情感分析、话题提取的原料评论者昵称书评列表关注大V书评是否影响销量评论时间书评列表时间维度趋势分析有用数书评列表判断评论质量你可能觉得“价格”对销量排行分析没什么用但实际上通过价格区间和销量分布的交叉分析你能得出“百元以上的书在畅销榜占比逐年下降”这种非常有价值的结论。没有这些字段后面的分析就只能停留在“TOP1是哪本”这种表面信息上。2.3 反爬与礼貌抓取润物细无声图书网站的运营者也不傻榜单和书评是他们的内容资产不可能让你用脚本哗啦哗啦地白嫖。所以反爬是一个绕不开的话题。但反爬不等于去攻击对方而是要在合理范围内做到“不打扰、不激进、有退让”。我的经验是遵守三条原则请求间隔随机化不要用固定0.5秒的间隔建议在0.5到1.5秒之间随机sleep。固定间隔反而容易被识别为机器行为。设置合理的请求头带上完整的User-Agent、Accept、Accept-Language模拟浏览器环境。不要把爬虫的名字写在UA里更不要用什么“Hack”之类的UA。遇到封锁就立刻收手如果连续出现403、418、频繁跳验证码就把程序停下来等一段时间再跑而不是加大力度重试。这里想多说一句很多爬虫教程会让你去搞什么“隐藏IP”“突破验证码”我自己是不赞成把这些写进常规教程的。做数据分析的同学走正道也能拿到足够多的公开数据。真要大规模商用那就去走官方API或者商业数据合作渠道。3. 实操过程与核心环节实现3.1 用requests抓取榜单页并解析列表下面我写一个通用的示例流程以某个公开图书网站的榜单页为例。实际使用的时候请替换成你需要分析的目标网站。import requests import parsel import time import random headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.8 } def fetch_page(url): resp requests.get(url, headersheaders, timeout10) resp.raise_for_status() resp.encoding resp.apparent_encoding return resp.text def parse_rank_page(html): sel parsel.Selector(html) books [] # 这里的li.book-item是针对常见列表结构的示例实际站点请自行调整 for item in sel.css(li.book-item): title item.css(h3 a::text).get() detail_url item.css(h3 a::attr(href)).get() author item.css(p.author::text).get() rating item.css(span.rating::text).get() if title and detail_url: books.append({ title: title.strip(), detail_url: detail_url.strip(), author: author.strip() if author else , rating: rating.strip() if rating else }) return books写代码时最需要留意的就是CSS选择器是否正确。很多新手会选择抄别人的选择器换个网站就失效了。这里我建议你用浏览器开发者工具先复制一个元素的选择器然后在Python里打印前几条解析结果做核对再批量跑。3.2 详情页补全销量与书评入口榜单页只给了图书的基础信息关键的销量指标和书评数据大概率在详情页。所以下一步是遍历详情页URL把信息补全。注意这里的“销量指标”在不同网站长得不一样有的是直接显示“已售出X万件”有的是“热度值”还有的是“周榜第X名”。设计代码时最好把这些字段分离然后解析时做字符串清理def parse_detail_page(html): sel parsel.Selector(html) info {} info[publisher] sel.css(span.publisher::text).get() info[publish_date] sel.css(span.publish-date::text).get() info[isbn] sel.css(span.isbn::text).get() # 销量/热度值不同网站叫法不同这里随便取了一个示例类名 info[sales_indicator] sel.css(span.sales-num::text).get() info[rating_count] sel.css(span.rating-count::text).get() return info这里我想重点强调一个经验不要只抓一个详情页字段就去存库。因为详情页和榜单页可能出现字段重叠比如评分和评论数两边都有但数字可能不一致。榜单页的评分可能是四舍五入的详情页的评分可能更精确。所以我建议在存储时把来源字段也一并记录或者干脆统一以详情页为准避免数据分析时出现对不上账的情况。3.3 书评列表页的分页与解析书评列表通常是一个单独的频道或者TabURL往往长这样https://example.com/book/12345/review?page1每翻一页URL里的page参数就会加1。我们可以写一个循环来抓取前N页书评def parse_review_page(html): sel parsel.Selector(html) reviews [] for r in sel.css(div.review-item): reviews.append({ review_title: r.css(h4::text).get(), content: r.css(div.review-content::text).get(), reviewer: r.css(a.reviewer::text).get(), rating: r.css(span.review-rating::attr(title)).get(), review_date: r.css(span.review-date::text).get(), useful_count: r.css(span.useful-num::text).get(), }) return reviews def crawl_reviews(detail_url, max_pages10): all_reviews [] for page in range(1, max_pages 1): review_url detail_url.rstrip(/) f/review?page{page} html fetch_page(review_url) reviews parse_review_page(html) if not reviews: break all_reviews.extend(reviews) time.sleep(random.uniform(0.5, 1.2)) return all_reviews这里有个常见的坑有些书评列表页使用“评论按热度排序”和“按时间排序”两种维度默认是热度排序。同一批评论按时间翻页可能和按热度翻页的集合不一样。为了让数据口径一致建议固定一种排序方式并在数据记录里加上sort_type字段。3.4 存储与去重数据入库前的三道关卡等数据抓到本地后还得经过三道关卡才能入库清洗、转换、去重。清洗主要是处理缺失值和脏数据。比如评论正文里混入的HTML标签要用正则或者parsel再清理一遍价格字段里有“¥”和空格要转成浮点数评分字段如果是“五星”这种文本要映射成5或4.5。转换主要是统一数据格式。日期最好统一成YYYY-MM-DD时间戳统一为10位或13位数字。书名里的全角空格、作者里的多个作者分隔符也要统一。去重是数据质量的生命线。由于翻页和详情页可能重复采集建议对每条数据计算一个哈希指纹比如MD5(书名 评论者 评论时间 评论标题)。重复记录直接跳过。import hashlib def gen_fingerprint(title, reviewer, date, review_title): raw f{title}|{reviewer}|{date}|{review_title} return hashlib.md5(raw.encode(utf-8)).hexdigest()3.5 增量抓取下一次跑脚本不用全量重来如果你只是想跑一次上面的代码没问题。但如果你想每周追踪榜单变化、观察书评数增长那就必须做增量抓取。增量抓取的核心逻辑很简单每次抓取前先从数据库读取已抓过的detail_url集合。榜单页里遇到已经存在的URL时可以跳过详情页抓取只更新榜单排名和评分。书评列表页只抓取书评ID大于上次最大书评ID的新评论。当然很多网站的书评没有数字ID退而求其次用“评论时间大于上次采集时间 评论者不在已知集合”来过滤。增量逻辑虽然会增加代码量但能极大减少对目标站点的访问压力。你想想一本畅销书可能有上千条书评每周全量抓一次不仅慢也容易触发反爬。增量抓取是更专业、更可持续的做法。4. 常见问题与排查技巧实录4.1 常见错误速查表这段内容很啰嗦但真的很实用。我直接整理成表格方便你对照排查现象可能原因排查思路403 Forbidden请求头不完整或UA被识别补充Cookie、Referer降低请求频率418 Im a teapot被WAF识别为机器请求暂停程序换时间段再试不要暴力重试返回的HTML中没有目标元素页面是动态渲染或选择器写错查看Network里是否有XHR接口确认选择器是否匹配乱码页面编码不是UTF-8用resp.apparent_encoding动态识别编码评论只有第一页有数据评论列表是异步加载找XHR接口或者用Playwright渲染数据库里出现重复数据翻页/详情页数据交叉建立唯一索引或指纹去重某本书的ISBN抓不到部分条目确实没有ISBN置空处理不要丢弃整条记录请求到一半超时网络波动或对方限流增加重试机制设置指数退避4.2 反爬封锁的现场处理我在实际采集中有一次印象特别深。当时抓一个图书详情页请求频率也不算高每秒钟也就1次但跑到几百条之后突然开始出现“请通过人机验证”的页面。最开始我以为是频率太高把间隔调到了3秒结果还是一样。后来发现是同一个账号登录态导致的因为详情页里的推荐位会带上用户ID无登录态的请求反而更容易被识别。那次的解决方式很朴素换了一个公共网络出口清掉所有带用户ID的Cookie并且把程序改成随机暂停、运行时长短的批处理模式。也就是说每次跑到200条就停10分钟效果立竿见影。这里也再次强调我不建议大家去研究破解验证码或者绕过风控。遇到封锁就说明对方的访问策略触发了保护机制最好的方式就是降低访问烈度或者分时段慢慢抓。4.3 时间字段与数据口径的坑图书网站的书评时间经常会出现“3天前”“上周”“2024-05-01”这种混合格式。如果你直接存字符串后续按时间排序就会很痛苦。建议在清洗阶段把这些相对时间统一换算成绝对时间。如果是“3天前”这种就用datetime.now()往前推3天如果是“上周”就推到上一周的同一时刻。这个转换逻辑写起来比较烦但非常值得做。否则你后面做“近一个月书评数量变化趋势”时会发现数据全是残缺的。4.4 榜单类型与数据合并问题很多网站同时存在“总榜”“新书榜”“童书榜”“小说榜”等多套榜单。同一个详情页URL可能会出现在多个榜单里。如果你在存储时把榜单名次直接存在book_info表的某个字段中过几天再抓一次字段就会被覆盖掉。正确做法是像前面说的那样把榜单信息单独放到rank_info表每次抓取都新插一行记录。后续分析时你既能看“今天的总榜第一名”又能看“过去30天总榜前十里哪些书上升最快”。这就是结构设计带来的红利。5. 进一步扩展与经验分享5.1 从数据到结论几个有价值的分析角度抓完数据之后很多人就不知道下一步该干嘛了。如果把整个项目看成一条流水线爬虫只是最前端的原料采集后面的分析才是真正能产生价值的部分。我建议优先做这几个分析评分与销量排名的关系把评分分成5分以上、4到5分、3到4分等区间对比各区间在销量榜中的占比。你会发现有些高分冷门书永远进不了畅销榜而有些低分争议书却卖得不错这背后能引申出很多关于图书营销和读者心理的判断。书评情感倾向与销量涨跌用简单的情感词典或者现成的NLP库给书评打正负向标签然后按周聚合。如果某本书的负面评论比例突然上升下一周销量往往是下降的这种规律在出版行业很有参考价值。评论时间与出版周期的相关性新书发布后多长时间能达到书评量峰值峰值持续多久能帮你判断一本书的“热度曲线”。5.2 自动化与定时更新的工程化思考如果你不想每天手动跑一次脚本可以考虑用操作系统的定时任务来做。Windows下是“任务计划程序”macOS和Linux下是crontab。比如每天凌晨2点运行一次采集脚本然后自动把结果追加到数据库。# 每天凌晨2点执行采集脚本 0 2 * * * cd /path/to/project /usr/bin/python3 crawl.py logs/crawl.log 21这里提醒一个小细节定时任务跑出来的数据一定要写日志。日志里记录每次抓取的起始时间、成功条数、失败条数、异常类型。没有日志的定时任务一旦哪天数据抓漏了你根本不知道是网络问题、反爬问题还是接口改版。5.3 给新手的三个实用建议最后聊几点我踩过坑之后的体会。第一先不要追求完美先跑通一条链路。哪怕只抓一本图书详情页和它的10条书评也别急着一次抓10万条。先把数据从榜单页 - 详情页 - 书评页这个路径完整跑通确认每个字段都能对上再扩大规模。第二协议和频率的克制是对自己最大的保护。我见过太多人因为爬虫把目标网站惹毛最后连正常浏览器访问都被临时限制。图一时之快得不偿失。控制频率不仅是为了对方也是为了让自己的任务更持久。第三把代码写成可以重跑的样子。不要每次抓完就改一堆参数要把URL、字段、选择器、分页规则都配置化。这样过了一个月网站结构调整了你能快速定位哪里需要改。做图书网站的书评与销量排行抓取技术难度一点都不高但真正考验人的是对需求的拆解、对数据的敬畏以及对细节的耐心。希望这篇文章能帮你少走一些弯路把宝贵的时间花在分析图书市场这件更有趣的事情上。
