企业官网建设流程全解析

简介：面向旅游评论分析与爬虫实战学习者的项目资源，聚焦潍坊、淄博两地游客评论数据采集与情感倾向挖掘。包内含1988个文件，以js脚本（781个）、txt文本（656个）、csv数据表（199个）为主要构成，兼顾ts、json、map等类型，对应爬虫采集、数据清洗、评论存储与可视化分析等环节，压缩包整体大小约29.59MB。已有587人学习下载。资源提供了从评论抓取到情感判别的完整流程参考，可直接查看潍坊与淄博的评论原始数据、情感分析结果及满意度相关字段，便于复现“5万条城市评论”的统计思路，也可作为入门自然语言处理与旅游舆情分析的工程样例。通过阅读脚本与数据文件，使用者能快速理解爬虫请求、解析、去重和情感打分的关键步骤，并据此扩展至其他城市或行业评论场景。

1. 城市评论情感分析：5万条数据从爬虫到结论的完整链路

当你想知道“一座城市到底住得舒不舒服、值不值得去旅游”，最真实的答案不在统计公报里，而在几十万条散落的用户评论中。人工读完5万条评论不现实，但用爬虫把评论抓下来，再用情感分析模型算出每条评论的正负倾向，就能把模糊的“口碑”变成可比较的数值。这个方案听起来简单，实际走一遍会发现：最耗时间的不是模型，而是爬虫阶段的封禁、评论里的表情和反讽、以及那些“看起来是差评其实在夸”的句子。本文以某点评平台的5万条城市评论为例，完整过一遍采集、清洗、情感分析、验证和聚合的链路，适合想自己做数据产品原型、做城市对比分析或想把自然语言处理落地到业务场景的开发者。你会发现，用现成工具就能在普通电脑上跑完整个流程，前提是把每一步的参数调对。

2. 评论数据采集：爬虫选型与5万条数据的合规获取

2.1 为什么选静态接口而非页面解析：反爬成本与稳定性权衡

大部分城市评论网站的前端页面是动态渲染的，直接抓HTML拿不到评论数据，只能用浏览器自动化工具等页面完全加载后再提取。这个办法能做，但有两个硬伤：一是慢，一个页面从启动浏览器到滚动加载再解析，耗时几秒钟，抓5万条要跑到天亮；二是容易暴露，自动化工具的特征很明显，在请求量上来之后几乎必然触发反爬机制。

常见做法是打开开发者工具的“网络”面板，勾选“Fetch/XHR”过滤，然后手动翻一页评论列表，找到返回评论数据的请求。它通常不是HTML，而是一个JSON接口，里面直接包含评论文本、评分、时间、用户ID、评论ID等结构化字段。拿这个接口写请求，一个循环就能高效抓数据，速度比渲染页面快一个数量级，也更方便解析和落库。

选接口时还要看robots.txt。虽然robots.txt没有强制法律效力，但对个人学习用途而言，遵循站点的访问约定是基本素质。我一般只爬公开页面能看到的评论数据，不碰需要登录才能访问的内容，并把请求频率控制在每秒1次以内。同时设置清晰的User-Agent，标明是学习用途的爬虫。如果你要抓的是某旅游平台的城市评论，注意区分“城市综合评分”和“单条评论文本”两种接口：前者通常只是总分值，后者才是做情感分析需要的原始语料。这里要抓的是带评论文本、评分、评论日期的记录，字段越全，后面做时间聚合和区域聚合越方便。

接口选型后还要分析分页机制。常见分页有两种：基于页数（page/pageSize）和基于游标（lastId）。基于页数的接口，翻到后面可能出现重复数据或内容不完整；基于游标的接口更稳定，但参数名通常是lastId、nextCursor这类，需要先手动翻两次页面观察参数变化。拿到接口和参数后，不要急着全量爬，先请求一页做小样本测试，确认字段齐全、编码正确，再进入全量采集。测试时记得把响应体存下来看原始结构，我遇到过接口返回嵌套三层data套data的情况，写解析代码时漏掉一层就会导致所有文本为空。

2.2 带分页参数的采集脚本：请求头、限速与断点续爬

