Spring Boot实现多语言情感分析与词云关键词提取实战

1. 这个简易版到底解决什么问题

这几年聊到 NLP 项目，大家第一反应基本都是 Python 加机器学习框架，很少有人会想到用 Java 后端把整套流程串起来。直到我自己接了一个需求，要给一个多语言社区的评论做情感分析，同时把关键词和词云图展示到页面上，才发现 Spring Boot 在这个场景里并没有大家想象中那么难用。这个项目的标题说得很直白：Spring Boot + 全球多语言情感分析 + NLP + 词云关键词提取，而且是简易版。所谓简易版，就是要用尽量少的依赖、尽量低的成本，把一个完整的分析链路跑通。

我见过太多类似的选题，最后都变成了“只写了一个调用 ChatGPT 接口的 Demo”，或者“用 Python 处理完再把结果贴到页面上”。这两个方向其实都偏离了 Spring Boot 项目本身的价值。真正适合 Java 后端工程师的做法，是把文本清洗、语言识别、分词、情感打分、关键词提取、词云图片生成全部收进一个 Java 服务里，对外暴露 REST 接口。这样做出来的东西可以直接嵌入到网页或者 App 后台，也能用来演示给不懂技术的朋友看效果。

这个简易版项目没有任何生产级玄学，不搞模型训练，不引入分布式计算，甚至连数据库都可以先不接。它适合三类人看：第一类是准备做毕业设计的同学，需要一套能讲清楚原理、也能现场演示的技术方案；第二类是想把 NLP 能力集成到 Java 后端工作流里的开发；第三类纯粹是好奇，想看看新闻评论、社交媒体短文本从原始字符串到一张漂亮词云图之间到底发生了什么。我会在下面把每个环节的选型理由、代码结构、踩坑经验都掰开讲清楚，尽量让读者看完之后能自己把项目搭起来。

1.1 需求拆解：要做什么和不做什么

拿到这个标题后，第一步不是找现成的模型，而是把功能边界划清楚。简易版的核心需求可以拆成三块。第一块是情感分析，给定一段文本，输出它是正面、负面还是中性，最好带一个极性分数。第二块是关键词提取，从一段或一组文本中找出最能代表内容的词。第三块是词云可视化，把关键词按照出现频率或权重的大小渲染成一张 PNG 图片。

如果再看细一点，需求里藏着一个容易被忽略的定语：全球多语言。这意味着输入文本不一定是中文，可能是英文、日文、韩文或者其他语言的评论。如果代码里写死 if (lang.equals("zh")) 那显然不够，但要做成 Facebook 那种覆盖一百多种语言的系统，又和“简易版”矛盾。我的方案是做一个可扩展的语言识别和资源注册机制：程序先根据字符集判断文本属于哪种语言，然后选择对应的分词策略和情感词典；词典缺失的情况下，再走一套默认的弱情感判定逻辑。这样既能演示多语言的思路，又不会让代码复杂到没法收场。

这个项目需要主动放弃很多东西。比如不做细粒度情感分类，不去区分“喜欢”和“喜爱”的细微差别；不做讽刺和反语识别，那东西连大模型都经常翻车；不追求每条词云都词准，只要在真实数据上看起来合理。把目标定得太高，最后往往会淹没在调参和模型训练里。我做这种项目一贯的原则是：先让链路通，再让结果能用，最后才考虑能不能变准。

1.2 技术选型的思路与版本考虑

我最终选定的技术栈很朴素：Spring Boot 负责接口和生命周期管理，HanLP 负责中文分词和一部分默认关键词抽取，kumo 负责词云渲染，情感词典用手工整理的 CSV 和开源词表，语言识别直接用 Unicode 字符区间判断。整个过程不依赖外部 AI 服务，所有东西离线可跑，既避免了高昂的调用费用，也方便课堂上做演示。

这里面有个特别现实的问题，就是版本。如果你跟着最新版的 Spring Boot 3.x 走，会发现包名从 javax 变成了 jakarta，而且要求 JDK 17 及以上。很多初学者电脑上还是 JDK 8 或者 11，如果照抄网上的新教程，往往会出现“明明配置看起来一模一样，项目就是起不来”的尴尬情况。我的建议是这个简易版项目固定在 Spring Boot 2.7.18 上，这是 2.x 的最后一个维护版本，兼容性足够广，网上资料也最多。后面如果公司要求必须升 3.x，再单独处理迁移问题也不迟。

