Selenium+文本挖掘实战：从评论采集到情感分析与主题建模

做了几年数据采集和文本分析，我越来越觉得 Selenium 和文本挖掘这套组合，是被很多人低估的黄金搭档。特别是面对那些没有开放 API、又全是动态渲染页面的网站，想拿留言评论数据做分析，requests 加正则那套很容易卡壳。而把 Selenium 采集到的留言数据，接上情感分析、主题建模、关键词提取和文本分类这一串文本挖掘流程，价值就完全不一样了。这套流程不复杂，但中间坑很多，我今天把这些经验整理出来，希望能帮你少走弯路。

这个方案适合谁？如果你要处理电商评论、微博留言、论坛帖子、应用商店评价这类数据，想从中分析用户情绪、发现热点话题、批量归类留言，这篇文章基本能把整个链路讲清楚。下面我按自己的实战流程来拆解，从采集到分析，每一步都给出可直接参考的操作。

1. 整体思路与方案选型

先说清楚一件事：Selenium 和文本挖掘并不是天然绑定的一对工具。Selenium 解决的是“怎么把网页数据稳定拿到手”的问题，文本挖掘解决的是“拿到手之后怎么把数据变成结论”的问题。这两个问题单独都有成熟的解法，但把它们串成一个完整 pipeline，才能真正处理留言数据这类非结构化文本。

1.1 为什么选择 Selenium 而不是直接用接口

很多留言数据所在的页面，比如微博评论、京东评价、小红书笔记下的回复，都是前端 JavaScript 动态渲染出来的。你用 requests 直接请求页面源码，得到的往往是空壳 HTML，真正的数据是页面加载后通过 Ajax 拉取、再由 JS 渲染到 DOM 里的。这时候你有两个选择：一个是抓包分析接口，直接调接口拿 JSON；另一个就是用 Selenium/Playwright 这类浏览器自动化工具，模拟真实用户操作。

那为什么我会选 Selenium？说个我自己的实操感受：抓包分析接口在数据量大、逻辑复杂时非常耗费时间，而且很多网站会做接口签名、参数加密、频率限制。你花一下午把接口参数破解了，第二天对方加个字段，代码又得重写。而 Selenium 直接操作真实浏览器，天然绕过接口加密的麻烦，只要能定位到元素，就能稳定拿到数据。代价是速度慢、资源占用大，但对于留言数据这种体量（几千到几十万条），完全够用。

提示：如果你的目标网站有清晰的接口且无加密参数，优先用 requests 方案，效率和稳定性都更好。Selenium 不是万能的，它适合那些接口方案搞不定的场景。

1.2 “优化”在这套方案里到底指什么

项目标题里有个关键词是“优化”，这个词容易让人误解，这里解释一下我在实操中是怎么理解它的。第一层是采集阶段的优化：Selenium 跑起来慢、容易崩，等待策略、元素定位、异常重试、去重逻辑，每一个环节都需要针对目标网站做调优。第二层是分析效率的优化：留言数据清洗、分词、向量化这些步骤，如果用错了方式，几万条数据就能让程序跑几小时。

我实测过一组数据：同样是清洗 2 万条中文评论，用 Pandas 向量化操作几秒钟完成，用普通 for 循环加正则要跑两三分钟；做 LDA 主题建模时，如果不去掉低频词和停用词，模型收敛时间能差出 5 倍以上。这种优化不是可有可无的，而是让整个方案从“能跑”变成“能落地”的关键。后面每个章节我都会把不同阶段的优化点穿插进去讲。

1.3 完整流程的整体设计

一封完整的留言数据分析方案，我习惯拆成五个环节，后面所有内容都围绕这条主线展开：

这个流程并不复杂，但每一步都有很多细节。如果不先把整体结构理顺，很容易在中间某个环节卡住，比如数据拿到了但清洗不干净、分词效果差导致后面分析全偏。下面我就按这个流程，把每个环节的关键操作和踩坑记录展开来说。

2. Selenium 采集环节的关键实操

Selenium 采集这块，网上教程非常多，但大多是简单演示“打开网页、获取数据、关闭浏览器”，真正的工程化细节很少人讲。这一节我会重点讲环境配置、等待策略、元素定位、滚动加载和异常处理这几个直接影响成功率的问题。

2.1 环境准备与浏览器驱动版本匹配

