用Python抓取淘宝京东评论，SnowNLP情感分析实战

简介：这是一套面向毕业设计及期末大作业场景的Python综合项目资料，聚焦淘宝、京东商品数据爬取与评论情感分析，适用于具备一定Python基础、希望完成完整课程项目或毕设系统的学习者。资源共103个文件，包含py源码、csv数据集、jpg/png图表与可视化结果、xml配置、说明文档及lstm模型文件等，压缩包大小约55.57MB，目录划分清晰，便于按数据采集、情感建模、结果展示等模块查阅。源码经本地编译运行通过，评审评分达95分以上，项目难度适中，内容经过助教审定，适合直接参考或二次扩展。附带中文商品评论、电商评论等多份csv数据，以及模型与驱动文件，可支撑从爬虫采集、评论预处理到情感分析、可视化输出的完整流程。已有219人学习下载，可用于理解真实电商评论分析任务并快速搭建可演示系统。

1. 把淘宝、京东评论抓下来做情感分析：这套毕设源码是怎么跑通的

做电商评论分析时，最耗时间的环节通常不是情感分析算法，而是数据从哪来。Python 淘宝、京东爬虫要面对淘宝的签名校验、京东频繁变化的分页参数，很多毕业设计卡在这一步，拿着现成的模型却喂不上数据。这套源码把商品数据抓取、评论抓取、数据清洗和情感分析串成了一条完整链路，我按毕业设计评审的眼光把压缩包里的文件重新跑了一遍，发现能拆开讲的东西不少。项目定位是本科毕设难度，适合正在做电商数据分析、评论情感分析大作业的同学，也适合想快速拿到一套能跑通的代码、再按自己的需求改的从业者。下面按实际使用顺序，讲数据文件结构、爬虫实现、情感分析逻辑和几个容易翻车的点。

2. 先理清楚 CSV 再谈算法：文件结构、字段口径与合并策略

解压这套源码之后，压缩包里不是只有一个 .py 文件，而是一堆 CSV：online_shopping_10_cats.csv、TBdata.csv、JDdata1688264584.7149756.csv、JDdata.csv，还有一群以商品 ID 命名的 comments.csv。第一次看到这些文件的人很容易犯的错，是随便找个 CSV 就开读，读出来的东西又看不懂。实际上它们并不是随便堆在一起的，而是「商品索引 → 商品数据 → 评论明细 → 清洗结果」这条数据链路的中间产物。先把文件的用途归类，再决定从哪一个入口跑分析，后面会少踩很多坑。

2.1 用一段通用脚本先探明所有 CSV 的字段

处理 CSV 的第一个坑是编码。这套源码里至少会混着 utf-8 和 gbk 两种文件，拿到文件后直接pd.read_csv("xxx.csv")大概率会撞上 UnicodeDecodeError。写一个带编码回退的 loader，把所有文件先扫一遍，比用 Excel 逐个点开要快得多。

import pandas as pd import glob def load_csv(path, max_rows=None): """带编码回退的读取，覆盖 utf-8 / gbk / gb18030 三种常见编码。""" for enc in ("utf-8", "gbk", "gb18030"): try: return pd.read_csv(path, encoding=enc, nrows=max_rows) except (UnicodeDecodeError, UnicodeError): continue raise ValueError(f"无法解码文件: {path}") for path in sorted(glob.glob("*.csv")): df = load_csv(path, max_rows=5) print(f"[{path}] 列名: {list(df.columns)}") print(f"行数预览: {len(df)}") print(df.head(2).to_string(index=False)) print("-" * 60)

这段脚本做的事情很直接：glob 先把目录下所有 CSV 捞出来，load_csv对每个文件依次尝试 utf-8、gbk、gb18030 三种编码，只读前 5 行用于看结构。max_rows=5是故意传给 read_csv 的，目的是避免哪个文件特别大时一次性读进内存。跑完这份脚本，每个文件的列名和字段形状就在控制台里摆着，接下来再谈用什么字段做分析，心里就有底了。

从脚本输出能看出文件大致分成四类：

