做图书类内容这几年我越来越频繁地需要一份书评口碑销量表现的交叉数据。无论是做选品分析、写推荐书单还是判断一本新书的营销效果单靠人工翻阅书评和销售页面效率都太低。于是就有了这个图书网站书评与销量排行爬取的小项目用Python把目标图书网站的书评内容、评分分布和销量排行抓下来清洗之后落到本地再做简单的聚合分析。这篇博文我会完整拆解这个项目从设计到落地的全过程包括为什么要这么选型、每一步怎么实现、以及我实际踩过的坑。内容更适合刚接触爬虫、想拿一个完整案例练手的Python开发者也适合需要批量拉取图书数据的运营、编辑和数据分析师参考。1. 项目整体设计与思路拆解1.1 这个项目到底要解决什么问题先说需求。图书网站的页面信息其实分三层列表页、详情页和评论数据。列表页能拿到书名、作者、出版社、定价和当前排名详情页能拿到更完整的出版信息、内容简介和总评分评论数据则分散在每条书评里包含星级、评论文本、评论时间和点赞数。我需要把这些数据拼成一张书评与销量排行的综合表核心目标有三个一是按销量维度看哪些书在持续走强二是按书评情感和评分看口碑是否撑得住销量三是把这两者结合起来找出卖得好但口碑差和口碑好但卖得少的异常样本。这类分析对选品和内容策划非常有用。1.2 技术选型为什么是requests而不是Scrapy很多新手一上来就纠结选什么框架。我的建议是情况不同选择不同。单拿这个项目来说数据量在几百到几千本书之间页面结构不算复杂用requests加BeautifulSoup完全够用代码直白、调试容易出了问题一眼就能看出来。Scrapy当然更强大自带并发调度、去重、中间件和Item Pipeline适合全站级、几万条数据以上的规模化采集。但它的学习曲线也在这Spider、Selector、Pipeline、Middleware一整套概念配置起来比小项目本身的代码量还多。我个人的经验是小项目先用requests跑通逻辑真到了需要扩展的时候再迁移Scrapy也不迟爬虫项目的核心永远在分析页面结构和处理反爬而不在框架本身。动态渲染的问题也要提前考虑。图书网站的商品列表和详情页多数是服务端渲染直接用requests就能拿到完整HTML但评论部分很多站点改成了前端异步加载数据藏在XHR接口的JSON里。这种情况我用Selenium兜底但我把Selenium定位成最后的备选方案因为它启动浏览器、加载页面的成本很高而且更容易被识别。优先找网页源码里的JSON接口才是正道。2. 核心细节解析与实操要点2.1 页面结构分析是第一步也是最容易偷懒的一步拿到一个图书网站别急着写代码。先用浏览器打开目标页面按F12进开发者工具切到Network面板刷新页面重点看两类请求文档类型的Document请求以及XHR/Fetch请求。如果评论内容出现在XHR请求的响应里说明是异步加载如果直接出现在HTML里就是服务端渲染。然后对着页面元素确认字段位置。我习惯在Elements面板里右键检查书名、评分、评论内容所在的节点把CSS路径记下来后面写选择器的时候会省很多事。举个例子一个典型的列表页结构大致长这样ul classbook-list li classbook-item a href/book/1001 classtitlePython数据分析实战/a span classauthor张三/span span classrating4.7分/span span classsales1.2万人付款/span /li ... /ul这个例子里书名、评分、销量都在同一个li节点下用CSS选择器可以一次定位。需要注意销量字段经常被写成XX人付款累计评价XX条这样的模糊口径抓下来之后要统一做归一化否则后面做排行排序会乱套。2.2 请求头伪装与反爬应对的实操套路反爬是绕不开的话题。图书电商类网站普遍会检查User-Agent、Referer和访问频率。我第一版脚本犯过很典型的错误直接用默认UA裸奔连续请求十几个页面之后服务器返回了一个验证码页面。所以从第一天开始就要养成伪装请求头的习惯。import requests HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/webp,*/*;q0.8, Accept-Language: zh-CN,zh;q0.8, Referer: https://books.example.com/, Connection: keep-alive, }UA要尽量接近真实浏览器的完整字符串光写个版本号很容易被识别。同时用requests的Session保持会话session requests.Session() session.headers.update(HEADERS) resp session.get(url, timeout10)请求频率是另一个关键。我实测下来单线程每秒不超过一次请求比较稳妥连续抓几百页的节奏每页之间time.sleep(1)到time.sleep(3)随机间隔。别小看这个延迟它直接决定你是顺利跑完还是跑到一半被限制。这里再补充一个细节Sleep的间隔最好用随机值固定间隔的模式反而容易被识别。2.3 评论数据的清洗与结构化抓下来的原始HTML文本不能直接用清洗是必须的环节。常见问题包括评论里嵌套了HTML标签、空评论和复制粘贴的重复评论、星级和评分的单位不统一、评论时间格式多种多样。我清洗的流程大致是先用BeautifulSoup提取文本并去除多余空白然后做空值过滤再按评论ID或内容哈希去重。评分方面我会统一转成5分制的浮点数比如4.5分转成4.5五星转成5.0。有用数则直接解析成整数方便后面按影响力排序。情感判断这里不搞复杂模型用评分映射加关键词初判就够了。比如3分以下算负面4分以上算正面中间算中性再叠加垃圾失望值得惊喜这类关键词微调。这种粗粒度情感标注虽然不如大模型精细但胜在快而且对聚合统计来说完全够用。3. 实操过程与核心环节实现3.1 环境准备与初始化我用Python 3.10venv建虚拟环境依赖只有四个requests、beautifulsoup4、lxml、pandas。SQLite用Python自带的sqlite3模块不额外装东西。安装命令一行搞定pip install requests beautifulsoup4 lxml pandas项目目录结构也很简单book_spider/ ├── spider.py # 主抓取脚本 ├── parser.py # 页面解析模块 ├── store.py # 数据落库模块 ├── config.py # 可配置参数 └── data/ └── books.db # SQLite数据库把抓取、解析、存储拆开是非常重要的习惯。这样换网站、换页面结构时只需要改parser.py不必动主流程。我见过太多人把几百行代码全堆在一个文件里最后改一个选择器都要翻半天。3.2 第一步抓取列表页并循环翻页列表页的URL通常带分页参数第一页长这样https://books.example.com/list?page1。先写一个基础抓取函数import time import requests def fetch_page(session, url): resp session.get(url, timeout10) resp.raise_for_status() resp.encoding resp.apparent_encoding return resp.textresp.encoding一定要处理。很多网站没声明charset直接解析中文会乱码用resp.apparent_encoding能根据内容自动推断编码实测下来对中文页面很稳。然后循环翻页。我一般先手动请求前三页确认总页数在页面里怎么体现再把循环写出来。控制逻辑很简单抓一页解析一页解析完成后立即落库不要攒到最后避免中途崩了全部丢失。BASE_URL https://books.example.com/list?page{page} for page in range(1, 26): # 假设总共25页 url BASE_URL.format(pagepage) html fetch_page(session, url) items parse_list(html) save_books(items) time.sleep(random.uniform(1, 3))这里有个细节解析完立即保存而不是累积。我第一批代码就是先抓完所有页面再统一写入数据库结果跑到第20页被限流前面19页的数据全在内存里虽然没丢但程序一断就全没了。改成边抓边存之后随时中断随时续跑安全感完全不同。3.3 第二步解析列表页提取书籍信息解析用BeautifulSoup加lxml解析器。lxml比Python自带的html.parser快不少处理大页面优势明显。选择器我偏向CSS选择器可读性好from bs4 import BeautifulSoup def parse_list(html): soup BeautifulSoup(html, lxml) items [] for li in soup.select(.book-list .book-item): title_node li.select_one(.title a) if not title_node: continue title title_node.get_text(stripTrue) detail_url title_node[href] if not detail_url.startswith(http): detail_url https://books.example.com detail_url items.append({ title: title, url: detail_url, author: get_text_safe(li, .author), rating: parse_rating(get_text_safe(li, .rating)), sales: parse_sales(get_text_safe(li, .sales)), }) return items def get_text_safe(node, selector): target node.select_one(selector) return target.get_text(stripTrue) if target else get_text_safe这种容错处理很有必要。一个列表有几十本书只要其中一本缺失某个字段直接取字段的代码就会抛异常。宁可返回空字符串也不让单条数据搞垮整个循环。解析销量、评分时我用独立的解析函数把1.2万人付款转成120004.7分转成4.7单位统一。3.4 第三步进入详情页抓取书评列表页拿到详情URL后再逐个访问详情页抓书评。这里要考虑请求量的放大25页列表约500本书每本书再抓一个详情页总共600个请求。按每请求间隔1到3秒算大约15到30分钟跑完算合理范围。详情页的书评部分优先找JSON接口。比如评论接口可能是https://books.example.com/book/1001/reviews?page1返回的是JSON解析更干净def fetch_reviews(session, book_url): book_id extract_book_id(book_url) reviews [] for page in range(1, 6): # 假设每本书取前5页评论 api_url fhttps://books.example.com/api/book/{book_id}/reviews?page{page} try: resp session.get(api_url, timeout10) data resp.json() except Exception: time.sleep(5) continue for item in data.get(comments, []): reviews.append({ book_id: book_id, content: clean_text(item.get(content, )), rating: float(item.get(score, 0)), useful: int(item.get(useful_count, 0)), time: item.get(create_time, ), }) time.sleep(random.uniform(1, 2)) return reviews如果找不到JSON接口就用BeautifulSoup直接解析HTML里的评论节点逻辑类似列表页解析。两条路线都一样要处理分页评论通常不止一页。这里分享一下抓不到评论时的排查顺序先在Network里确认评论请求的真实URL再看响应是HTML还是JSON确认数据结构后先手动请求一次把返回内容打印出来跟代码里的解析逻辑对照。九成的问题出在字段名对不上而不是请求失败。3.5 第四步数据落库与排行输出存储我选了SQLite单文件、零配置、查询方便。建表时给关键字段加约束防止重复数据import sqlite3 conn sqlite3.connect(data/books.db) conn.execute( CREATE TABLE IF NOT EXISTS books ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT UNIQUE, author TEXT, rating REAL, sales INTEGER, detail_url TEXT ) ) conn.execute( CREATE TABLE IF NOT EXISTS reviews ( id INTEGER PRIMARY KEY AUTOINCREMENT, book_id INTEGER, content TEXT, rating REAL, useful INTEGER, review_time TEXT ) ) conn.commit()title TEXT UNIQUE这个约束很关键。重复抓取时直接插入会报唯一性错误正好用异常捕获来跳过往数据实现最简单的增量更新。排行输出我用pandas做聚合。两个口径纯销量榜直接按sales降序综合口碑榜把评分和销量归一化后加权我实测下来评分权重0.6、销量权重0.4的效果比较合理。销量归一化就用最大最小归一化把原始销量映射到0到1之间再和同样归一化的评分加权求和。import pandas as pd df pd.read_sql(SELECT * FROM books, conn) df[sales_norm] (df[sales] - df[sales].min()) / (df[sales].max() - df[sales].min()) df[rating_norm] df[rating] / 5.0 df[score] df[rating_norm] * 0.6 df[sales_norm] * 0.4 df df.sort_values(score, ascendingFalse) print(df[[title, author, rating, sales, score]].head(20))再把每本书的书评平均情感分join进来就能看到销量排名和口碑排名的差异。这两列的差值是整个分析里最有价值的产出畅销榜前列但口碑垫底的书往往就是可以重点写文章拆解的对象。4. 常见问题与排查技巧实录4.1 被反爬限制时怎么判断和处理我把它视为爬虫项目的必修课。最常见的信号有三个一是某个时间点之后所有请求都返回403或418状态码二是返回页面里出现验证码相关关键词三是返回200但页面内容变成登录跳转页或空模板。遇到这些问题第一步不是堆代理和伪装而是先停手分析触发的边界。我的排查顺序先确认是不是单IP请求过快把间隔拉大到5秒以上再试探确认不是频率问题后检查请求头是否完整Cookie是否需要先访问首页获取最后才考虑更换IP这类更重的方案。在这个项目里把间隔控制在合理范围内、伪装好请求头基本就能跑完全程不需要上更复杂的对抗手段。4.2 动态加载的数据抓不到怎么办前面提过优先找JSON接口。判断方法很简单在页面上拉到评论区然后刷新页面观察Network里新增了哪些XHR请求那里面往往就是评论数据的真实来源。复制接口URL在浏览器新标签页打开如果返回纯JSON直接请求这个URL就行。实在找不到接口时再上Selenium。我用它的套路是给浏览器设置无头模式、加载固定的UA、等待关键元素出现后再提取页面源码。下面是一个最小可用版本from selenium import webdriver from selenium.webdriver.chrome.options import Options options Options() options.add_argument(--headless) options.add_argument(--disable-gpu) options.add_argument(user-agentMozilla/5.0 ...) driver webdriver.Chrome(optionsoptions) driver.get(https://books.example.com/book/1001) html driver.page_source driver.quit()Selenium慢是慢了点但应对那些必须浏览器执行JS才能渲染的页面它确实是最可靠的后备方案。注意用完之后要及时quit()开着的浏览器进程多了会拖垮本机。4.3 数据去重与增量更新的经验增量更新不需要复杂方案。我用的策略就是依靠数据库唯一约束插入时捕获异常即可def save_books(items): for item in items: try: conn.execute( INSERT INTO books (title, author, rating, sales, detail_url) VALUES (?, ?, ?, ?, ?), (item[title], item[author], item[rating], item[sales], item[url]) ) except sqlite3.IntegrityError: pass # 标题已存在跳过 conn.commit()这个方案有个隐藏问题如果一本书的销量或评分后来变了这条重复数据不会被更新。解决方法是再加一条更新逻辑捕获唯一性错误后改为执行UPDATE把变异了的字段刷新。这也是数据采集里很常见的一个坑抓取脚本跑了几轮数据却停留在第一轮的样子。4.4 一个容易被忽略的细节断点续跑爬虫跑一半断了是常态别指望它一次成功。我的做法是在循环里记录当前进度抓完一页就在本地存一个进度文件下次启动时读取进度从断点继续。这个小习惯能为你节省大量重跑时间。尤其是在抓评论这种请求量翻倍的任务里从头重跑不仅慢而且增加被限制的风险。5. 合规边界与运行建议5.1 爬虫的合规红线要心里有数爬虫领域的合规问题必须重视。个人学习研究和小规模采集是一回事大规模商业化抓取是另一回事。做这个项目时我给自己定了几个明确原则严格遵守目标网站的robots.txt规则控制请求频率不对网站服务器造成压力只采集公开可见的数据不碰需要登录才能访问的内容更不碰个人隐私字段。书评虽然挂在公开页面但涉及具体的用户昵称、头像、个人主页链接时我在落库之前都会把这类字段去掉。做数据分析需要的是评论文本和评分不需要知道是谁写的。这个习惯让我用完数据后没有心理负担也避免了很多潜在麻烦。5.2 个人学习项目的数据量控制我建议这类学习项目把数据量控制在千条级别。做到能跑通完整流程、能产出分析结论就够了没必要追求全量。我见过有人为了学习把整个网站几百万条评论全抓下来结果不仅给对方服务器造成压力自己也被封了IP。练习项目练习的是思路和方法不是数据规模。另外一个建议是尽量构造自己的本地测试页面去练手或者使用那些明确允许抓取的开放数据源。技术原理都是一样的但合规风险完全不同。等流程完全跑通了再面对真实网站时你的思路会更清晰操作也会更克制。最后再分享一点个人体会这个项目最大的收获不是代码本身而是从需求到数据的完整链路意识。我后来复盘时发现真正花时间的不是写爬虫而是定义清楚什么是口碑好、什么是销量高、两者的权重怎么定。数据口径没想清楚抓得再快都是白费。如果你也想做类似的项目我建议你动手前先花半小时把输出表格的字段定义写明白这会让你后面的爬取目标清晰很多。小技巧最后送给你把脚本里的目标URL、翻页范围、请求延迟全部抽到config.py里做成可配置项下次换任何图书网站只需改配置文件就能复用同一套代码。这个细节帮我节省了大量重复劳动也让这个爬虫项目从一次性脚本变成了可长期使用的工具。
Python爬虫实战：图书网站书评与销量排行数据抓取全攻略
做图书类内容这几年我越来越频繁地需要一份书评口碑销量表现的交叉数据。无论是做选品分析、写推荐书单还是判断一本新书的营销效果单靠人工翻阅书评和销售页面效率都太低。于是就有了这个图书网站书评与销量排行爬取的小项目用Python把目标图书网站的书评内容、评分分布和销量排行抓下来清洗之后落到本地再做简单的聚合分析。这篇博文我会完整拆解这个项目从设计到落地的全过程包括为什么要这么选型、每一步怎么实现、以及我实际踩过的坑。内容更适合刚接触爬虫、想拿一个完整案例练手的Python开发者也适合需要批量拉取图书数据的运营、编辑和数据分析师参考。1. 项目整体设计与思路拆解1.1 这个项目到底要解决什么问题先说需求。图书网站的页面信息其实分三层列表页、详情页和评论数据。列表页能拿到书名、作者、出版社、定价和当前排名详情页能拿到更完整的出版信息、内容简介和总评分评论数据则分散在每条书评里包含星级、评论文本、评论时间和点赞数。我需要把这些数据拼成一张书评与销量排行的综合表核心目标有三个一是按销量维度看哪些书在持续走强二是按书评情感和评分看口碑是否撑得住销量三是把这两者结合起来找出卖得好但口碑差和口碑好但卖得少的异常样本。这类分析对选品和内容策划非常有用。1.2 技术选型为什么是requests而不是Scrapy很多新手一上来就纠结选什么框架。我的建议是情况不同选择不同。单拿这个项目来说数据量在几百到几千本书之间页面结构不算复杂用requests加BeautifulSoup完全够用代码直白、调试容易出了问题一眼就能看出来。Scrapy当然更强大自带并发调度、去重、中间件和Item Pipeline适合全站级、几万条数据以上的规模化采集。但它的学习曲线也在这Spider、Selector、Pipeline、Middleware一整套概念配置起来比小项目本身的代码量还多。我个人的经验是小项目先用requests跑通逻辑真到了需要扩展的时候再迁移Scrapy也不迟爬虫项目的核心永远在分析页面结构和处理反爬而不在框架本身。动态渲染的问题也要提前考虑。图书网站的商品列表和详情页多数是服务端渲染直接用requests就能拿到完整HTML但评论部分很多站点改成了前端异步加载数据藏在XHR接口的JSON里。这种情况我用Selenium兜底但我把Selenium定位成最后的备选方案因为它启动浏览器、加载页面的成本很高而且更容易被识别。优先找网页源码里的JSON接口才是正道。2. 核心细节解析与实操要点2.1 页面结构分析是第一步也是最容易偷懒的一步拿到一个图书网站别急着写代码。先用浏览器打开目标页面按F12进开发者工具切到Network面板刷新页面重点看两类请求文档类型的Document请求以及XHR/Fetch请求。如果评论内容出现在XHR请求的响应里说明是异步加载如果直接出现在HTML里就是服务端渲染。然后对着页面元素确认字段位置。我习惯在Elements面板里右键检查书名、评分、评论内容所在的节点把CSS路径记下来后面写选择器的时候会省很多事。举个例子一个典型的列表页结构大致长这样ul classbook-list li classbook-item a href/book/1001 classtitlePython数据分析实战/a span classauthor张三/span span classrating4.7分/span span classsales1.2万人付款/span /li ... /ul这个例子里书名、评分、销量都在同一个li节点下用CSS选择器可以一次定位。需要注意销量字段经常被写成XX人付款累计评价XX条这样的模糊口径抓下来之后要统一做归一化否则后面做排行排序会乱套。2.2 请求头伪装与反爬应对的实操套路反爬是绕不开的话题。图书电商类网站普遍会检查User-Agent、Referer和访问频率。我第一版脚本犯过很典型的错误直接用默认UA裸奔连续请求十几个页面之后服务器返回了一个验证码页面。所以从第一天开始就要养成伪装请求头的习惯。import requests HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/webp,*/*;q0.8, Accept-Language: zh-CN,zh;q0.8, Referer: https://books.example.com/, Connection: keep-alive, }UA要尽量接近真实浏览器的完整字符串光写个版本号很容易被识别。同时用requests的Session保持会话session requests.Session() session.headers.update(HEADERS) resp session.get(url, timeout10)请求频率是另一个关键。我实测下来单线程每秒不超过一次请求比较稳妥连续抓几百页的节奏每页之间time.sleep(1)到time.sleep(3)随机间隔。别小看这个延迟它直接决定你是顺利跑完还是跑到一半被限制。这里再补充一个细节Sleep的间隔最好用随机值固定间隔的模式反而容易被识别。2.3 评论数据的清洗与结构化抓下来的原始HTML文本不能直接用清洗是必须的环节。常见问题包括评论里嵌套了HTML标签、空评论和复制粘贴的重复评论、星级和评分的单位不统一、评论时间格式多种多样。我清洗的流程大致是先用BeautifulSoup提取文本并去除多余空白然后做空值过滤再按评论ID或内容哈希去重。评分方面我会统一转成5分制的浮点数比如4.5分转成4.5五星转成5.0。有用数则直接解析成整数方便后面按影响力排序。情感判断这里不搞复杂模型用评分映射加关键词初判就够了。比如3分以下算负面4分以上算正面中间算中性再叠加垃圾失望值得惊喜这类关键词微调。这种粗粒度情感标注虽然不如大模型精细但胜在快而且对聚合统计来说完全够用。3. 实操过程与核心环节实现3.1 环境准备与初始化我用Python 3.10venv建虚拟环境依赖只有四个requests、beautifulsoup4、lxml、pandas。SQLite用Python自带的sqlite3模块不额外装东西。安装命令一行搞定pip install requests beautifulsoup4 lxml pandas项目目录结构也很简单book_spider/ ├── spider.py # 主抓取脚本 ├── parser.py # 页面解析模块 ├── store.py # 数据落库模块 ├── config.py # 可配置参数 └── data/ └── books.db # SQLite数据库把抓取、解析、存储拆开是非常重要的习惯。这样换网站、换页面结构时只需要改parser.py不必动主流程。我见过太多人把几百行代码全堆在一个文件里最后改一个选择器都要翻半天。3.2 第一步抓取列表页并循环翻页列表页的URL通常带分页参数第一页长这样https://books.example.com/list?page1。先写一个基础抓取函数import time import requests def fetch_page(session, url): resp session.get(url, timeout10) resp.raise_for_status() resp.encoding resp.apparent_encoding return resp.textresp.encoding一定要处理。很多网站没声明charset直接解析中文会乱码用resp.apparent_encoding能根据内容自动推断编码实测下来对中文页面很稳。然后循环翻页。我一般先手动请求前三页确认总页数在页面里怎么体现再把循环写出来。控制逻辑很简单抓一页解析一页解析完成后立即落库不要攒到最后避免中途崩了全部丢失。BASE_URL https://books.example.com/list?page{page} for page in range(1, 26): # 假设总共25页 url BASE_URL.format(pagepage) html fetch_page(session, url) items parse_list(html) save_books(items) time.sleep(random.uniform(1, 3))这里有个细节解析完立即保存而不是累积。我第一批代码就是先抓完所有页面再统一写入数据库结果跑到第20页被限流前面19页的数据全在内存里虽然没丢但程序一断就全没了。改成边抓边存之后随时中断随时续跑安全感完全不同。3.3 第二步解析列表页提取书籍信息解析用BeautifulSoup加lxml解析器。lxml比Python自带的html.parser快不少处理大页面优势明显。选择器我偏向CSS选择器可读性好from bs4 import BeautifulSoup def parse_list(html): soup BeautifulSoup(html, lxml) items [] for li in soup.select(.book-list .book-item): title_node li.select_one(.title a) if not title_node: continue title title_node.get_text(stripTrue) detail_url title_node[href] if not detail_url.startswith(http): detail_url https://books.example.com detail_url items.append({ title: title, url: detail_url, author: get_text_safe(li, .author), rating: parse_rating(get_text_safe(li, .rating)), sales: parse_sales(get_text_safe(li, .sales)), }) return items def get_text_safe(node, selector): target node.select_one(selector) return target.get_text(stripTrue) if target else get_text_safe这种容错处理很有必要。一个列表有几十本书只要其中一本缺失某个字段直接取字段的代码就会抛异常。宁可返回空字符串也不让单条数据搞垮整个循环。解析销量、评分时我用独立的解析函数把1.2万人付款转成120004.7分转成4.7单位统一。3.4 第三步进入详情页抓取书评列表页拿到详情URL后再逐个访问详情页抓书评。这里要考虑请求量的放大25页列表约500本书每本书再抓一个详情页总共600个请求。按每请求间隔1到3秒算大约15到30分钟跑完算合理范围。详情页的书评部分优先找JSON接口。比如评论接口可能是https://books.example.com/book/1001/reviews?page1返回的是JSON解析更干净def fetch_reviews(session, book_url): book_id extract_book_id(book_url) reviews [] for page in range(1, 6): # 假设每本书取前5页评论 api_url fhttps://books.example.com/api/book/{book_id}/reviews?page{page} try: resp session.get(api_url, timeout10) data resp.json() except Exception: time.sleep(5) continue for item in data.get(comments, []): reviews.append({ book_id: book_id, content: clean_text(item.get(content, )), rating: float(item.get(score, 0)), useful: int(item.get(useful_count, 0)), time: item.get(create_time, ), }) time.sleep(random.uniform(1, 2)) return reviews如果找不到JSON接口就用BeautifulSoup直接解析HTML里的评论节点逻辑类似列表页解析。两条路线都一样要处理分页评论通常不止一页。这里分享一下抓不到评论时的排查顺序先在Network里确认评论请求的真实URL再看响应是HTML还是JSON确认数据结构后先手动请求一次把返回内容打印出来跟代码里的解析逻辑对照。九成的问题出在字段名对不上而不是请求失败。3.5 第四步数据落库与排行输出存储我选了SQLite单文件、零配置、查询方便。建表时给关键字段加约束防止重复数据import sqlite3 conn sqlite3.connect(data/books.db) conn.execute( CREATE TABLE IF NOT EXISTS books ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT UNIQUE, author TEXT, rating REAL, sales INTEGER, detail_url TEXT ) ) conn.execute( CREATE TABLE IF NOT EXISTS reviews ( id INTEGER PRIMARY KEY AUTOINCREMENT, book_id INTEGER, content TEXT, rating REAL, useful INTEGER, review_time TEXT ) ) conn.commit()title TEXT UNIQUE这个约束很关键。重复抓取时直接插入会报唯一性错误正好用异常捕获来跳过往数据实现最简单的增量更新。排行输出我用pandas做聚合。两个口径纯销量榜直接按sales降序综合口碑榜把评分和销量归一化后加权我实测下来评分权重0.6、销量权重0.4的效果比较合理。销量归一化就用最大最小归一化把原始销量映射到0到1之间再和同样归一化的评分加权求和。import pandas as pd df pd.read_sql(SELECT * FROM books, conn) df[sales_norm] (df[sales] - df[sales].min()) / (df[sales].max() - df[sales].min()) df[rating_norm] df[rating] / 5.0 df[score] df[rating_norm] * 0.6 df[sales_norm] * 0.4 df df.sort_values(score, ascendingFalse) print(df[[title, author, rating, sales, score]].head(20))再把每本书的书评平均情感分join进来就能看到销量排名和口碑排名的差异。这两列的差值是整个分析里最有价值的产出畅销榜前列但口碑垫底的书往往就是可以重点写文章拆解的对象。4. 常见问题与排查技巧实录4.1 被反爬限制时怎么判断和处理我把它视为爬虫项目的必修课。最常见的信号有三个一是某个时间点之后所有请求都返回403或418状态码二是返回页面里出现验证码相关关键词三是返回200但页面内容变成登录跳转页或空模板。遇到这些问题第一步不是堆代理和伪装而是先停手分析触发的边界。我的排查顺序先确认是不是单IP请求过快把间隔拉大到5秒以上再试探确认不是频率问题后检查请求头是否完整Cookie是否需要先访问首页获取最后才考虑更换IP这类更重的方案。在这个项目里把间隔控制在合理范围内、伪装好请求头基本就能跑完全程不需要上更复杂的对抗手段。4.2 动态加载的数据抓不到怎么办前面提过优先找JSON接口。判断方法很简单在页面上拉到评论区然后刷新页面观察Network里新增了哪些XHR请求那里面往往就是评论数据的真实来源。复制接口URL在浏览器新标签页打开如果返回纯JSON直接请求这个URL就行。实在找不到接口时再上Selenium。我用它的套路是给浏览器设置无头模式、加载固定的UA、等待关键元素出现后再提取页面源码。下面是一个最小可用版本from selenium import webdriver from selenium.webdriver.chrome.options import Options options Options() options.add_argument(--headless) options.add_argument(--disable-gpu) options.add_argument(user-agentMozilla/5.0 ...) driver webdriver.Chrome(optionsoptions) driver.get(https://books.example.com/book/1001) html driver.page_source driver.quit()Selenium慢是慢了点但应对那些必须浏览器执行JS才能渲染的页面它确实是最可靠的后备方案。注意用完之后要及时quit()开着的浏览器进程多了会拖垮本机。4.3 数据去重与增量更新的经验增量更新不需要复杂方案。我用的策略就是依靠数据库唯一约束插入时捕获异常即可def save_books(items): for item in items: try: conn.execute( INSERT INTO books (title, author, rating, sales, detail_url) VALUES (?, ?, ?, ?, ?), (item[title], item[author], item[rating], item[sales], item[url]) ) except sqlite3.IntegrityError: pass # 标题已存在跳过 conn.commit()这个方案有个隐藏问题如果一本书的销量或评分后来变了这条重复数据不会被更新。解决方法是再加一条更新逻辑捕获唯一性错误后改为执行UPDATE把变异了的字段刷新。这也是数据采集里很常见的一个坑抓取脚本跑了几轮数据却停留在第一轮的样子。4.4 一个容易被忽略的细节断点续跑爬虫跑一半断了是常态别指望它一次成功。我的做法是在循环里记录当前进度抓完一页就在本地存一个进度文件下次启动时读取进度从断点继续。这个小习惯能为你节省大量重跑时间。尤其是在抓评论这种请求量翻倍的任务里从头重跑不仅慢而且增加被限制的风险。5. 合规边界与运行建议5.1 爬虫的合规红线要心里有数爬虫领域的合规问题必须重视。个人学习研究和小规模采集是一回事大规模商业化抓取是另一回事。做这个项目时我给自己定了几个明确原则严格遵守目标网站的robots.txt规则控制请求频率不对网站服务器造成压力只采集公开可见的数据不碰需要登录才能访问的内容更不碰个人隐私字段。书评虽然挂在公开页面但涉及具体的用户昵称、头像、个人主页链接时我在落库之前都会把这类字段去掉。做数据分析需要的是评论文本和评分不需要知道是谁写的。这个习惯让我用完数据后没有心理负担也避免了很多潜在麻烦。5.2 个人学习项目的数据量控制我建议这类学习项目把数据量控制在千条级别。做到能跑通完整流程、能产出分析结论就够了没必要追求全量。我见过有人为了学习把整个网站几百万条评论全抓下来结果不仅给对方服务器造成压力自己也被封了IP。练习项目练习的是思路和方法不是数据规模。另外一个建议是尽量构造自己的本地测试页面去练手或者使用那些明确允许抓取的开放数据源。技术原理都是一样的但合规风险完全不同。等流程完全跑通了再面对真实网站时你的思路会更清晰操作也会更克制。最后再分享一点个人体会这个项目最大的收获不是代码本身而是从需求到数据的完整链路意识。我后来复盘时发现真正花时间的不是写爬虫而是定义清楚什么是口碑好、什么是销量高、两者的权重怎么定。数据口径没想清楚抓得再快都是白费。如果你也想做类似的项目我建议你动手前先花半小时把输出表格的字段定义写明白这会让你后面的爬取目标清晰很多。小技巧最后送给你把脚本里的目标URL、翻页范围、请求延迟全部抽到config.py里做成可配置项下次换任何图书网站只需改配置文件就能复用同一套代码。这个细节帮我节省了大量重复劳动也让这个爬虫项目从一次性脚本变成了可长期使用的工具。