先说环境：Python 3.8+，Selenium 4.x，Chrome 浏览器，还有对应版本的 ChromeDriver。很多人初次跑 Selenium 就挂在驱动版本不匹配上。Chrome 每次自动升级后，旧版驱动就废了。判断方法非常简单：打开浏览器，地址栏输入 chrome://version，记下版本号，去 ChromeDriver 下载页找你对应的版本。

Selenium 4.x 之后还有一个更省心的方案：使用 Selenium Manager。从 4.6 版本开始，Selenium 内置了 Selenium Manager，如果本机没装 Chrome，它会自动下载匹配的驱动。不过实际项目里我建议还是手动管理驱动，因为内网环境、服务器环境不一定允许自动下载，手动控制版本更稳妥。

bash复制# 安装依赖
pip install selenium pandas jieba scikit-learn snowlp gensim

这里插一句， snownlp 的包名有点特殊，如果装不上可以试 pip install snownlp。装好之后验证一下：

python复制from selenium import webdriver
driver = webdriver.Chrome()
driver.get("https://example.com")
print(driver.title)
driver.quit()

能打印出页面标题，说明环境就通了。

2.2 等待策略：显式等待优先于隐式等待

Selenium 采集留言数据时，最常见的错误是 NoSuchElementException——元素还没加载出来，代码就去定位了。解决这个问题有两种方式：隐式等待和显式等待。隐式等待是设置一个全局超时时间，比如 driver.implicitly_wait(10)，表示在 10 秒内轮询查找元素，找不到就抛异常。

但我的经验是：能用显式等待就用显式等待。隐式等待虽然简单，但在复杂页面下会拖慢执行速度，因为每次查找元素都会等待，而且不同浏览器对隐式等待的实现有细微差异。显式等待用 WebDriverWait 配合 expected_conditions，可以精确指定“等某个元素可见后再继续”。

python复制from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

wait = WebDriverWait(driver, 10)

# 等待评论列表第一条出现
comment_item = wait.until(
    EC.presence_of_element_located((By.CSS_SELECTOR, ".comment-item"))
)

# 等待“查看更多”按钮可点击
load_more_btn = wait.until(
    EC.element_to_be_clickable((By.XPATH, "//div[@id='load-more']"))
)

为什么等待对留言采集这么重要？因为留言区通常是页面加载完成后才异步拉取的，有些平台还会做“懒加载”——用户滚动到评论区才去请求留言数据。你等不到正确的时机，后续代码全白搭。判断等待时机的通用方法是在浏览器开发者工具里看 Network 面板，确认留言接口的触发时机，再决定该等哪个元素。

2.3 元素定位：CSS Selector 优先，XPath 兜底

拿到留言数据，核心就是定位留言容器。我个人的优先级排序是：id 定位 > CSS Selector > XPath > 标签名/链接文本。为什么？id 是最稳定的，但留言列表很少给每个评论一个独立 id，所以实际项目里用 CSS Selector 和 XPath 最多。

举个例子，某电商平台评论区的结构大概是：

html复制<div class="comment-list">
  <div class="comment-item">
    <span class="user-name">用户A</span>
    <p class="comment-content">这个商品质量不错，物流很快</p>
    <span class="comment-date">2024-05-01</span>
  </div>
  <div class="comment-item">
    <span class="user-name">用户B</span>
    <p class="comment-content">包装破损，差评</p>
    <span class="comment-date">2024-05-02</span>
  </div>
</div>

定位所有评论节点：

python复制# 拿到所有评论条目
items = driver.find_elements(By.CSS_SELECTOR, ".comment-list .comment-item")

for item in items:
    username = item.find_element(By.CSS_SELECTOR, ".user-name").text
    content = item.find_element(By.CSS_SELECTOR, ".comment-content").text
    date = item.find_element(By.CSS_SELECTOR, ".comment-date").text
    print(username, content, date)

这里有个很容易犯的错：用 driver.find_element 去定位评论内容，结果只能拿到第一条评论。要用 driver.find_elements 拿所有列表项，再从每个列表项里二次定位。这样即使每条评论的结构有细微差异，也不会因为某一条缺失就直接抛异常。

XPath 的作用场景是：当 CSS 类名是动态生成的（比如 comment-item_12034fa 这种带哈希后缀），CSS Selector 就不稳定了。这时候用 XPath 的 contains 方法：