这种分层组织在毕设项目里很常见，好处是每个模块各管一段：爬虫产出商品表和评论表，清洗脚本产出合并数据，最后分析代码只需要对接 data.csv 或中文商品评论.csv，不会因为一个环节出错把整条链路全部拖垮。JDdata 后面的长数字是爬取时点的 unix 时间戳，不是乱码，这点先记住，免得以为文件损坏。

2.2 商品表与评论表怎么关联：主键口径要提前统一

接下来是把商品和评论两层数据关联起来。最容易踩的坑是类型不一致：淘宝商品 ID 是一串纯数字，如果商品表里这列是字符串，评论表里却是整数，merge 时两边互相匹配不上，最后得到的大表会出现大量空值，甚至行数膨胀。

tb = load_csv("TBdata.csv") comments = load_csv("中文商品评论.csv") # 统一主键类型，避免长数字被读成科学计数法或浮点数 tb["key"] = tb["商品ID"].astype(str).str.strip() comments["key"] = comments["item_id"].astype(str).str.strip() merged = comments.merge(tb, on="key", how="left", suffixes=("", "_商品")) print(merged.shape) print(merged.head())

把主键统一成字符串再关联，是处理这类数据最保险的做法。astype(str)可以把数字列无损转成字符串，str.strip()顺手清掉可能混进来的空格。merge 的on指定关联键，how="left"表示以评论表为主表，评论里每条数据都保留，商品表匹配上的带过来，匹配不上的字段变成 NaN。suffixes区分两边重复的列名，比如评论表有“价格”，商品表也有“价格”，后者会自动变成“价格_商品”，避免列名互相覆盖。

关联之前，有两类重复数据必须处理：评论表可能因为翻页抓了一次又一次，商品表也可能在多次任务里重复入库。不处理就 merge，行数会成倍增长，后面的统计全是错的。我一般会在关联前先单独去重，再用清洗过的表做合并。

comments = comments.drop_duplicates(subset=["key", "content"]) tb = tb.drop_duplicates(subset=["key"])

评论表按“商品 ID + 评论内容”去重，意思是两条内容完全一样的记录才会被删掉；商品表按商品 ID 去重就行。这是合并链路里成本最低的一步，但效果非常明显：关联之后的行数、情感分析结果的分布，都会干净很多。合并完成后，情感分析就只需要在 merged 表上操作，后续按商品 ID 分组统计正负向数量，按品类聚合看整体情绪，都不需要再去翻原始评论文件。

3. 爬虫模块的实现套路：Cookie 保持、分页参数与落盘去重

CSV 里的数据不会凭空出现，它们是爬虫跑出来的。这套源码的爬虫部分核心其实不复杂：用 requests 保持会话，把浏览器里的登录态搬运过来，再按平台的分页规则拉评论。淘宝和京东的评论接口策略不同，淘宝那边有签名参数，京东的接口对常见参数更友好，但两者共同的问题是都会被风控。所以爬虫模块里最常见的两个方案是：轻量用 requests，重一点用 Selenium。

3.1 用 requests 维持会话拉京东评论：Cookie、Header 与分页参数

京东的评论接口是标准 JSON 返回，参数结构清晰，适合做第一版爬虫。接口地址是 club.jd.com 域名下的 productPageComments.action，直接返回评论列表、评论总数、好评率等字段。请求时只需要带上商品 ID、页码和分页大小。