HanLP 我使用 portable-1.8.4 版本，依赖体积小，内置的模型可以覆盖中文分词、词性标注、命名实体识别和 TextRank 关键词抽取。之所以没有选 Stanford CoreNLP，是因为它虽然支持的语言很多，但模型文件巨大，启动内存占用高，对简易项目来说有点“杀鸡用牛刀”。kumo 这个词云库是基于 Java AWT 的，优点是调用简单，生成的图片效果不错，缺点是对中文默认不支持，必须手工指定一个能找到的中文字体。这个坑我在后文会专门展开。

2. 多语言情感分析的核心链路

2.1 先判断语言：一种不依赖机器学习库的方法

拿到一段未知文本，第一步不是分词，而是搞清楚这段话是什么语言。实现方式不需要特别复杂，Unicode 区间就够了。韩文一般落在 AC00-D7AF 和 1100-11FF 区间，日文的平假名和片假名落在 3040-30FF，而汉字基本落在 4E00-9FFF，拉丁字母则是基础的 ASCII 区间。用正则或者逐字符扫描的方式统计不同区间的字符数量，哪个占比高就判断为哪种语言。

实际写的时候有几个细节需要注意。日文和中文都会用到汉字，比如日文句子“今日は天気がいいですね”里既有汉字也有平假名，所以判断逻辑要先看有没有假名，有假名就先归为日文，没有假名但包含汉字再归为中文。韩文的每个音节像一个个小积木，看起来和中文汉字完全不一样，直接按区间判就可以。如果是纯英文字符，先统一转成小写，然后再做后续处理。这个方法不是百分百准确，但对于以常见主流语言为主的社区评论足够用了，而且代码量很小，也好解释。

我自己的经验是，语言判断这件事千万别一上来就用大量模型。很多初学者在第一步就想上 BERT 做语言分类，后来发现仅加载模型就花了七八百兆内存，还没开始实际分析，服务器已经快卡死了。简易版项目最重要的是让整条链路保持轻量。真正用于判断的代码量大概只有三十行，返回一个 zh、en、ja、ko 之类的小写字符标识就够了。

2.2 词典法情感分析为什么适合简易版

语言确定之后，情感分析就好办了。简易版采用的情感分析是词典法，原理非常简单：准备一个情感词典，里面记录每个词的极性分数，正面词记正数，负面词记负数，强度越大绝对值越大。分析文本时，把文本分词，然后逐个查词典打分，最后把分数累加。比如句子 “这个产品真的很棒”，分词后得到 “这个 / 产品 / 真的 / 很 / 棒”，其中 “棒” 是正面词加 1.5 分，“很” 是程度副词把强度放大一倍，最终得到正分数，判断为正面。

和基于深度学习模型的情感分析相比，词典法最大的好处是透明、快速、不需要训练。你完全可以解释清楚这条评论为什么被判定为负面，因为把分词结果和词典命中情况打印出来就能看到。这对新手项目答辩来说尤其重要，老师问“你的模型是怎么判断情感的呢”，你能讲出词典匹配和权重翻转的逻辑，比答一句“模型学到的特征”要有说服力得多。

当然，词典法也有自己的痛点。首先是分词错误会直接导致匹配不到词；其次是同一个词在不同上下文里可能有完全相反的含义，比如“这手机真垃圾”里面的“真”是程度副词，而“真货”里面的“真”又是正面词。处理这个问题最常用的技巧是维护一个否定词表和程度副词表。当句子中出现“不、没、别、never、not”这类否定词时，把后面一定窗口范围内命中的情感词分数取反；出现“很、非常、极其、very、really”这类程度词时，对后面的情感词做加权。这种简化版逻辑虽然覆盖不了所有语言现象，但准确率已经足够应付大多数评论场景，而且实现起来难度低，很适合做第一版。

2.3 多语言情感词典如何组织