python复制items = driver.find_elements(By.XPATH, "//div[contains(@class, 'comment-item')]")

还有更复杂的场景，比如评论在 iframe 里，或者嵌套在多层 div 中，定位就要先切 iframe：

python复制driver.switch_to.frame("comment-iframe")
# 定位评论...
driver.switch_to.default_content()  # 切回主文档

踩过一次坑后我总结的经验是：拿到目标网站先不要急着写代码，先用开发者工具确认评论元素的稳定特征。哪个属性是稳定的就去定位它，优先用文本内容（评论正文）而不是节点层级去定位，因为 JS 框架升级最容易改的就是层级和类名。

2.4 滚动加载与分页：触发更多留言

很多网站的留言不是一次性加载完的，而是随着滚动条下降不断加载。Selenium 处理滚动加载的方式非常直接：模拟滚动到底部，等新内容出现，再继续滚动。

python复制import time

def scroll_and_collect(driver, max_scrolls=20):
    comments = []
    last_count = 0
    for i in range(max_scrolls):
        # 滚动到底部
        driver.execute_script("window.scrollTo(0, document.body.scrollHeight);")
        time.sleep(2)  # 等页面加载
        
        # 检查评论数量是否变化
        items = driver.find_elements(By.CSS_SELECTOR, ".comment-item")
        if len(items) == last_count:
            # 数量没变，可能已到底或需要点击“查看更多”
            try:
                load_btn = driver.find_element(By.XPATH, "//div[text()='点击查看更多']")
                load_btn.click()
            except:
                break
        last_count = len(items)
    return items

注意这里有个小技巧：每次滚动后比较评论数量，如果数量没有增长，说明加载可能结束了。如果页面有“查看更多”按钮，就点一下继续加载。

滚动加载有一个常见问题：模拟滚动太快会导致页面还没加载完，代码就已经执行到下一步。所以 time.sleep 是必要的，但不能写死太久，否则几万条评论要爬到猴年马月。我的习惯是先用 time.sleep(2) 起步，观察页面稳定性再动态调整，如果发现大量 StaleElementReferenceException 异常，就把 sleep 时间加长到 3-4 秒。

2.5 数据存储与断点续爬

采集到的留言一定要及时落盘，不要屯在内存里。原因很简单：Selenium 进程一旦崩溃、页面超时、网络断开，内存里的数据全没了。我习惯每翻一页就增量写入 CSV，而不是最后一次性保存。

python复制import csv
from pathlib import Path

csv_path = Path("comments.csv")
write_header = not csv_path.exists()

with open(csv_path, "a", newline="", encoding="utf-8-sig") as f:
    writer = csv.writer(f)
    if write_header:
        writer.writerow(["username", "content", "date", "page"])
    for item in items:
        writer.writerow([
            item.find_element(By.CSS_SELECTOR, ".user-name").text,
            item.find_element(By.CSS_SELECTOR, ".comment-content").text,
            item.find_element(By.CSS_SELECTOR, ".comment-date").text,
            current_page
        ])

再用 utf-8-sig 编码而不是 utf-8，这样 Excel 打开 CSV 不会乱码。断点续爬的实现思路是：启动时先读 CSV 里已有的评论数，如果当前页面已经爬过，就跳过。更简单的方案是用 set 去重，把已采集的评论内容存到内存里：

python复制seen = set()
if csv_path.exists():
    with open(csv_path, "r", encoding="utf-8-sig") as f:
        reader = csv.reader(f)
        next(reader, None)  # 跳过表头
        for row in reader:
            if row:
                seen.add(row[0] + "_" + row[1])  # 用户名+内容作为唯一标识

后面采集时判断 if (username + "_" + content) not in seen 才写入。这个方法虽然简单，但能大幅减少重复数据，后面清洗阶段也能省不少事。

3. 文本挖掘四大应用实操拆解

留言数据拿到手，下一步就是文本挖掘。标题里提到的情感分析、主题建模、关键词提取、文本分类，四个方向各有侧重，但都需要先做文本预处理。这一节我会把预处理和四个分析方向串起来讲。

3.1 文本预处理：决定整个分析质量的地基

很多人一上来就做情感分析，结果效果很差，很可能是没做好预处理。留言数据的预处理主要包括：缺失值处理、去重、去噪声（去掉纯表情、纯标点、广告链接）、分词、去停用词。

我用 Pandas 处理 CSV 文件：

