简介：该压缩包是一个面向潍坊与淄博旅游评论数据的完整爬虫与情感分析项目，适用人群包括Python爬虫与自然语言处理入门学习者、相关课程设计参与者，以及需要了解游客反馈的旅游从业者和决策者。项目从评论采集到情感倾向判断形成了一条完整链路：利用爬虫抓取约5万条城市评论，随后对数据进行清洗、预处理与情感分析，最终输出游客对两座城市的整体评价、满意度及不满意细节，可直接用于旅游体验调研或舆情参考。压缩包共1988个文件，以Python脚本、CSV评论数据、TXT文本和JSON配置文件为主，同时包含JavaScript、类型定义、文档及少量图表资源，整体约29.59MB，目录结构清晰，便于按采集、数据、分析、可视化等模块查阅。已有587人学习下载。通过该项目，读者可得到可复用的爬虫代码、分城市存储的评论数据集、情感分析实现及结果图表，并掌握针对具体城市评论的文本挖掘思路，为后续扩展分析或论文写作提供扎实的参考基础。
1. 5万条城市评论情感分析：先想办法把数据洗干净，再谈模型
先说结论：这个项目真正的门槛不在爬虫，也不在情感分析算法，而在“5万条评论抓回来后，你只有大约3万条能用”。城市评论这个场景，用户会大量写“哈哈哈哈环境绝了”“排队两小时再也不来”这种夹杂语气词、表情符号和网络梗的短文本，否定词还特别多。直接拿通用情感模型跑，准确率经常不到七成，和抛硬币差不了多少。
这个标题要做的事其实是一条完整的链路：用爬虫采集某个城市/多个城市的商家评论，落到数据库里，做清洗去重，再分城市、分店铺做情感倾向分析，最后得到“这个城市商户口碑整体是偏正面还是偏负面”的量化结果。适合想给城市门店选品、给区域运营做口碑监控，或者单纯想练手完整数据流水线的从业者。这篇我就按我做过的方案把每一步拆开讲，代码都是能直接跑的。
2. 用 requests 和 sqlalchemy 搭采集链路：从页面 URL 到入库的最小可跑代码
2.1 为什么是 requests 而不是 scrapy：5 万条数据考虑的是性价比
一提到爬虫，很多人的第一反应是 scrapy，甚至是分布式爬虫。但 5 万条城市评论这个量级，真的不需要上框架。单进程 requests 加一点并发控制，一两个小时就能跑完，维护成本也低得多。用 scrapy 的收益要等数据量到百万级、需要断点续爬和调度管理时才明显；到那个阶段再去研究爬虫管理平台和分布式细节也不迟。
我的选型理由很简单：requests 的代码是线性的，哪里出错肉眼就能看出来。抓 5 万条评论，单线程跑大约两三个小时，把每条请求间隔控制在 1 到 2 秒，对目标站点的压力也小。早期我踩过最重的坑就是高估了速度需求，上了 scrapy，结果一周里有三天在处理代理和去重队列，核心的评论数据反而没抓多少。
城市评论的数据来源常见的是点评类平台的城市商家页，包括餐饮、酒店、景点几类。这类页面的评论列表通常是滚动加载，所以不建议直接解析初始 HTML，要先看浏览器 Network 面板里的 XHR 请求，找到返回 JSON 的评论接口。下面这套代码把“拿 HTML/JSON → 解析评论字段 → 入库”完整串起来，适用于绝大多数返回 JSON 的评论接口。
2.2 抓取评论首页数据：请求头、超时与重试是三个保命参数
import requests import time import random HEADERS = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 " "(KHTML, like Gecko) Chrome/122.0 Safari/537.36", "Accept": "application/json, text/plain, */*", "Referer": "https://example-city-review-site.com/", "Accept-Language": "zh-CN,zh;q=0.9", } def fetch_reviews_json(url, params, retries=3): for attempt in range(retries): try: resp = requests.get(url, headers=HEADERS, params=params, timeout=10) if resp.status_code == 200 and resp.json(): return resp.json() if resp.status_code in (403, 429): # 被限流时先退避，通常等几秒就好 time.sleep(random.uniform(3, 5) * (attempt + 1)) elif resp.status_code >= 500: time.sleep(random.uniform(2, 4)) except requests.RequestException as e: # 超时和连接断开都算瞬时错误 print(f"请求失败：{e}，第 {attempt + 1} 次重试") time.sleep(random.uniform(1, 2) * (attempt + 1)) return None这段代码的核心是“有限重试 + 退避等待”。timeout=10 表示连接和读取都最多等 10 秒，避免某个慢接口把整个采集卡死。处理 403 和 429 的时候等待时间按指数增长，第一次停 3 到 5 秒，第二次停 6 到 10 秒。你实际调参的时候看日志就行：如果某个页面连续重试三次都失败，就别再硬抓，直接记下来跳过去，最后统一补采。
解析 JSON 评论的代码比解析 HTML 稳定得多：
def parse_comment_items(data): items = [] # 不同站点的 JSON 结构不一样，这里只给出最常见的两层结构 for card in data.get("reviews", []): city = card.get("city", "") shop_name = card.get("shop_name", "") rating = card.get("rating", 0) # 评论内容偶尔是 null，要兜底 content = (card.get("content") or "").strip() if not content: continue items.append({ "city": city, "shop_name": shop_name, "rating": rating, "content": content, "comment_time": card.get("comment_time", ""), }) return items注意这里有个参数细节：rating 保留原始数值，别在采集阶段做转换，否则后面分析“评分和情感分数是否一致”时会丢失精度。content 为空字符串的评论直接跳过，这类数据没有分析价值，还会把情感模型的输出带偏。
2.3 sqlalchemy 储存评论数据：表结构设计与批量写入参数
5 万条评论拿内存 list 存肯定不行，爬虫中断一次就全丢了。我习惯直接用 SQLAlchemy 连 MySQL，定义一张评论表，字段不多，但要把去重键和索引一次建好。
from sqlalchemy import create_engine, Column, Integer, String, Float, Text, DateTime from sqlalchemy.orm import sessionmaker from sqlalchemy.ext.declarative import declarative_base from datetime import datetime Base = declarative_base() class CityReview(Base): __tablename__ = "city_reviews" id = Column(Integer, primary_key=True, autoincrement=True) city = Column(String(32), index=True) # 城市名，聚合分析时用 shop_name = Column(String(128), index=True) # 店铺名 rating = Column(Float, default=0.0) # 原始评分，可能缺失 content = Column(Text) # 清洗前的原文 content_md5 = Column(String(32), unique=True, index=True) # 去重指纹 comment_time = Column(String(32), default="") created_at = Column(DateTime, default=datetime.now) engine = create_engine( "mysql+pymysql://user:password@127.0.0.1:3306/review_db?charset=utf8mb4", pool_size=10, pool_recycle=3600 ) Base.metadata.create_all(engine) Session = sessionmaker(bind=engine)content_md5 字段是最关键的，它加了 unique 约束，重复评论第二次入库时数据库直接报错，天然挡住了脸。charset 必须写 utf8mb4，因为评论里全是 emoji 和特殊符号，utf8 存不住。pool_size=10 是并发写入时的连接池大小，如果后面决定用多线程采集，可以调到 20。先用单线程的话，默认值就够。
批量入库的写法：
def save_reviews(session, review_items, batch_size=500): for i in range(0, len(review_items), batch_size): batch = review_items[i:i + batch_size] session.add_all([ CityReview(**item, content_md5=md5_fingerprint(item["content"])) for item in batch ]) try: session.commit() except Exception: # 重复数据会导致 unique 冲突，回滚后逐条试，能保留更多数据 session.rollback() for item in batch: try: session.add(CityReview(**item, content_md5=md5_fingerprint(item["content"]))) session.commit() except Exception: session.rollback() continuebatch_size=500 是我在 MySQL 上试过比较稳的阈值。小于 100 时 commit 次数太多，耗时翻倍；大于 1000 时一次语句过大，出错回滚的成本也高。注意 save_reviews 里的 md5_fingerprint 函数在下一章会定义，这里先用着。
3. 清洗和去重环节：把 5 万条评论变成 4 万条有效语料的完整处理
3.1 清洗流程的四个环节：去标签、去符号、压缩重复、兜底
城市评论的文本质量比商品评论更混乱。店铺名、地址、电话会被系统自动拼接进文本，表情符号和“哈哈哈哈”无处不在，还有人会用“不错不错不错不错”这种重复短语凑字数。清洗阶段我做四件事：
第一步去 HTML 标签，虽然 JSON 接口一般不返回 HTML，但某些平台的评论内容里会混入<br>换行标签；第二步把非中英文和常见标点之外的字符移除，只保留中文、英文、数字以及逗号句号问号感叹号；第三步压缩超过 3 次的连续重复字符；第四步去除纯空白和长度过短的评论。
import re def normalize_text(raw): # 1. 去 HTML 标签 text = re.sub(r"<[^>]+>", "", raw) # 2. 保留中文、英文、数字和常用标点 text = re.sub(r"[^\u4e00-\u9fa5a-zA-Z0-9，。！？、…\s]", "", text) # 3. 压缩连续重复字符："好吃好吃好吃好吃" -> "好吃好吃好吃" text = re.sub(r"(.)\1{4,}", r"\1\1\1", text) # 4. 合并多余空格 text = re.sub(r"\s+", " ", text).strip() return text第 2 步的正则是最容易出错的地方。方括号里的脱字符表示“取反”，意思是保留中文、大小写英文、数字、顿号句号叹号问号省略号以及空白，其余全部删除。这里故意没保留分号和引号，因为在评论语料里它们的信息量很低。正则(.)\1{4,}的作用是把任意连续出现 5 次及以上的字符压缩成 3 次，“哈哈哈哈哈哈哈哈”就变成“哈哈哈”，既保留语气又限制了重复带来的噪声。注意这个压缩只对单字生效，对“不错不错不错”这类整词重复不起作用，需要在去重阶段单独处理。
3.2 用 MD5 指纹做精确去重：比全表比对快一个量级
评论去重不能直接SELECT content FROM table WHERE content = ...，几万条数据逐条比对要把数据库跑死。正确做法是对清洗后的文本计算 MD5，用哈希值判重。相同文本必然生成相同 MD5，虽然理论上存在碰撞，但对这个量级的短文本，实际概率可以忽略。
import hashlib def md5_fingerprint(text): return hashlib.md5(text.encode("utf-8")).hexdigest() def deduplicate(items): seen = set() unique_items = [] for item in items: clean_content = normalize_text(item["content"]) if len(clean_content) < 10: continue fp = md5_fingerprint(clean_content) if fp in seen: continue seen.add(fp) item["content"] = clean_content item["content_md5"] = fp unique_items.append(item) return unique_items这里有两个参数值得细说。最短长度设为 10，是因为城市评论里常见的“很棒”“一般”只有几个字，信息量太低，情感分析里很容易被误判；但也别把阈值设得太高，20 字会丢掉大量有效的中短评。seen 集合用内存存指纹，5 万条评论的 MD5 也就几百 KB，完全没有压力。
我在实际项目里还发现一个现象：同一用户在不同平台转发同一条评论，原文几乎一致但标点有差异。所以去重前要先 normalize_text，把全角符号和多余空格清掉，否则去重形同虚设。
3.3 停用词表构建：不要直接抄网上的通用版本
情感分析不是分词任务，停用词表的作用不是删光虚词，而是删掉会干扰情感分数的高频噪声词。城市评论里出现频率极高但毫无情感倾向的词语包括“感觉”“觉得”“这家”“东西”“然后”“反正”“一个”等等。网上下载的 1500 词停用表是针对新闻语料的，用在评论上反而会把“好”“坏”之外的情感词误伤。
我的做法是：先用 jieba 对所有清洗后的评论分词，统计词频 Top 500，然后人工筛一遍，把词频高但情感中性的词挑出来加入停用词表。这个筛选过程大约需要半小时，但对后续所有分析都是正收益。词表本身是纯文本文件，每行一个词，加载方式和停用词常规做法一致。
import jieba STOPWORDS = set() with open("city_review_stopwords.txt", encoding="utf-8") as f: for line in f: word = line.strip() if word: STOPWORDS.add(word) def tokenize_for_analysis(text): words = jieba.lcut(text) return [w for w in words if w not in STOPWORDS and w.strip()]分词之后不要急着丢原始文本。我一般会把清洗后评论、分词结果、情感分数分开存，因为后面做词云和负面主题抽取还要用分词结果。城市评论里“市中心”“地铁站”“停车场”这种地点词会频繁出现，它们不是噪声，而是城市体验的维度词，应该保留，这对判断“这个城市交通便利度口碑如何”很有价值。
4. 情感分析从基线到落地：snownlp 跑分之后再叠一层词典修正
4.1 城市评论不是电商评论：为什么直接跑通用模型会翻车
情感分析这块，最省事的做法是用 snownlp 对每条评论算一个 sentiment 分数，大于 0.5 判正面，小于 0.5 判负面。snownlp 底层是朴素贝叶斯模型，理论上一个函数就能用。但城市评论有个要命的特点：口语化程度极高，否定词常和程度副词叠在一起，“没有想象中那么好吃”“也不是很难吃”这种句子比比皆是。通用模型在电商评论上训练得多，遇到这种句式经常出错。
所以我的落地路径分两层。第一层用 snownlp 跑基线，快速得到一个大体分布；第二层叠一个情感词典修正模块，专门处理否定词和程度副词。不要一上来就微调 BERT 或者做多模态情感分析——那需要标注数据、GPU 和额外的文本之外的模态，这个项目的数据规模撑不起，而且完全没必要。
4.2 修正模块的完整代码：否定词窗口和程度副词系数
from snownlp import SnowNLP NEGATION_WORDS = {"不", "没", "无", "非", "莫", "别", "未"} INTENSIFIERS = { "非常": 1.6, "特别": 1.6, "极其": 1.8, "太": 1.3, "很": 1.2, "有点": 0.7, "稍微": 0.7, "比较": 0.9, } def adjusted_sentiment(text, window=3): base_score = SnowNLP(text).sentiments words = jieba.lcut(text) score = base_score # 先处理程度副词：把 0.4 的“有点差”拉回 0.28 for idx, w in enumerate(words): if w in INTENSIFIERS: factor = INTENSIFIERS[w] score = 0.5 + (score - 0.5) * factor # 再处理否定词：找到否定词后看它后面 window 个字里有没有情感词 # 如果是否定 + 负面词，如“不难吃”，整体应偏正面 for idx, w in enumerate(words): if w in NEGATION_WORDS: after = words[idx + 1:idx + 1 + window] if any(w in POSITIVE_WORDS or SnowNLP(w).sentiments > 0.6 for w in after): score = 1 - score elif any(w in NEGATIVE_WORDS or SnowNLP(w).sentiments < 0.4 for w in after): score = 1 - score return score这套逻辑里最关键的是 window=3 这个参数。它表示否定词只影响后面 3 个字范围，避免把“不是这家店但服务员态度还行”这种跨分句文本整体翻转。window 太小找不到情感词，太大又会误伤。我用下来 3 是最优解，句子短的时候改成 2 也行。POSITIVE_WORDS 和 NEGATIVE_WORDS 是两个自定义词表，需要维护，我通常各放 50 到 100 个高频词，把“难吃”“脏乱”“划算”“惊艳”这类评论常用词手工放进去，比全部用模型判断可靠得多。
这里提一个参数细节：程度副词用0.5 + (score - 0.5) * factor而不是直接乘，是为了保持分数始终在 0 到 1 区间。score=0.6 遇到系数 1.6，会变成 0.66，而不是 0.96，这样不会把本来微正的句子变成极端正面。
4.3 城市级聚合分析：均值和中位数之外还要看标准差
每一家店铺的情感分数算出来后，真正的项目交付物是从城市维度汇总的画像。把评分、情感分数、评论数按城市分组，最直接的分析是看平均情感分，但这里有个隐藏问题：平均数会被异常值拉偏。
import pandas as pd df = pd.DataFrame(all_reviews) city_stats = ( df.groupby("city") .agg( review_count=("sentiment", "count"), mean_sentiment=("sentiment", "mean"), median_sentiment=("sentiment", "median"), std_sentiment=("sentiment", "std"), ) .sort_values("mean_sentiment", ascending=False) )std_sentiment 这个字段最容易忽略。它反映的是城市内部评论分歧度：标准差高说明这个城市的好评和差评极端分化，典型的“爱之深责之切”，或者某些商圈宣传过度；标准差低说明整体口碑一致。我在交付报告里会专门画一张散点图，横轴是评论数，纵轴是情感分，点的大小是标准差，一眼就能看出哪些城市属于“小样本高口碑”的虚火状态——评论数低于 500 但情感分接近 0.8 的城市数据，基本不值得采信。
提示：情感分数阈值不要死磕 0.5。0.45 到 0.55 之间的评论大半是中性或混合情感，比如“环境不错但味道一般”。这类样本应该归入中立区间单独统计，强行二分只会制造大量错标。
5. 5 万条评论项目避坑记录：从字谜乱码到重复入库的 5 个真实排查过程
5.1 文本全是字谜和方块字，解析结果完全不能用
现象：爬回来的评论内容是一堆不认识的偏旁部首组合，单个字符能对上，组成词语就看不懂，而且数字全变成了小方块。
原因：部分点评平台对评论内容做了字体反爬。页面会把标准字体映射成自定义字体，浏览器加载时用加密字库渲染出正常文字，但 requests 抓到的 HTML 里的字符编码是错位映射的。直接按字符取就是字谜。
解决：这种情况不要在 HTML 层面硬解。优先找该站点是否提供 JSON 接口，JSON 通常不加密；实在没有再看字体文件，把自定义字体下载后按字形轮廓映射回标准字。这里要注意一个关键点：每次加载字体映射关系可能都变，所以不能缓存一张映射表用到底，要在每次抓取时同步获取。最笨也最稳的办法是对字谜文本截图做 OCR，但那速度太慢，5 万条根本扛不住。
5.2 入库后统计发现重复率超过 40%
现象：评论总数很快到 5 万条，但店铺维度去重后实际不足 3 万条，重复集中在评分高、评论多的头部店铺。
原因：评论接口是按更新时间排序的，页码越深，新评论插入越频繁，同一评论可能同时出现在第 1 页和第 3 页；另外评论列表是滚动加载，前端滚动一次就请求一次接口，如果爬虫翻页时没有记录已抓取评论的指纹，就会反复抓同一批。
解决：不能只按评论 ID 去重，因为页面展示的 ID 字段可能被截断或脱敏。按清洗后的文本 MD5 在库里建唯一索引，入库时 catch 重复异常跳过。我在 2.3 节的 save_reviews 里已经写了这层逻辑，实际跑下来重复率从 40% 降到 3% 以内。还有 3% 是跨平台转载的近似重复，需要靠编辑距离或 SimHash 做一遍模糊去重，如果对精确率要求不高可以不做。
5.3 snownlp 把“太难吃了”判成正面情绪
现象：把“这家店的菜太难吃了，不会再光顾”喂给 snownlp，sentiments 返回 0.14，方向是对的；但改成“不难吃”之后返回 0.82，也算对；真正翻车的是“没有想象中那么难吃，凑合吧”，竟然返回 0.11 的负面分。
原因：snownlp 的训练语料主要来自带有明确情感标签的商品评论，对“没有想象中那么难吃”这种双重否定句式没有能力建模。它把“难吃”这个词的权重拉得极高，根本没有捕捉到前半句的否定和后半句的“凑合”。
解决：4.2 节里的否定词窗口就是针对这个问题的。把“不难吃”识别为正面，把“没有想象中那么难吃”识别为中性偏负面。但注意一个边界：否定词窗口对短句效果好，对长句会失效。比如“服务员说这道菜不难吃，但端上来真的一般”——否定词作用域只在“不难吃”里，后面转折句是负面，这种句子我一般直接归入中立区，不参与城市正面率统计。
5.4 翻页到第 30 页开始返回空数据，但网页上还有评论
现象：爬虫从第 1 页翻到第 40 页，前 30 页正常，之后接口返回空列表，日志里也没有报错，以为是数据到底了。
原因：评论接口翻页有两个限制：一是页码深度限制，很多接口最多返回前 50 页；二是时间窗口限制，按时间倒序排列时，超过某个时间点的评论不会被返回。第 30 页恰好落在窗口边界，再往后就是空。
解决：改用“时间游标”方式翻页，每次按 last_comment_time 传参，而不是页号。第一次请求拿最新一批，取这批里最早的评论时间作为下一次请求的游标，服务器会返回从这个时间往后的更早评论。这样翻到 5 万条都没问题，且天然避免同一时间点评论被重复抓取。
5.5 MySQL 连接被反复打断，写入速度越来越慢
现象：数据入库到一半，日志突然报 “MySQL server has gone away”，重试几次还是失败，进程卡死。
原因：默认连接有一个超时时间，爬虫和清洗预处理耗时较长，单条连接隔几分钟不操作就会被服务端断开。SQLAlchemy 的连接池不知道连接已失效，继续复用就报错。
解决：在create_engine里加上pool_recycle=3600，让连接池每 1 小时强制回收重建一次。同时把采集、清洗、入库拆成三个阶段，不要让一条 MySQL 连接跨过整个抓取时间；抓取阶段只写原始 JSON 到本地文件，清洗阶段再批量入库，这个习惯帮我避开了很多锁库和断连的问题。
6. 从“跑通”到“可信”：构造 300 条手工标注集，摸清情感分析的真实上限
做了清洗去重和词典修正，情感分析只是“能跑”，离“可信”还差一个环节：你不知道整个 pipeline 的准确率到底是多少。这时候靠自己拍脑袋判断完全不靠谱，玄学问题就得用定量方法解决。我的习惯是每批数据都随机抽取 300 条，自己人工打标，然后和算法的结果做对比。
具体做法：把清洗后的评论按城市分层抽样，每层抽 30 到 50 条，凑成 300 条。人工标记时只用两个类别：正面和负面；把明显中立的句子也归到负面或正面里都不合适，所以再加上第三类中立。判定标准要提前定死：说过 5 个字以上正面评价且没有明显负面词的算正面；讽刺、比较、双重否定这种全部算中立，不进准确率计算。这样算出来的准确率才是真实的。
from sklearn.metrics import classification_report y_true = [1, 0, 1, -1, 1, 0, 0, 1, -1, 1] y_pred = [1, 0, 0, -1, 1, 1, 0, 1, 0, 1] # 只看正面和负面两类，中立样本单独观察 filtered_true = [t for t, p in zip(y_true, y_pred) if t != -1] filtered_pred = [p for t, p in zip(y_true, y_pred) if t != -1] print(classification_report(filtered_true, filtered_pred, target_names=["负面", "正面"]))我一般把 0.45 到 0.55 之间的输出判为中立。这样会牺牲一部分样本，但剩下的样本准确率能稳定在 0.82 以上。只算正面率时还有个技巧：用情感分数的标准差代替均值来判断城市口碑是否健康，标准差超过 0.25 的城市，光看均值容易被两极分化的评论误导。这个指标比任何花哨的模型都更能说明真实用户的分歧程度。
最后再提一个多模态情感分析的延伸思路：城市评论里混着大量图片表情，如果你的数据源能一并抓到评论配图，可以把文本情感分数和图片色调做个交叉验证——通常配图明亮的评论文本正面概率更高。这个方向值得做，但前提是先把文本这条路的口径校准好。现在我拿到任何一个新平台的数据，都会先花半天人工标注 300 条再写代码调参，而不是急着全量跑。这个习惯帮我省下的返工时间远多于标注花费的时间，希望帮到你。
本文还有配套的精品资源，点击获取