多语言版不能只做一种语言的词典，否则判断完语言之后还是要面对词典覆盖问题。我的做法是用一个 Map 结构，key 是语言代码，value 是语言专属的 SentimentDictionary 对象。这个对象内部包含 Map<String, Double> wordScore、否定词集合和程度副词集合。中文词典直接读一个 UTF-8 编码的 CSV 文件，里面常见的正面词负面词都预先打好了分数；英文词典则可以使用知名的 AFINN-165 词表，文件格式是 tab 分隔的英文单词和分数；日文和韩文因为手头没有特别合适的开源词表，可以先把基础的情感词整理进去，作为扩展的起点。

这里想多说一句架构上的细节。即便是简易版，也要为将来替换更强的词典留出口。不要把这些逻辑全部塞在一个 Service 里，而是抽象一个 PolarityWordProvider 接口，接口里定义 Optional<Double> lookup(String word, String lang)。中文实现查本地 CSV，英文实现查 AFINN，以后如果觉得模型准确率不够，可以再加一个基于词向量的实现，对调用方完全无感。这样当你从简易版往上迭代的时候，不需要推翻整个 Service 层，只需要替换底层实现类。

我在实际项目里遇到过一种很尴尬的情况：数据库里的评论明明带有多个国家的语言，但开发时只准备了中文词表，结果所有英文评论的得分全部是零，用户反馈“为什么我的英文评论永远显示中性”。所以词典注册机制一定要在程序启动时统一检查，加载完就打印出当前支持的语种和词条数量。后来我把这个过程做成了一个启动日志，每次启动都能看到 “language zh dictionary loaded: 12500 words” 之类的提示，相当于给自己吃一颗定心丸。

3. 关键词提取与词云生成的关键细节

3.1 关键词提取不能只靠词频

讲到关键词提取，我得先纠正一个常见的认知误区。很多人以为把一篇文章里出现次数最多的词挑出来就是关键词，这个想法在真实文本里基本不可用。原因很简单，一篇文章里出现最多的往往会是“我们”“这个”“但是”“的”这类停用词，把它们画进词云图既没有信息量，画面也巨丑。

想要做出像样的关键词，正常流程是：先分词，再过滤停用词和标点，然后选择一种关键词打分算法。简易版里最省事的算法是 HanLP 内置的 TextRank，它借鉴了网页排序的思想，把每个词看成一个节点，如果两个词在同一个窗口内共现，就在节点之间连一条边。经过多轮迭代计算后，那些与很多词都有连接的词会获得更高的权重，从而被识别为关键词。HanLP 对外提供了非常直接的静态方法 HanLP.extractKeyword(text, topN)，输入一段文本，输出一个关键词字符串列表，中文效果还不错。

这里要说明一点：HanLP 的 TextRank 更适合长文本，比如一整篇新闻或者一段产品介绍。如果输入是微博短评或者一句话评论，词与词之间的共现信息太少，TextRank 的效果就会明显打折。针对这种场景，我在项目里采用了一个两阶段的策略。如果输入是单条长文本，直接调 extractKeyword；如果输入是一批短评论，就先对每条评论分词，去掉停用词后统一放进一个统计容器中，最后按词频降序取前 N 个作为候选关键词。这样做的计算成本低，而且贴合词云图的展示需求，因为词云本质上就要呈现高频词。

3.2 词云渲染的两个容易翻车的点

词云渲染用的库是 kumo，但是直接调用它处理文本会有一个大坑：kumo 默认的文本分析器是按空格和英文形态来拆词的，它不理解中文。如果直接把“我爱自然语言处理”这句话丢进去，它会把整句话当成一个词，或者按肉眼根本看不懂的规则切碎。正确的用法是让 HanLP 先把文本切开，再用空格拼成一句类似 “我 爱 自然语言处理 的 美妙” 的字符串，最后交给 kumo 来做词频统计和布局。这也是我在代码中特意把分词和渲染分成两层的原因。

第一个容易翻车的点是字体。kumo 渲染图片时如果遇到字体中没有覆盖的字符，就会画出一个个方框，看起来像系统崩溃了一样。解决方法是启动时检测系统可用字体，如果当前运行环境是 CentOS 或者精简版 Docker 镜像，往往还没有安装中文字体，需要把 fonts-noto-cjk 之类的字体包装进去，或者直接在资源目录放一个开源字体文件，通过 Font.createFont 加载。第二个是图片输出方式。词云生成是典型的 CPU 密集操作，如果接口是同步调用，一次生成可能要几百毫秒到几秒，接口响应会明显变慢。简易版可以在 Controller 里先同步生成图片再返回文件流，但要给前端一个明确的响应时间预期；如果是做项目展示，强烈建议把图片生成放到一个异步线程池里，先返回一个任务 ID，再由前端轮询获取结果。