python复制import pandas as pd
import re

df = pd.read_csv("comments.csv")
df = df.dropna(subset=["content"])  # 去掉空内容
df = df.drop_duplicates(subset=["content"])  # 去重

# 去掉纯表情、纯标点、超短评论
def clean_text(s):
    if not isinstance(s, str):
        return ""
    s = s.strip()
    # 去掉 URL
    s = re.sub(r"https?://\S+|www\.\S+", "", s)
    # 去掉 @ 用户
    s = re.sub(r"@\S+", "", s)
    return s

df["clean_content"] = df["content"].apply(clean_text)
df = df[df["clean_content"].str.len() >= 2]

分词我用 jieba，这是中文文本挖掘事实上的标准工具。有几个细节需要注意：

python复制import jieba

jieba.setLogLevel(20)  # 关闭日志

# 加载自定义词典，比如产品名、品牌名、网络流行语
jieba.load_userdict("domain_words.txt")

# 分词并过滤停用词
stop_words = set()
with open("stopwords.txt", "r", encoding="utf-8") as f:
    for line in f:
        stop_words.add(line.strip())

def tokenize(text):
    words = jieba.lcut(text)
    words = [w for w in words if w not in stop_words and len(w.strip()) > 1]
    return words

df["tokens"] = df["clean_content"].apply(tokenize)

分词这块最容易踩的坑是：程序默认词典对领域词汇识别不准。比如商品评论里的“蓝牙耳机”，jieba 可能切成“蓝牙/耳机”，这并不算错，但在后续做关键词提取时，“蓝牙耳机”这个整体概念就被拆散了。解决办法就是自定义词典，把这些领域词加进去，让 jieba 把它们当作一个整体。

提示：停用词表不要直接用网上随便找的“中文停用词表”，要根据你的领域做增删。比如“商品”“东西”“感觉”“觉得”这类词在普通文本里是动词，但在评论语料里是高频的无意义词，建议加到你的自定义停用词表里。

3.2 情感分析：从词典到预训练模型

情感分析的目标是判断每条留言的情感倾向：正向、负向还是中性。中文情感分析的方案大致分三类：基于词典、基于传统机器学习、基于深度学习预训练模型。

我的建议是：先跑通一个轻量级方案，再根据效果升级。轻量级首选 SnowNLP，它简单到几乎不需要配置：

python复制from snownlp import SnowNLP

def sentiment_score(text):
    try:
        s = SnowNLP(text)
        return s.sentiments  # 0~1 之间，越接近1正向
    except:
        return 0.5

df["sentiment"] = df["clean_content"].apply(sentiment_score)
df["sentiment_label"] = df["sentiment"].apply(
    lambda x: "positive" if x > 0.6 else ("negative" if x < 0.4 else "neutral")
)

但 SnowNLP 有个众所周知的坑：它是基于电商购物评论语料训练的，在其他领域（比如微博、新闻评论、应用商店评价）迁移效果会打折。如果你发现测出来的结果明显不对，比如“这手机耗电太快”被判成正向，那就要考虑换模型。

如果你想用更准确但配置也更复杂的方案，推荐用 transformers 库加载中文预训练模型，比如 uer/roberta-base-finetuned-jd-binary-chinese 这类在京东评论上微调过的情感分类模型，或者 IDEA-CCNL/Erlangshen-Roberta-330M-Sentiment。不过预训练模型运行速度慢、显存占用大，如果只是处理几万条数据，有点杀鸡用牛刀的感觉。我的真实建议是：先跑 SnowNLP，做一个随机抽样的人工校验，如果准确率在 75% 以上，那就不折腾了；如果太低，再上 BERT 系列。

情感分析完成后，可以按时间维度做趋势统计。比如按日期聚合正向情感占比，能直观看出产品口碑的时间变化。

3.3 主题建模：用 LDA 发现留言中的隐藏话题

主题建模做的事情是：从一堆留言里自动找出若干“主题”，每个主题由一组高频词构成。比如某款手机的用户评论，LDA 可能发现三个主题：一个是“电池、续航、充电”，一个是“屏幕、显示、清晰”，一个是“发货、物流、快递”。这相当于帮你快速了解用户都在聊什么，不需要逐条阅读。

LDA 建模我习惯用 gensim：

python复制from gensim import corpora, models