下面这段是能直接改来用的最小采集脚本，抓的是某点评平台的城市评论接口。假设接口返回JSON，评论文本在reviewText字段，评论时间在commentTime字段，评论ID是id。

import requests import time import json import random HEADERS = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", "Accept": "application/json, text/plain, */*", "Referer": "https://example.com/city/reviews", # 替换为实际页面 } def fetch_reviews(city_id, max_pages=100, out_file="reviews.jsonl"): session = requests.Session() session.headers.update(HEADERS) # 断点续爬：已存在文件就统计行数，粗略估算起始页 start_page = 0 try: with open(out_file, "r", encoding="utf-8") as f: start_page = sum(1 for _ in f) // 20 # 每页20条 except FileNotFoundError: pass for page in range(start_page, max_pages): params = { "cityId": city_id, "page": page, "pageSize": 20, "sort": "time", } try: resp = session.get( "https://example.com/api/reviews", params=params, timeout=10 ) resp.raise_for_status() data = resp.json() except Exception as e: print(f"[第{page}页] 请求失败: {e}") time.sleep(5) continue items = data.get("data", {}).get("list", []) if not items: print("没有更多数据，停止。") break with open(out_file, "a", encoding="utf-8") as f: for it in items: # 只保留需要的字段，过滤空文本 if it.get("reviewText") and it["reviewText"].strip(): record = { "id": it.get("id"), "city": city_id, "score": it.get("score"), "time": it.get("commentTime"), "text": it["reviewText"].strip(), } f.write(json.dumps(record, ensure_ascii=False) + "\n") print(f"已采集第{page}页，累计{sum(1 for _ in open(out_file, encoding='utf-8'))}条") time.sleep(random.uniform(0.8, 1.5)) # 限速，降低被封概率

这段脚本的关键点有三个。第一，用requests.Session复用TCP连接，避免每次重新握手被风控盯上。第二，断点续爬通过统计已完成文件的行数来估算起始页，虽然不精确，但配合时间排序，重跑时影响很小。更稳妥的做法是把已抓到的评论ID存到一个集合里，运行时做内存去重，但5万条评论的ID集合也就几十兆，完全放得下。第三，限速用的是随机延迟，固定延迟容易被识别成机器行为，随机间隔更接近真人操作。

参数说明：max_pages控制最大翻页数，按每页20条计算，5万条需要2500页，但实际评论排序会随时间变化，所以建议按时间倒序抓，并设置足够大的max_pages让循环自己终止。timeout设10秒，网络抖动时快速失败重试。如果接口要求登录后的Cookie，可以把浏览器里复制出的Cookie加到HEADERS里，但要注意登录态过期会导致返回数据变形，所以脚本里最好加一层字段校验，发现连续几页都没有reviewText就停下来换Cookie。

另外算一下耗时：每页20条，5万条是2500页，每页间隔0.8到1.5秒，加上请求处理时间，大约需要1到1.5小时。这个时长在个人电脑上跑没问题，但别在公共网络上抓，容易因为出口IP共享被连带封禁。抓下来的文件是JSONL格式，一行一条，方便后续用pandas读取。

2.3 数据去重与字段规整：入库前的最后一道手

爬下来的数据虽然是结构化JSON，但直接拿来做情感分析还是有很多脏点：翻页可能重复抓到同一评论，有些评论只有表情没有文字，时间字段格式可能不统一，评分字段偶尔混入字符串。所以要先读进pandas做清洗。

import pandas as pd df = pd.read_json("reviews.jsonl", lines=True) print("原始行数:", len(df)) # 按评论ID去重，保留第一次出现的记录 df = df.drop_duplicates(subset="id", keep="first") # 删除评论文本为空的记录 df = df.dropna(subset=["text"]) # 去掉纯空白的评论 df = df[df["text"].str.strip() != ""] # 时间字段统一成datetime类型，方便后续按月份聚合 df["time"] = pd.to_datetime(df["time"], errors="coerce") df = df.dropna(subset=["time"]) # 分数字段强制转成数值，无法转换的置空 df["score"] = pd.to_numeric(df["score"], errors="coerce") df = df.dropna(subset=["score"]) print("清洗后行数:", len(df)) print(df["city"].value_counts()) print(df["score"].describe()) df.to_parquet("city_reviews_clean.parquet")

这里值得留意的是drop_duplicates的keep参数。接口翻页时如果出现重复记录，keep="first"保留先抓到的版本。时间字段用errors="coerce"把非法字符串转成NaT，之后再dropna掉。评分字段同理，城市评论里偶尔会掺着“暂无评分”这类脏值，直接to_numeric并丢空。最后存成parquet是比CSV更好的选择，压缩率高、读取快，后续用pandas或直接加载到模型都方便。如果你必须用CSV，注意统一utf-8编码，同时用quoting=csv.QUOTE_ALL处理文本里的逗号。

清洗完还要看分布。打印city的value_counts，如果某个城市只有几百条评论，而另一个城市有2万条，后续聚合时必须考虑样本不平衡。比如评论少的城市可能只有几个极端差评，直接把情感均值拉得很低，容易得出错误结论。这一步不做的话，模型跑完你都不知道结论被少数样本带偏了。

3. 情感分析落地：从词表到预训练模型的选型与实战

3.1 三种情感分析方案的适用边界：词表、朴素贝叶斯与中文预训练模型

拿到5万条清洗后的评论，接下来要判断每条文本的情感极性。很多人第一反应是“用深度学习模型”，但实际工程里要先看数据规模、标注成本和运行资源。我按自己用过的方案，把常见做法分成三类。

词表方案最简单：准备一张正负面情感词表，统计评论里命中的词并累加分数。优点是跑5万条只要几秒，缺点也很明显——“这家店不干净”会被“干净”这个正面词误导，“太难吃了但我爱他”这种转折句完全失效。所以词表只适合快速看个大概，不适合出正式报告。

朴素贝叶斯需要标注语料。如果你没有人工标注，可以拿评论自带的星级当弱标签：1-2星视为负面，4-5星视为正面，3星丢弃。这样能自动造出训练集，模型能学到“干净”“差劲”这类词的统计关联，但对否定句的泛化仍然一般。原因是TF-IDF特征无法理解词序，模型不知道“不干净”其实是负面。如果评论文本普遍很短，词序信息本就稀缺，朴素贝叶斯倒也能用；但城市评论经常是“环境可以，服务太慢”这种前后转折，朴素贝叶斯容易抓错重点。

预训练模型是目前实际项目里效果最稳的选择。中文预训练模型在海量语料上做过掩码语言模型训练，对“不太满意”“不怎么样”这类表达有更强的语义理解。缺点是推理慢、吃显存。但5万条评论属于小批量，用GPU推理半小时就能完成，CPU也不是不能跑，只是时间会慢到让你怀疑人生。我的建议是：别从零训练模型，直接用开源的预训练模型做推理。5万条这个规模，恰好是“直接调用”而不是“微调”的边界——如果数据量到50万、100万，微调会更值得；但5万条评论对普通预训练模型来说，零样本推理已经能拿到八成左右的准确率。

3.2 用现成模型跑批推理：显存控制与批量处理技巧

以某个开源中文情感分类模型为例，加载后对清洗后的DataFrame批量预测。下面是完整可跑的推理代码。

import torch from transformers import AutoTokenizer, AutoModelForSequenceClassification import pandas as pd model_name = "some/chinese-sentiment-model" # 替换为实际可用的模型标识 tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForSequenceClassification.from_pretrained(model_name) device = "cuda" if torch.cuda.is_available() else "cpu" model.to(device) model.eval() df = pd.read_parquet("city_reviews_clean.parquet") texts = df["text"].tolist() def predict_batch(texts, batch_size=64, max_length=128): results = [] for i in range(0, len(texts), batch_size): batch = texts[i:i + batch_size] enc = tokenizer( batch, truncation=True, padding=True, max_length=max_length, return_tensors="pt" ).to(device) with torch.no_grad(): outputs = model(**enc) probs = torch.softmax(outputs.logits, dim=-1) # 假设标签0为负面，1为正面 batch_result = probs[:, 1].cpu().tolist() results.extend(batch_result) return results df["pos_score"] = predict_batch(texts, batch_size=64, max_length=128) df["sentiment"] = (df["pos_score"] > 0.5).astype(int) df.to_parquet("city_reviews_scored.parquet")

这段代码里最需要调的是batch_size和max_length。batch_size受显存约束，16GB显存跑64没问题；如果你的显卡只有4GB，把batch_size降到16或32。max_length决定模型能看到多长的评论，普通用户评论一般在50字以内，设128足够；设太大会浪费显存，太小会截断关键信息。注意这里的padding用的是动态padding，tokenizer会按batch内最长的样本补齐，比固定padding省显存。

推理速度方面，一张消费级显卡（如显存8GB）处理5万条评论，batch_size=64的情况下，实际耗时约20到40分钟。如果只有CPU，同样数据量可能要跑3到6小时。所以如果你的机器没有GPU，建议先用2000条小样本验证流程，再决定是否租GPU或减少数据量。情感分析不是流式计算，跑得慢一点没关系，但别在没验证结果前就全量跑。

推理完成后，检查pos_score分布。如果大量评论的得分集中在0.5附近，说明模型区分度不高，可能是文本本身简短、情感不明显，也可能是模型对领域词汇不熟悉。比如“打卡”“网红店”这类词，老模型可能不理解。此时可以换一个更大或更新的模型，也可以对评论做简单扩展，比如把“打卡”替换成“来过了”，但这会引入噪声，我一般优先换模型。

3.3 结果标注与正确率验证：随机抽检和混淆矩阵

模型预测完，很多人直接拿结果做统计，这很容易翻车。正确做法是先抽100条人工标注，再对比模型预测，算出真实准确率。

import random import numpy as np import pandas as pd from sklearn.metrics import confusion_matrix, classification_report df = pd.read_parquet("city_reviews_scored.parquet") random.seed(42) sample_indices = random.sample(range(len(df)), 100) # 人工标注：这里演示用规则代替，真实场景需要人看 # 把样本导出后，标注结果写回manual_label列 sample_df = df.loc[sample_indices, ["text", "score", "sentiment"]].copy() sample_df["manual_label"] = (sample_df["score"] >= 4).astype(int) # 弱标注示例 y_true = sample_df["manual_label"] y_pred = sample_df["sentiment"] print(confusion_matrix(y_true, y_pred)) print(classification_report(y_true, y_pred))

真实项目里，人工标注不是规则代替。我一般会把抽出的100条导出成一个Excel，里面是评论原文、星级、模型预测结果，然后请同事或自己逐条判断真实情感。注意抽样要用随机种子固定，方便复现，也避免只抽到最新或最热的评论。混淆矩阵能直观看到模型更容易把负面当成正面，还是反过来。比如输出里第一行（真实负面）预测成正面的数量很多，说明模型偏乐观；如果第二行（真实正面）预测成负面多，说明模型偏保守。

除了人工标注，还有一种更省力的验证：用评论自带的星级做一致性分析。正常来说，4-5星应该多数是正面，1-2星多数是负面。你可以直接算一下不同星级下sentiment=1的比例。

print(df.groupby("score")["sentiment"].mean())

看这个输出时有个常见困惑：3星评论的正面比例接近0.5，这是正常的，因为3星本身就是“还行，但说不出有多好”。但如果有大量1星评论被预测成正面，说明模型可能被“环境不错但服务差到极点”这类混合评价搞糊涂了。这种验证不需要额外人工，作为快速排查很有价值。

4. 城市评论情感分析的避坑指南：爬虫封禁、数据脏乱与模型偏置

4.1 现象：采集到3000多条时突然开始大量返回403

我抓某平台评论时，前面一切正常，翻到某个页数后连续不断报403，重试也无效。原因：请求频率虽然设置了随机延迟，但累计请求量达到阈值，且我用的User-Agent是requests库默认的python-requests，很容易被识别。解决：一是把User-Agent换成一个浏览器的完整UA，并加上Accept-Language等字段；二是把请求频率再降一档，0.8到1.5秒改成1.5到2.5秒；三是做断点续爬，从断点继续而不是从头开始。如果你有代理资源，可以把请求分散到多个IP，但注意免费代理的稳定性很差，频繁断线反而浪费更多时间。对个人项目来说，最靠谱的其实是把采集时间拉长到3到4个小时，而不是在一个小时内暴力抓完。

4.2 现象：评论里的表情符号和繁体字导致情感误判

清洗后的文本里常见“这家店很好👍”“東西好吃，服務也一流”。模型把带👍的句子判成中性甚至负面，繁体句子也经常得低分。原因：表情符号在分词时被当成特殊token，扰乱语义；繁体字和简体字在预训练词表里的覆盖面不同，模型没见过太多繁体表达。解决：先统一转简体，再对表情做归一化。我通常用opencc把繁体转成简体，再用emoji库把表情替换成文字描述。

import emoji from opencc import OpenCC cc = OpenCC("t2s") def clean_emotion_text(s): s = cc.convert(s) # 繁体转简体 s = emoji.demojize(s) # 表情转成描述文本 # 常见表情再映射成中文词 s = s.replace(":thumbs_up:", "赞") s = s.replace(":smile:", "开心") s = s.replace(":cry:", "哭") return s df["text_clean"] = df["text"].apply(clean_emotion_text)

这里要注意，demojize生成的描述是带冒号的英文短语，直接喂给模型会有噪声，所以需要把高频表情手动映射成简短中文。如果表情种类多，可以先统计出现频次，只映射排名前20的，剩下的直接删掉，因为低频表情对情感判断的贡献可以忽略。另外，繁体转换后会留下“服務”变“服务”，“一流”不变，这类转换不会引入歧义，可以放心做。

4.3 现象：评论很少的新区域出现极端情感均值，导致城市排名失真

某城市新开的商圈只有不到20条评论，其中3条差评，情感均值就掉到0.2，而老商圈有5000条评论均值0.7。如果用平均分对比，新区域明显吃亏。原因：样本量太小，极值影响大。解决：在聚合时加一条阈值规则，评论数少于50的区域不参与对比，或者用贝叶斯平滑把情感均值往整体均值收缩。贝叶斯平滑公式很简单：smoothed = (count * avg + global_avg * alpha) / (count + alpha)，alpha取10到20。这样小样本的分数会趋向全局均值，不会被极值带偏。这个技巧在做城市间对比时尤其重要，因为热门城市和冷门城市的评论量可能差一个数量级。

district_stats = df.groupby("district")["pos_score"].agg(["mean", "count"]) alpha = 15 global_avg = df["pos_score"].mean() district_stats["smoothed"] = ( district_stats["mean"] * district_stats["count"] + global_avg * alpha ) / (district_stats["count"] + alpha)

4.4 现象：模型对否定句“不怎么样”识别错误

我测试过一批“环境还行，就是不怎么样”的评论，模型预测为正面，原因是注意力集中在“还行”上，“不怎么样”的否定含义没有被充分利用。原因：预训练模型虽然有上下文理解，但短文本中否定词和目标词之间可能隔着修饰成分，模型在有限长度下捕捉不全。解决：可以在预处理阶段标记否定词，或者更简单一点——在推理后做规则修正。如果文本中出现“不怎么样”“不太好”“一般般”等固定搭配，且没有其他强正面词，就把pos_score压低0.3。这类规则不能覆盖所有情况，但能把模型的系统性错误压下去。如果你对效果有更高要求，应该用更大参数量模型或做领域微调，不过5万条评论的应用场景里，规则修正的性价比更高。

def rule_adjust(text, pos_score): neg_phrases = ["不怎么样", "不太好", "一般般", "差强人意"] pos_phrases = ["非常好", "很满意", "强烈推荐"] if any(p in text for p in neg_phrases) and \ not any(p in text for p in pos_phrases): return pos_score - 0.3 return pos_score df["pos_score_adj"] = df.apply( lambda r: rule_adjust(r["text"], r["pos_score"]), axis=1 )

注意，规则修正后要重新计算准确率，避免压过头。如果原本预测0.6的评论被压到0.3，等于把边界样本推到了负面，可能引入新错误。因此规则只应在模型置信度不高时使用，比如pos_score在0.4到0.7之间。这个区间才是真正容易出错的地方。

5. 从情感分值到城市画像：聚合分析与可视化输出

5.1 按区域和时段聚合的情感指数计算

有了每条评论的情感分值，就可以开始做城市画像了。我一般按三个维度聚合：时间（年、月或季度）、区域（行政区或商圈）、评分星级。下面是用pandas做聚合的典型代码。

import pandas as pd df = pd.read_parquet("city_reviews_scored.parquet") df["month"] = df["time"].dt.to_period("M") # 城市整体情感指数：对pos_score取均值 city_monthly = df.groupby("month")["pos_score"].mean().reset_index() # 区域月度交叉，同时保留评论量 district_monthly = df.groupby(["district", "month"])["pos_score"].agg( ["mean", "count"] ).reset_index() # 过滤小样本区域 district_monthly = district_monthly[district_monthly["count"] >= 50] # 贝叶斯平滑 global_mean = df["pos_score"].mean() alpha = 15 district_monthly["smoothed"] = ( district_monthly["mean"] * district_monthly["count"] + global_mean * alpha ) / (district_monthly["count"] + alpha)

聚合时最需要注意的是时间粒度。城市评论的活跃度有季节性，按天聚合噪声太大，按年聚合又会把趋势抹平。月份是自然选择。区域字段如果原始接口没给，需要用评论里的地名关键词反查，但这一步会有误差，所以建议在爬虫阶段就把区域字段一并抓到。如果只有城市ID，就只能做城市级聚合，没法往下钻到商圈。

情感指数算出来后，还要做交叉验证。比如对比某个区域的评分星级和情感指数，如果星级很高但情感指数低，说明用户在评分上给了“还不错”，文本里却在吐槽“排队两小时体验极差”。这种不一致可能是评分膨胀，也可能是“好评返现”导致星级虚高，但它本身就是有价值的发现。你可以把这种区域标记出来，作为需要看原文的异常点。

5.2 用词云和情感分布图验证结论

数值统计容易掩盖细节，可视化能帮你快速发现异常。我常用两张图：一张是正负面评论的词云对比，一张是情感分数的分布直方图。

import matplotlib.pyplot as plt from wordcloud import WordCloud for senti in [0, 1]: texts = " ".join(df[df["sentiment"] == senti]["text_clean"].tolist()) wc = WordCloud( font_path="simhei.ttf", # 中文字体路径 width=800, height=400, max_words=100, background_color="white" ).generate(texts) plt.figure(figsize=(10, 5)) plt.imshow(wc, interpolation="bilinear") plt.axis("off") plt.title("负面评论词云" if senti == 0 else "正面评论词云") plt.savefig(f"cloud_{senti}.png", dpi=150)

词云的作用是快速核对模型结论是否符合常识。如果负面词云里出现“干净”“实惠”这类正面词，大概率是评论里带着反讽，比如“真是干净得让我不敢进去”。这说明模型可能没把反讽识别出来，需要回到上一章的规则修正。如果正面词云里全是“不错”“可以”，说明整体评价比较温和，情感指数不会太低。

除了词云，情感分数的分布直方图也很关键。把pos_score画成直方图，观察是不是双峰分布。正常来说，正面评论应该集中在0.8以上，负面评论集中在0.2以下，中间是模糊地带。如果大量评论落在0.4到0.6之间，说明模型在这些样本上犹豫不决，这时候可以针对中间区间再看几条原文，找出是哪些词让模型困惑。

plt.figure(figsize=(8, 5)) plt.hist(df["pos_score"], bins=50, range=(0, 1)) plt.xlabel("positive score") plt.ylabel("count") plt.title("评论情感得分分布") plt.savefig("sentiment_dist.png", dpi=150)

最后，把月度情感指数和时间画成折线图，可以直观看到城市口碑的拐点。比如某区域在某个月突然出现负面峰值，去查当月的评论原文，往往能发现是因为某个公共事件导致的集体吐槽。这种分析对商业选址和品牌公关很有价值，但对个人项目来说，能证明你的情感分析链路是通的就够了。

到这里，利用爬虫爬取城市评论并做情感分析的完整流程就走通了。我自己做过一个小版本：爬了某新一线城市的3万条评论，第一次跑模型时忘了处理表情，正面评论的准确率只有六成；后来把表情替换和繁体转换加上，准确率提到了八成左右。这让我养成了一个习惯：先花一小时看100条原始评论，再决定清洗规则和模型选型，而不是拿到数据就丢进模型。希望这个流程和踩坑记录能帮到你。

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