为了便于理解，我把语言、分词、词典之间的关系整理成一个对照表，这样就能清楚地看到哪些模块可以复用，哪些模块需要按语言做扩展。

3.3 接口返回结果怎么设计

在设计 REST 接口时要把最终的数据结构想清楚，不能只落一张图片。我的想法是返回一个 JSON 对象，里面包含最原始的情感分析字段、关键词权重信息和词云图片地址三大部分。页面拿到 JSON 之后，既可以直接展示情感标签，也可以给词云图片加缓存。这个结构还能在没有 UI 的情况下用 Postman 直接验证接口正确性，对调试非常友好。

具体字段可以这么定义：lang 表示识别出来的语言；sentiment 表示最终情感类型，取值是 POSITIVE、NEUTRAL、NEGATIVE 三种；polarityScore 是原始极性分数；keywords 是一个数组，里面每个元素包含 word 和 weight；wordCloudPath 是图片的相对访问路径。如果前端希望在页面用纯 div 渲染动态词云而不依赖 PNG，keywords 数组里的数据也够用了，一张图上没有展示的词还可以通过数组自行构造。这个设计相当于给项目增加了不少灵活度，又不会增加多少代码量。

4. 核心代码与完整运行流程

4.1 工程结构和依赖清单

项目代码量其实不大，如果全量统计大概也就十几个类。为了让目录结构清晰，我按职责分成controller、service、nlp、wordcloud、dict 几个包。controller 只负责 HTTP 请求和响应，service 做编排，nlp 下的类负责具体的分词和语言识别，wordcloud 负责把关键词结果渲染成图片，dict 目录专门放各类字表文件。这个分层方式非常常规，却能避免以后想扩展时满项目的代码乱飞。

在项目里加入核心依赖，使用 Maven 管理，pom 中加入 spring-boot-starter-web 之后，重点要添加 HanLP 和 Kumo 依赖。HanLP 的坐标是 com.hankcs:hanlp:portable-1.8.4，kumo 坐标是 com.github.kennycason:kumo:1.28。如果你只是为了测试，可以把所有功能写在一个启动类里跑；如果用于正式封装，建议把最终的服务类注册成 Spring Bean。我在本地调试时习惯先写一个 main 方法验证字符判断逻辑，然后才接入 Controller，这样可以减少反复重启 Spring Boot 的等待时间。

有个地方需要特别提示：kumo 依赖 Java AWT，在 Linux 服务器上运行图片生成功能时，如果没有图形化环境，启动阶段就要加上 VM 参数 -Djava.awt.headless=true。有些生产环境会禁止某些 Java 模块的反射访问，如果遇上权限问题，再根据实际错误加对应的启动参数。如果搞不定这些，最直观的结果就是生成图片时报 HeadlessException，这个问题在网上搜索也能很快找到答案。

4.2 情感分析模块的实现要点

情感分析服务的核心代码大概长这样。我先把文本交给语言探测器，拿到语言代码，再调用对应的分词器得到词列表。遍历词列表时维护一个上下文状态，比如当前是否处于否定范围、刚才的强度系数是多少。每次命中词典就打一次分，直到处理完整个文本。

java复制public SentimentResult analyze(String rawText) {
    String lang = languageDetector.detect(rawText);
    List<String> tokens = tokenizer.tokenize(rawText, lang);

    double totalScore = 0;
    boolean negated = false;
    double intensifier = 1.0;

    for (String token : tokens) {
        String key = token.toLowerCase();
        if (negationWords(lang).contains(key)) {
            negated = true;
            continue;
        }
        if (intensifierWords(lang).containsKey(key)) {
            intensifier = intensifierWords(lang).get(key);
            continue;
        }
        Double baseScore = sentimentDictProvider.lookup(key, lang).orElse(null);
        if (baseScore != null) {
            double value = baseScore * intensifier;
            if (negated) {
                value = -value;
            }
            totalScore += value;
            negated = false;
            intensifier = 1.0;
        }
    }
    return new SentimentResult(lang, toSentimentLabel(totalScore), totalScore);
}