# tokens 是分词后的列表，每一条留言对应一个词列表
dictionary = corpora.Dictionary(df["tokens"])
dictionary.filter_extremes(no_below=5, no_above=0.5)  # 过滤低频和高频词

corpus = [dictionary.doc2bow(text) for text in df["tokens"]]

# 训练 LDA 模型
lda_model = models.LdaModel(
    corpus=corpus,
    id2word=dictionary,
    num_topics=5,
    passes=20,
    random_state=42
)

# 打印每个主题
for idx, topic in lda_model.print_topics(num_words=10):
    print(f"Topic {idx}: {topic}")

LDA 有两个关键参数要调：主题数 num_topics 和迭代次数 passes。passes 太少模型不收敛，太多浪费时间，我一般默认 20。主题数的确定比较讲究，最直接用的是 model_perplexity 困惑度指标：主题数多了，模型太细碎；主题数少了，主题太笼统。更实用的方法是拿不同主题数跑几轮，人工看结果哪个最有解释力。比如 3 个主题讨论的分别是“电池”“屏幕”“物流”，5 个主题时多出了“价格”和“赠品”，那 5 个主题可能信息量更大。

LDA 一个非常关键的操作是：主题建模前一定要做词过滤。filter_extremes(no_below=5, no_above=0.5) 的含义是，只保留在至少 5 条留言中出现过、但在超过 50% 的留言中都出现的词。“商品”“东西”这类词几乎每条留言都有，不滤掉它们，每个主题都会被这些词污染。

注意：LDA 是概率模型，同样的数据跑两次结果可能不完全一致。要在训练时固定 random_state=42 之类的种子，保证结果可复现。如果后续要写报告或做演示，这一步能让你的结果更严谨。

3.4 关键词提取：TF-IDF 与 TextRank

关键词提取是从每条留言或整个语料中找出代表性词汇。做这一块有两种常用算法：TF-IDF（词频-逆文档频率）和 TextRank（基于图模型的排序算法）。

TF-IDF 的核心思想是：一个词在一篇文章中出现的频率高，但在整个语料中很少出现，那这个词就很能代表这篇文章的特征。TextRank 则更偏向提取文本内部结构中的关键短语。

jieba 内置了两种算法的实现：

python复制import jieba.analyse

# TF-IDF 关键词提取
keywords_tfidf = jieba.analyse.extract_tags(
    " ".join(df["clean_content"]),
    topK=20,
    withWeight=True
)

# TextRank 关键词提取
keywords_textrank = jieba.analyse.textrank(
    " ".join(df["clean_content"]),
    topK=20,
    withWeight=True
)

我实际用下来的感受是：TF-IDF 提取的词更“具体”，容易提取出产品名、属性词；TextRank 提取的词更“泛”，但能较好地保留短语结构。如果做舆情分析，两个结果可以都留一份，互相印证。

关键词提取在整体分析链路里还有一个作用是：它可以作为情感分析和主题建模的前置步骤。比如先用 TF-IDF 提取出高频负面关键词（“卡顿”“退货”“差评”），再以此为线索，回看这些词出现在哪些留言里，分析这些留言的情感分布，就能快速定位产品的主要负面反馈点。这一步做起来很朴素，但特别出效果。

3.5 文本分类：做留言自动打标

文本分类的目标是把留言自动归入预先定义的类别，比如“质量问题”“物流问题”“售后问题”“好评夸奖”。这本质上是监督学习，需要先有一部分人工标注数据。

标注数据不用太多，如果分类是 4 类，每类打标 200 条左右，1000 条样本基本够训练一个可用的简单分类器。特征工程方面，我不会直接拿原始文本去喂模型，而是先做 TF-IDF 向量化，再用朴素贝叶斯或逻辑回归训练。

python复制from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.naive_bayes import MultinomialNB
from sklearn.model_selection import train_test_split
from sklearn.metrics import classification_report

# 假设 df 中已有 label 列，取值为 "quality" / "logistics" / "service" / "praise"
vectorizer = TfidfVectorizer(
    tokenizer=lambda x: x.split(),
    max_features=5000,
    ngram_range=(1, 2)
)

# tokens 列表转成空格分隔的字符串，作为 TF-IDF 输入
df["train_text"] = df["tokens"].apply(lambda x: " ".join(x))

X = vectorizer.fit_transform(df["train_text"])
y = df["label"]

X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, random_state=42, stratify=y
)