import requests import time import pandas as pd session = requests.Session() session.headers.update({ "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 " "Chrome/120.0 Safari/537.36", "Referer": "https://item.jd.com/10055368660713.html", "Cookie": "这里换成你浏览器里复制的整段Cookie", }) URL = "https://club.jd.com/comment/productPageComments.action" def fetch_jd_comments(sku_id, page, page_size=10): params = { "productId": sku_id, "score": "0", # 0=全部评价，1=好评，2=中评，3=差评 "sortType": "6", # 6表示按时间倒序 "page": page, # 页码从0开始，不是1 "pageSize": page_size, # 每页数量，建议不超过20 } for attempt in range(3): try: resp = session.get(URL, params=params, timeout=5) resp.raise_for_status() data = resp.json() return data, data.get("comments") or [] except requests.RequestException as e: print(f"第 {attempt+1} 次请求失败: {e}") time.sleep(1 + attempt * 2) return None, []

这里几个关键参数要解释。score=0表示不分星级直接抓全部评价，后续想只看差评时把 score 改成 3 就行。sortType=6是按时间倒序，能确保每次拉到的都是最新评论，不至于在翻页过程中数据大量重复。page从 0 开始是京东的惯例，跟网页前端一致，翻页时把 page 加 1。pageSize默认 10，可以改成 20，但不建议再大，单页返回的数据量一旦超过服务端阈值，很容易触发风控。timeout=5秒和 3 次重试，是给网络抖动留的余量，一个页面请求失败不会让整个任务中断。

拿到数据后要把它攒成列表再落盘。循环翻页的写法一般是这样：

all_comments = [] for page in range(0, 10): data, comments = fetch_jd_comments("10055368660713", page, page_size=20) if not comments: break all_comments.extend(comments) time.sleep(0.5) print(len(all_comments))

这里每一页之间 sleep 0.5 秒，是低频率抓取的做法，也是爬虫代码里最容易被人忽视的地方。抓评论是为了把样本拿全，节奏放慢反而让后续页码上的数据更完整。等 comments 为空时说明已经翻到最后一页，直接 break 跳出循环。

3.2 淘宝侧的处理方式：用浏览器环境取 Cookie，别硬刚签名

淘宝的评论接口不能照搬京东这套直接请求成功，它带一个随前端版本变化的签名参数，纯 requests 会话很难长期维护。源码里更常见的做法是先用 Selenium 打开浏览器并登录淘宝，把浏览器里的 Cookie 取出来，交给 requests 去请求评论接口。登录这类操作只做一次，后面全部复用这个会话。

from selenium import webdriver from selenium.webdriver.chrome.options import Options options = Options() options.add_argument("--headless=new") options.add_argument("--disable-gpu") options.add_argument("--no-sandbox") options.add_argument("--window-size=1280,800") driver = webdriver.Chrome(options=options) driver.get("https://login.taobao.com/") # 这里可以配合手动扫码，也可以在已有登录态的环境里打开任意商品页 cookie_text = "; ".join(f"{c['name']}={c['value']}" for c in driver.get_cookies()) print(cookie_text) driver.quit()

这段代码的目的是拿到会话 Cookie，不是真正的爬取动作。headless模式让浏览器在后台运行，disable-gpu和no-sandbox是常见参数，避免部分服务器环境下 Chrome 启动崩溃。driver.get_cookies()取到的是浏览器当前的 Cookie 列表，把它们拼接成name=value; name2=value2的格式输出，扔给 3.1 节创建的 session 即可。注意这段 Cookie 必须用自己电脑上的，自己扫一次码、自己导出，才能保证接口拿的是自己的登录态。

为什么淘宝不继续用纯 requests 模拟登录？因为登录时的加密逻辑涉及动态参数，在毕业设计的时间窗口里反复维护收益太低。用浏览器环境拿到会话，相当于让浏览器替我们把最麻烦的部分处理掉，requests 只需要专注翻页和解析，这套分工在毕设项目里是性价比最高的。

提示：Selenium 方式需要本机已装 Chrome 及匹配版本的 chromedriver，压缩包里的 LICENSE.chromedriver 文件提示的就是这一环。版本不匹配时浏览器会直接打不开，或者报 session not created。

3.3 抓完直接落盘：编码统一、去重和文件名规范化

无论从哪个平台抓下来，评论数据最终都要变成 CSV，否则情感分析模块没法统一对接。常见的存法是把每个商品的评论单独存成一个文件，文件名用商品 ID，方便后来按商品维度去分析。

import os def save_comments(sku_id, rows, folder="comments"): os.makedirs(folder, exist_ok=True) df = pd.DataFrame(rows) df.drop_duplicates(subset=["content"], keep="first", inplace=True) df.to_csv( f"{folder}/{sku_id}_comments.csv", index=False, encoding="utf-8-sig", quoting=1 )

save_comments的几个参数设计点：drop_duplicates按评论内容去重，是因为翻页时会出现同一评论被不同页返回的情况，直接删掉就好。encoding="utf-8-sig"会写入带 BOM 的 UTF-8 文件，这样用 Excel 直接打开不会乱码，是 Windows 环境下最稳妥的落盘方式。quoting=1对应 csv.QUOTE_ALL，把每个字段都加引号包裹，评论正文里如果有逗号、换行符，也不会把 CSV 的列结构破坏掉。落盘之后，爬虫模块的工作就结束了，情感分析面对的不再是网页接口，而是本地老老实实的 CSV，后面的操作可以随时回滚、重新分析。

4. 情感分析怎么做：SnowNLP 跑批、阈值设置与结果回写

爬虫和数据清洗都跑通后，情感分析就是项目最上面的一层。情感分析要处理的核心问题只有一个：一段中文评论到底该判成正向、负向还是中性。选择用 SnowNLP 做情感分析，不是因为它是效果最好的模型，而是在毕业设计这个场景下，它最能同时满足“能跑、能解释、能改”这三个要求。

4.1 为什么选 SnowNLP：轻量、可解释、方便答辩

SnowNLP 是一个面向中文文本的 Python 库，内置情感分析、分词、词性标注等能力。情感分析部分返回一个 0 到 1 之间的浮点数，越接近 1 表示越正向，越接近 0 表示越负向。它和大型预训练模型比，不需要下载大权重文件，不需要 GPU，在一台普通笔记本上就能跑完几万条评论，这是毕业设计项目最看重的地方。

选型时也考虑过直接用 BERT 或调用大模型 API。BERT 要在本地加载模型并微调，一个以业务链路为主的项目因为引入模型训练反而变得不可控；大模型 API 则需要联网，答辩现场一旦网络出问题，整个环节就没法演示。SnowNLP 把这两类麻烦都避开，一条pip install snownlp就装好，代码完全本地运行，演示时不容易翻车。如果你的数据量很大，后续也可以把 SnowNLP 换成其他模型，情感分析模块的输入输出结构不用变，只需要改score_comment这一个函数。

4.2 批量给评论打分：处理延迟与阈值划分

跑批的核心函数很简单，把每一条评论传入 SnowNLP，取出 sentiments 字段，再加一个阈值判断。

import pandas as pd from snownlp import SnowNLP import time df = pd.read_csv("comments/10055368660713_comments.csv", encoding="utf-8-sig") def score_comment(text): """返回 0-1 之间的情感分数，越接近 1 越正向。""" if not isinstance(text, str) or len(text.strip()) < 2: return None return SnowNLP(text).sentiments def to_label(score): if score is None: return "unknown" if score > 0.6: return "pos" if score < 0.4: return "neg" return "neutral" df["sentiment"] = df["content"].apply(score_comment) df["label"] = df["content"].apply(to_label) print(df["label"].value_counts())

阈值不是随便拍出来的。SnowNLP 对短评容易往中间值靠，直接用 0.5 切分，会把不少带有模糊口吻的评论误判成负向。我通常设 0.6/0.4 两个阈值，把 0.4 到 0.6 之间划成中性，这样正负向的结果更明确，答辩时也更好解释。如果想把分类调得更激进，可以把 0.6 改 0.55、把 0.4 改 0.45，代价是中性区间的样本变少，误判率会略微上升。

score_comment里先排除空字符串和长度小于 2 的评论，是为了过滤“好”“棒”这类极短文本。SnowNLP 对两个字的情绪倾向识别并不稳定，标成 unknown 比硬塞进正向里更诚实。sentiment 为 None 的样本，后续在统计时先不纳入正负计算，不影响整体分布。

如果评论量超过一万条，直接对整个 DataFrame 做 apply 会让内存占用持续高涨，运行到一半程序可能被系统 kill 掉。这种时候我习惯分批处理，每 500 条休息一下再继续。

rows = [] for idx, row in df.iterrows(): rows.append(score_comment(row["content"])) if idx % 500 == 0: time.sleep(0.2) df["sentiment"] = rows df["label"] = df["content"].apply(to_label)

iterrows 虽然慢，但胜在内存占用低、方便看到进度。500 条 sleep 0.2 秒，实际感觉不到卡顿，但能让笔记本在长跑中不至于温度飙升。这些细节答辩时不一定展示，但代码在别人机器上能不能一口气跑完，往往取决于这种小地方。

4.3 按商品维度汇总，验证结果是否可信

情感分析跑完，不能只看一堆 pos/neg 标签，还要确认这些标签落在商品维度上是有意义的。汇总统计按商品 ID 分组，数一数每个 ID 下的正负数量，就能看出评论质量情况。

summary = ( df.groupby(["item_id", "label"]) .size() .unstack(fill_value=0) ) summary.to_csv("sentiment_summary.csv", encoding="utf-8-sig") print(summary.head())

groupby 按类别统计数量，unstack 把标签列变成横向字段，fill_value=0保证没有该标签的商品位置也不会是空 NaN。生成的结果文件 sentiment_summary.csv 是后面做报表的底子。如果某个商品的中性样本特别多，比如超过一半，那通常不是阈值选错，而是这个商品本身大量使用了“还可以”“一般吧”这类模棱两可的表达，这时候可以把中性的处理策略单独说明，解释成“无明显情绪偏向”即可。

最后再做一次人工抽样验证，避免模型在个别商品上整体跑偏。

import random random.seed(42) sample = df.sample(20) for _, row in sample.iterrows(): text = str(row["content"])[:30] print(f"{text} -> {row['sentiment']:.3f}")

抽 20 条把它和情感分数对应着看，人工确认判定是否符合常识。如果发现明显错判，比如一句“质量太差”被判成正向 0.6 以上，就要检查评论里是不是带了一堆表情符号，或者分词时被 emoji 干扰。人工验证这个环节才是情感分析模块里真正决定项目质量的一步。

5. 避坑实录：编码、脏数据、内存与风控的 4 个教训

代码写出来后，真正磨掉时间的是环境问题和数据问题。这套源码从解压到最终跑通，我踩过 4 次比较真切的坑，下面按“现象 → 原因 → 解决”的顺序写出来。如果遇到类似报错，可以直接对号入座。

5.1 中文乱码：CSV 读出来全是诡异符号

现象：用pd.read_csv("xxx.csv")读出来的评论内容是一堆看不懂的符号，比如“鑷繁”“鐑”这种，但列名又是正常的。

原因：文件由 Windows 端的工具写入，编码是 gbk 或 gb18030，代码却按 utf-8 去解码，于是中间字节被错误解析。反过来也一样，文件本身是 utf-8，代码里却指定了 gbk，同样会乱码。

解决：不要靠猜编码。写一个带编码回退的加载函数，依次尝试 utf-8、gbk、gb18030，谁读得通就用谁。这一层处理在项目里只需要做一次，放在公共工具模块里，之后的清洗、分析、落盘步骤都能复用。2.1 节里给出的load_csv实现直接拿来用就行，不用另造轮子。

5.2 评论自带换行符，CSV 导出后行数变多

现象：情感分析结果导出成 CSV 后，用 Excel 打开，原本一行一条评论的表被拆成多行，后面的统计数据对不上位置。

原因：评论区里用户输入的换行符\n被原样带进了 DataFrame，pandas 的to_csv默认不会对这类特殊字符做转义，导致 CSV 的行的结构被破坏。

解决：导出前先把评论字段里的\r、\n替换成空格，再用quoting=1把每个字段用引号包起来，这样 Excel 无论如何都不会乱拆行。

import re df["content_clean"] = df["content"].map( lambda x: re.sub(r"[\r\n]+", " ", str(x)) ) df.drop(columns=["content"]).to_csv( "clean.csv", index=False, encoding="utf-8-sig", quoting=1 )

保留 content_clean 列而不用原来的 content 覆盖，是因为清洗后的内容才是真正进入分析模块的样本，原始文本留一份备份，方便人工复核某条评论的原始样貌。

5.3 全量读取导致内存吃紧，脚本中途被杀

现象：情感分析脚本运行几百条之后，内存占用一个劲儿往上顶，最后进程被系统直接 kill 掉，前期的分析结果全部丢失。

原因：把几万条评论一次性读进 DataFrame，再用 apply 对整列做 SnowNLP 计算，每个中间结果都驻留在内存里，内存占用自然失控。

解决：改用 chunksize 分批读取，每批处理完落盘一次。这样一来内存里最多只保留少量评论的量级，长时间运行不容易出问题。

chunks = pd.read_csv( "big_comments.csv", chunksize=5000, encoding="utf-8-sig" ) for i, chunk in enumerate(chunks): chunk["sentiment"] = chunk["content"].apply(score_comment) chunk.to_csv( f"scored_part_{i}.csv", index=False, encoding="utf-8-sig" )

chunksize 返回的是迭代器，不会一次性把文件全装进内存，每一批单独计算、单独保存，最后再把分片 CSV 合并起来。代码虽然多了几行，但运行体验完全不同，数据量超过两万条时差距特别明显。

5.4 接口返回正常但数据不更新：可能命中风控

现象：requests 请求返回 200，JSON 解析也成功，但每次翻页回来的评论内容都是同一批，无论 page 加到哪里都没有新内容。

原因：接口检测到来自同一客户端的频繁请求，命中风控后响应的是缓存数据，不再返回真实内容和新增评论。

解决：降低请求频率，把单页间的 sleep 调成 1 到 3 秒的随机值；同时给请求头补上完整的 Referer 和 User-Agent，让请求更像正常浏览。最关键的是，在翻页循环里加一个重复检测：如果连续多次返回的第一条评论都是同一段，就认为命中风控，主动停一段时间。

import random prev_first = None repeat_count = 0 for page in range(0, 50): _, comments = fetch_jd_comments(sku_id, page) if not comments: break first_text = comments[0].get("content", "") if first_text == prev_first: repeat_count += 1 if repeat_count >= 3: print("疑似风控，暂停 60 秒") time.sleep(60) break else: repeat_count = 0 prev_first = first_text time.sleep(random.uniform(1, 3))

用第一条评论内容做重复检测是一个简单但有效的方案。更严谨的做法是缓存所有评论的哈希值，但比较消耗内存，毕设场景用首条内容比对已经能挡住大部分重复循环。sleep 用random.uniform(1, 3)生成随机间隔，避免固定间隔被服务端识别出机器特征，间隔太短容易被判定成异常访问。

6. 把结果变成答辩素材：报表、断点续抓与最终验证技巧

情感分析的结果不能只停留在终端里。答辩时要展示的是图表、统计表，以及可信的结论。最后这一步我一般做三件事：出汇总报表、生成图表、给爬虫加上断点续抓的壳。

6.1 用一张柱状图把正负分布说出来

import matplotlib matplotlib.use("Agg") import matplotlib.pyplot as plt import pandas as pd df = pd.read_csv("sentiment_summary.csv", encoding="utf-8-sig") df.sort_index().plot(kind="bar", figsize=(10, 6), title="商品评论情感分布") plt.legend(title="情感标签") plt.tight_layout() plt.savefig("sentiment_bar.png", dpi=150)

matplotlib.use("Agg")让脚本在没有显示器的环境下也能绘出图片，答辩前在笔记本上把图存成 PNG，直接贴进 PPT。dpi=150保证缩放后文字不模糊。图片结合 sentiment_summary.csv 里的统计表，回答“整体评价偏正向还是偏负向”“哪个商品口碑最差”这类问题，都有了实际数据支撑。

6.2 给爬虫加断点续抓：中断后不用从头再来

import os def get_pending_pages(checkpoint, total_pages): done = set() if os.path.exists(checkpoint): with open(checkpoint, encoding="utf-8") as f: done = {int(x) for x in f.read().split()} return [p for p in range(total_pages) if p not in done], done

checkpoint 文件记录已经完成的页码，每成功抓完一页后往文件里追加一个页码。任务被中断后再次运行，get_pending_pages会跳过已完成页码，只补抓剩余部分。这套机制在凌晨长时间跑数据时很管用，毕竟谁也不想因为一次断网就把前面几小时的成果清零。

从那以后我每次跑这类爬虫项目，都会强制先走一遍「先看结构 → 再抓样本 → 再加批量」的流程，确认接口和字段没问题才放宽请求量，不然一遍全量跑下来，多半会在乱码、重复、风控这三个坑里翻车。情感分析的阈值、SnowNLP 的分词结果、CSV 的落盘格式，也都在这个流程里一并验证过。希望这次的拆解能帮你在做淘宝、京东评论情感分析项目时省下一些试错时间，真正把这份源码跑出自己的结论。

本文还有配套的精品资源，点击获取