这里有一个实现细节很多人第一次写容易忽略：否定词的处理不能沿用到整句话。比如“我觉得这家店味道不错，但不便宜”这句话，前半段是正面，后半段“不便宜”是否定句子内的某个形容词，不应该把“不错”的分数也翻转。简易版采用了状态复位策略，一旦在否定词之后遇到一个词典词，处理完马上把 negated 置回 false。虽然这个策略无法处理复杂的跨分句否定，但至少能把最常见的情况解决掉。写成代码时，这段逻辑要放在循环体的适当位置，否则很容易出现整个句子越算越糊涂的情况。

4.3 关键词统计与词云生成实现要点

关键词提取的代码分两条路径。如果输入是新闻这种长文本，直接调用 HanLP 的抽取方法，把关键词列表按顺序输出。

java复制List<String> keywords = HanLP.extractKeyword(text, 10);

如果输入是一个短评论列表，我会先逐条分词，剔除停用词和纯数字字符串，然后用一个 LinkedHashMap 统计词频。剔除停用词时，不能只判断词长度是否为 1，因为英文的 “a” 和 “I” 都有长度，却属于停用词；也不能只比较一份固定的停用词表，因为不同领域的文本停用词略有差异。简易版可以准备一份通用停用词表，遇到“好的”“想要”“真的”这类在具体业务中高度频繁但不体现业务的词，也顺手加进去。

词云生成直接使用上一步统计出的词频列表，按照数量取前 80 到 100 个就好。这里为什么要限制数量？因为词云布局不可能无限放大，超过一定数量后，为了不重叠，很多文字会被压缩到看不清，反而影响效果。比如一副 800 乘 600 的图显示 100 个词是合理上限，超过后会有一堆小字密集成一片噪声，视觉效果很差。

渲染的核心代码如下。注意这里我没有用 kumo 自带的 FrequencyAnalyzer，而是从我们自己的统计结果构造词频对象，因为这样可以完全绕开它对中文分词不友好的问题：

java复制public File generateWordCloud(Map<String, Integer> wordFrequency, String lang, String outputDir) {
    List<WordFrequency> frequencies = wordFrequency.entrySet().stream()
        .filter(entry -> entry.getValue() >= 2)
        .sorted((a, b) -> b.getValue() - a.getValue())
        .limit(100)
        .map(entry -> new WordFrequency(entry.getKey(), entry.getValue()))
        .collect(Collectors.toList());

    Font font = loadFontFor(lang);
    WordCloud wordCloud = new WordCloud(new Dimension(800, 600), CollisionMode.RECTANGLE);
    wordCloud.setPadding(2);
    wordCloud.setBackgroundColor(Color.WHITE);
    wordCloud.setColorPalette(buildColorPalette());
    wordCloud.setKumoFont(new KumoFont(font));
    wordCloud.build(frequencies);

    File output = new File(outputDir, System.currentTimeMillis() + "_" + lang + ".png");
    wordCloud.writeToFile(output.getAbsolutePath());
    return output;
}

loadFontFor 这个函数是我后来加的。刚开始代码里直接写死成 new Font("Arial", Font.PLAIN, 24)，英文文本没问题，中文文本在屏幕上全是方块。后来改成从系统字号列表里选择支持中文的字体；如果找不到，就尝试从 classpath 加载一个 ttf 字体文件，再把字体注册到 GraphicsEnvironment。这步处理完，词云图才算真正可用。

4.4 从启动到出图完整跑一遍

启动项目之前，先在 resources 目录下准备一份 stopwords.txt 和若干情感词典文件。情感词表不用追求特别大，几千条已经比很多演示项目效果要好。接着把 Spring Boot 的端口设为 8080，启动后在本地跑一个集成测试文本。测试文本我习惯用两段不同语言的内容，一段中文说“服务很好，环境也很棒，但位置有点偏”，一段英文说 “The device is absolutely fantastic and worth every penny”。