clf = MultinomialNB()
clf.fit(X_train, y_train)

y_pred = clf.predict(X_test)
print(classification_report(y_test, y_pred))

这里有两个细节值得说。第一，TfidfVectorizer 的 ngram_range=(1, 2) 表示同时使用单词和双词组合作为特征，这能捕捉到“物流很慢”里“物流+很慢”这样的短搭配信息，比只用单个词效果更好。第二，train_test_split 里加 stratify=y，保证每一类在训练集和测试集中的比例一致，避免某一类样本过少导致评估失真。

如果后续发现朴素贝叶斯效果不好，可以考虑逻辑回归或线性 SVM。对于文本分类这种高维稀疏特征，线性模型的泛化能力往往比树模型好得多，而且训练速度也快。

4. 常见问题与排查技巧实录

这一节是我最想写的部分。很多问题不实际操作根本不会遇到，遇到了百度搜也很少有人讲清楚。我把这些年踩过的坑按采集和挖掘两个阶段归类，做成一份速查表。

4.1 Selenium 采集阶段的高频故障

滑块验证这事多说两句。很多新手一看到滑块就慌，其实触发滑块验证的根源是访问频率太高，或者浏览器指纹太干净。最稳妥的应对是：降低采集频率、加上随机的时间间隔、使用真实的 user-agent 和 window.size 设置。不要试图去破解验证码，一是法律风险，二是费半天劲写出来的“过滑块”代码可能过两天就被平台更新废了。

关于随机延时，我常用的写法：

python复制import random
import time

# 随机延时 2~5 秒，模拟真人操作
time.sleep(random.uniform(2, 5))

这种方法虽然简单，但对于中小规模数据采集非常有效。

4.2 文本挖掘阶段的结果异常与调优方向

一个问题很常见：分词结果里全是无意义的“了”“的”“是”。这时要去检查停用词表，同时检查 len(w.strip()) > 1 的过滤条件。中文里大量单字是助词、语气词，过滤后能大幅降噪。

第二个常见问题是主题建模的结果很怪，比如每个主题都包含相同的词。这大概率是数据预处理没做好，高保真词（如“商品”“东西”）没有被滤掉。解决办法是调大 filter_extremes 的 no_above 参数，把它从 0.5 降到 0.3，或者直接把“商品”“东西”加入停用词表。

第三个问题是情感分析准确率太低。先人工看 100 条结果，如果错误集中在否定句和反讽，比如“这个快递是真的快啊（明明很慢）”，说明需要更高级的模型来捕捉上下文。这时候可以考虑 BERT 系模型，或者采用“情感词典 + 否定词反转规则”的改良词典方法。

第四个问题：文本分类样本不均衡，比如“好评夸奖”类有 2000 条，“质量问题”类只有 100 条，分类器会偏向多数类。对策是：一是采集时尽量均衡采样；二是用 class_weight='balanced' 或者过采样/欠采样方法；三是如果样本量实在太小，不要勉强做分类，改成基于关键词规则打标，效果可能更好。

注意：文本挖掘结果一定要做人工抽样验证。LDA 的主题词、情感分析的打分，都存在模型与领域不匹配的问题。我的习惯是每 500 条留言随机抽 50 条人工核对，用准确率衡量结果是否可发布。

4.3 工程层面的性能优化技巧

最后说说“优化”这件事在工程上的具体落点，按性价比排序：

第一，无头模式。服务器上跑采集时用 options.add_argument("--headless=new") 可以不弹浏览器窗口，节省大量资源。但无头模式更容易被反爬识破，如果遇到验证码，建议还是用有头模式配合屏幕。

第二，分批处理。几万条留言不要一次性全部读进内存做向量化，容易内存溢出。可以按 5000 条一个 chunk 分批读取、分批处理，结果直接写入新的文件。

第三，合理使用缓存。比如分词结果可以缓存到本地文件，第二次运行时直接读取，不用重新分词。分词是文本挖掘流程里比较耗时的一步，缓存能把效率提升 50% 以上。

第四，特征工程要克制。TfidfVectorizer 的 max_features 不要设置得太大，我一般用 5000，足够覆盖绝大多数留言语料的常见词。设置过大会引入大量噪音特征，训练时间变长，效果反而变差。