调用接口时，传入一个 text 参数，然后观察返回值。如果一切正常，返回值里情感类型应该分别是正面和正面，中文关键词里应该包含“服务、环境、位置”这类词，英文关键词里应该包含 “device、fantastic、worth、penny”。如果情感类型、关键词明显不对，先不要怀疑核心算法，优先检查是不是停用词表长度太极端或者词典文件编码有问题。词典文件一定要用 UTF-8 保存，用 GBK 存的中文词表在加载后会出现很多乱码词条，情感分析准确率会瞬间跌到基本靠猜。

步骤层面总结一下：第一步创建 Spring Boot 工程并引入依赖；第二步添加语言识别和分词工具类；第三步加载情感词典并实现打分逻辑；第四步实现关键词统计和词云渲染；第五步写一个测试 Controller；第六步用几个不同语言样例验证输出；第七步处理字体和中文显示问题；第八步把这个简单的接口扩展到批量处理能力，比如接收一个 List 然后返回整体高频词云。整个流程半天时间足够跑通，如果你把所有代码都写好再调试，可能更短。

5. 典型问题与排查记录

5.1 常见问题速查

我在搭建这个简易版项目时踩过不少坑，有些问题很典型，网上资料又讲得模棱两可。这里整理一个速查表，希望可以让大家少走弯路。

另一类问题出在评分规则上。有些句子明明带有“不便宜”这种含否定词的表达，但词典里存的是“便宜”正面词，程序计算时先命中“不”把 negated 状态设为 true，然后命中“便宜”做了翻转，最终结果是负面，这很合理。但如果句中顺序是“便宜不便宜”这种正反并列表达，简单状态机就会出毛病，因为它会把第一个“便宜”当作正面词加分，再把第二个翻转成负面扣分，最终总分可能接近 0。这个问题的处理方式取决于你到底想要什么：如果是在意商品评价里的价格讨论，最好还是在词典里补充“贵”“便宜”“划算”等词的上下文用法；如果只是做综合情感参考，中性结果也不一定完全错误。

5.2 往生产环境升级时应该改什么

如果有人看过这套简易版后觉得效果不错，想往生产环境推，我的建议是先动三个地方。第一，把词典法的情感分析替换成微调过的多语言预训练模型，比如轻量级的蒸馏版 XLM-R 或者 mBERT，用业务历史数据做领域适配。不要指望免费词典打得过垂直领域模型，尤其是遇到“绝绝子”“yyds”这种带网络流行语色彩的文本，词典法基本上无能为力。第二，把文本清洗环节再往前移，加入 emoji 转换、URL 过滤、重复标点压缩等操作，这些操作对后续情感判断和关键词提取的影响非常大，往往比换模型更能提升线上表现。第三，为词云生成增加缓存，同一个话题的评论结果设置几分钟的过期时间，避免每次页面刷新都触发一次重型计算。

里面我还想提一个容易被忽略的点：词云生成在内存不足的服务器上可能会崩溃。一个包含几十万条评论的语料，分词后产生的中间对象数量非常可观，如果 JVM 堆只有 256MB，大概率会触发 OOM。简易版可以忽略这个问题，但如果要处理大批量数据，一定要控制单次分析的文本条数，最好分批次处理，每批几千条以内，分析完一批更新一次统计结果，最后再统一生成词云。这种批处理思路在真实新闻评论和微博热门数据分析里非常重要，否则你写好的服务会在毫无征兆的情况下宕掉，还很难排查。

另外提醒一句，如果你是从零开始照着这个思路写，不要一开始就去追求界面花哨。先保证测试接口能在一秒内返回 JSON，词云图片能在两三秒内生成，再谈前端可视化。前端可以用纯 HTML 加一个 <img> 标签显示词云图，也可以投入精力做一个 SVG 动态词云，前者是演示项目里最稳定的路线，不容易因为兼容性问题干扰后端逻辑的验证。

我自己做这个项目最大的体会是：NLP 不是只有“训练一个大模型”这一条路。很多时候，工程化能力比模型精度更能决定一个分析功能能不能真正落地。你不需要在简易版里把每个语言模型都做到世界一流，但你必须保证从拿到文本到输出图片的整个链路是可靠、可解释、可扩展的。如果以后有人问我“Spring Boot 做多语言情感分析到底行不行”，我会直接把我这套代码给他，然后让他换几个不同语言的句子试试。能跑起来，比什么都重要。