python复制options = webdriver.ChromeOptions()
options.add_argument("--headless=new")
options.add_argument("--window-size=1920,1080")
options.add_argument("--disable-gpu")
driver = webdriver.Chrome(options=options)

4.4 完整实操示例：从网页评论到分析报告

为了让上面的内容更直观，我串一个完整的小案例：抓取某个商品评论区的前 100 条留言，做情感分析和关键词提取。

整个流程可以写成这样一个脚本骨架：

python复制# 1. 采集
driver = webdriver.Chrome()
driver.get("https://example.com/product/12345")
wait = WebDriverWait(driver, 10)

# 等待评论区出现
wait.until(EC.presence_of_element_located((By.CSS_SELECTOR, ".comment-list")))

comments = []
for _ in range(5):  # 滚动 5 次，每次拿一批留言
    driver.execute_script("window.scrollTo(0, document.body.scrollHeight);")
    time.sleep(2)
    items = driver.find_elements(By.CSS_SELECTOR, ".comment-item")
    for item in items:
        content = item.find_element(By.CSS_SELECTOR, ".comment-content").text
        comments.append(content)
driver.quit()

# 2. 保存
df = pd.DataFrame({"content": comments})
df.to_csv("product_comments.csv", index=False, encoding="utf-8-sig")

# 3. 分析
df = pd.read_csv("product_comments.csv")
df["clean"] = df["content"].apply(clean_text)
df["sentiment"] = df["clean"].apply(lambda x: SnowNLP(x).sentiments)
df["keywords"] = df["clean"].apply(
    lambda x: ",".join(jieba.analyse.extract_tags(x, topK=5))
)

# 4. 结果输出
print(df.groupby(pd.cut(df["sentiment"], bins=[0, 0.4, 0.6, 1], labels=["neg", "neu", "pos"])).size())

这个流程看起来简单，但已经覆盖了从采集到分析的完整链路，也是上面所有知识点的一个浓缩。实际项目里，把这几步扩展成模块化函数，配合日志和异常处理，就是一个很扎实的留言数据分析工具。

5. 几个容易被忽略但很实用的细节

分享一些零散但实打实好用的小技巧，都是我在实际项目里沉淀下来的。

5.1 留言数据的时效性处理

评论数据有一个天然属性：时间价值衰减。去年的评论和今天的评论，分析重点完全不一样。所以我建议在采集时一定保留时间字段，后续分析按时间段切分，比如按月统计情感均值，按周统计关键词变化。如果你的目标是舆情监控，甚至可以做成每天定时采集、增量更新，这需要把 Selenium 脚本包一层调度逻辑（比如用 cron 或 APScheduler）。

5.2 分析与业务场景绑定

很多文本挖掘项目最后变成了“跑了一个模型，出了一堆图表，然后呢？”这是因为没有把分析结果跟具体决策绑定。比如电商场景，情感分析结果应该对应着售后策略调整；主题建模结果应该对应着产品改进方向；关键词提取结果应该对应着客服话术优化。做这个方案之前，先想清楚“分析结果给谁看、要支持什么决策”，分析和报告的表达方式会很不一样。

5.3 关于重新运行与结果复现

文本挖掘流程里的随机性其实很大：LDA 每次跑出来的主题词不一样，情感模型打分也有概率性。为了保证分析结果可复现，我在代码里会固定所有能固定的随机种子，并且把预处理结果保存成中间文件。这样即使后续重新训练模型，也不需要从头跑一遍预处理。

5.4 模型的领域迁移问题

这是我想重点强调的一点：无论你用 SnowNLP 还是 BERT 系模型，只要是公开预训练模型，训练语料都和你的目标场景存在偏差。做正式项目时，强烈建议准备几十条人工标注的验证样本，用来评估模型在你这个领域的效果。评估结果不理想，就考虑微调或换模型，不要迷信“大模型一定更好”。

在我自己跑过的项目里，比较顺手的一套组合是：Selenium 采集加 CSV 增量存储，jieba 分词加自定义词典，SnowNLP 做情感初筛、人工抽样校验，LDA 做主题发现，TF-IDF 加朴素贝叶斯做留言分类。这套组合的好处是轻量、够用、好维护，处理几万条留言的体量完全不虚。如果你也是刚开始接触这个方向，不妨照这套链路先完整跑一遍，再根据数据效果逐步替换模型。整个过程最核心的一点是：先让流程通起来，再追求精度，别一开始就陷在工程细节里出不来。