企业官网建设流程全解析

简介：面向文本挖掘与数据可视化初学者及中级Python用户的PDF教程，围绕词云这一关键词可视化技术展开，帮助读者把项目报告、数据分析、社交媒体监控或教学场景中的文本快速转成直观图形。压缩包仅含1个PDF文件，大小约2.07MB，内容集中、便于查阅。教程从词云的定义、作用与生成原理讲起，说明文本预处理、词频或TF-IDF权重计算、图像生成与展示保存的基本流程，并介绍wordcloud与matplotlib的配合方式；7个案例由浅入深，既有最简调用，也覆盖中文不分词与分词处理、蒙版形状、自定义配色、关键词及权重提取等进阶用法，每个案例配有代码和运行结果。文中还给出PyCharm、Python 3.7、wordcloud 1.9.3和matplotlib 3.5.3的环境参考，便于复现和排错。目前已有109人学习，适合希望系统掌握词云生成流程、积累可复用代码的读者。

1. 词云的第一层错觉：字号不是词频，而是归一化后的像素预算

很多人第一次跑通词云，会默认一件事：词出现 100 次，字号就该是出现 50 次的两倍。真跑一遍就会发现完全不是这样——把max_words从 200 调到 50，同一个词在同一份文本里的字号变了；把height从 600 改成 1200，所有字整体变大；套上蒙版之后，长尾词干脆缩到最小字号挤在角落。词云真正画出来的，是“词频先经过排名归一化、再映射到一块固定的画布像素预算”的结果，统计只负责第一步，布局才是决定观感的那一步。这份 python 课程资源 里的七个案例，从最简调用一路走到蒙版、取色、关键词权重，其实正好把这条链路拆成了七段可以单独验证的断面。搞懂每一段在干什么，图才不会时好时坏。

2. 权重到字号：词云的信息损失发生在哪一步

一张词云“准不准”，八成取决于进入布局之前的权重是怎么算的，而不是取决于颜色好不好看。WordCloud().generate(text)这行最简调用背后藏了三件事：把文本切成 token、统计 token 频次、按某种规则把频次折算成字号。前两件决定了图里会出现哪些词，第三件决定了这些词看起来谁更重要。三者任意一个没对齐，图就会失真，而且失真得很隐蔽——图还是能画出来，只是你以为自己看到的是“关键词分布”，实际看到的可能是“分词器的切分习惯”。

2.1 三种权重口径：计数、TF-IDF、jieba 关键词

最朴素的权重就是计数。generate(text)内部会把 token 流丢进process_text，统计每个词出现多少次，再顺手做两件事：用停用词表过滤掉the、a、of这类无信息量的高频词，以及用collocations机制额外生成二元组合。这个口径的优点是零门槛，缺点也很明显——文本长度一变，所有绝对频次都跟着涨，但它对“相对重要性”的表达能力很弱。一段 10 万字的新闻稿里，“的”出现 8000 次，“算法”出现 300 次，不滤虚词的话，整张图会被虚词吃掉。

第二种是 TF-IDF。它的价值在于压掉“在整个语料里到处都出现”的词，把“在这个文档里异常高频”的词顶上来。jieba.analyse.extract_tags(text, topK=200, withWeight=True)走的就是这条路，返回的是(词, 权重)的列表，权重是归一化后的浮点数。这类权重的好处是跨文档可比：你做十篇稿子的词云，用计数会出现“每张图里都是那批高频词”，用 TF-IDF 才能看出每篇各自的侧重。代价是需要一个像样的背景语料，否则 IDF 项退化成常数，效果跟计数差不多。

第三种是外部注入。只要你能给出{词: 权重}这个 dict，generate_from_frequencies就认，它不关心你的权重来自 TF-IDF、情感得分、还是业务侧的点击量。这是整条链路上最灵活的一个接口，也是最容易被误用的一个——很多人把已经归一化到 0~1 的分数直接丢进去，结果所有词的权重差距被压缩到千分位，字号几乎一样大，图看起来“平”得像没做过分析。常见的实现思路是：进布局之前先看一眼权重的分布，最大最小差几个数量级，心里要有个数。

2.2 字号映射：min/max_font_size 与 relative_scaling 的真实作用

字号是怎么算出来的？把词频线性映射到一个字号区间，就这么直白。下面这段是照着重写的一版映射逻辑，用来手算比读源码更快看出问题：

# 复现 WordCloud 的字号映射：把词频线性映射到 [min_font_size, max_font_size] freqs = {'数据': 1200, '可视化': 640, '挖掘': 210, '停用词': 48, '蒙版': 12} maximum, minimum = max(freqs.values()), min(freqs.values()) max_font, min_font = 96, 4 # 分别对应 max_font_size / min_font_size for word, f in freqs.items(): # 线性插值：最小值必然落在 min_font_size，最大值必然落在 max_font_size size = round((f - minimum) / (maximum - minimum) * (max_font - min_font) + min_font) print(f'{word:6s} freq={f:5d} font_size={size}')

跑出来的结果会很说明问题：停用词只有 48 次，蒙版只有 12 次，两者的频次差四倍，字号却几乎一样（都贴着 4px 的下限）。这不是 bug，是线性映射的必然结果——真实文本的词频分布接近齐夫定律，头部几个词占掉绝大部分频次，中长尾被压缩在区间的最低端，肉眼看不出差别。所以词云“看起来没有层次”，通常不是布局算法的问题，而是权重分布本身长尾太重。

max_font_size和min_font_size就是这条映射的两端。前者不设时默认取画布高度，这也是为什么把height从 600 改到 1200，整张图的字会整体变大——你以为是分辨率变了，其实是字号上限被画布高度带着走了。后者默认很小（个位数像素），作用是给长尾词留一个“还看得见”的位置，而不是让它们消失。

relative_scaling则是这条映射的“松紧旋钮”。它取 0 的时候，字号只跟词的排名有关，第 1 名最大、第 2 名次之，跟具体频次差多少无关；取 1 的时候，字号严格跟相对频率成正比，头部词会大到夸张，长尾小到看不清。默认值在两者之间，是个折中。想让图“有层次又不失衡”，调这个参数比调字号上下限更有效。

2.3 generate 与 generate_from_frequencies 走的是两条路

generate(text)接收原始文本，内部自己做 tokenize、做停用词过滤、做二元组合，最后才进布局。generate_from_frequencies(dict)直接跳过前面所有环节，你给什么它就画什么。这两条路的差异不只是“省事”，它决定了你能不能控制权重来源。

一旦走到generate_from_frequencies，有几件事必须自己负责：停用词要自己滤（WordCloud自带的停用词表是英文的，对中文几乎无效）；分词要自己做；词形归一（比如英文复数）要自己处理。换来的是完全可控的权重。教程里第七个案例就是这么做的：

import jieba.analyse # extract_tags 用的是 TF-IDF，topK 控制保留多少个词 freq = jieba.analyse.extract_tags(text, topK=200, withWeight=True) freq = {w: weight for w, weight in freq} # 转成 generate_from_frequencies 要的 dict wc = WordCloud(mask=mask, font_path='你的中文字体.ttf', mode='RGBA', background_color=None ).generate_from_frequencies(freq)

topK=200这个参数值得掰开看。它限定了进入布局的词数上限，而WordCloud自己也有一个max_words（默认 200）。两个上限同时存在时，生效的是更小的那个。很多人调了topK却没反应，就是因为max_words卡在前面。反过来，如果你只调max_words而不动topK，多出来的名额也没词可填。

还有一个容易被忽略的边界：generate_from_frequencies里如果所有词的权重完全相等，最大值减最小值等于 0，映射公式会除零。实际代码里对这种情况有兜底，但结果通常是所有词同一个字号，图看起来像是排版事故。喂权重之前扫一眼max - min，是个成本极低的好习惯。

3. 中文词云的三根地基：分词、字体、编码

英文词云能一行代码出图，是因为空格天然就是 token 边界；中文没有这个便利，一整套地基得自己搭。这三根地基里任何一根塌了，图都不会报错，只会安静地画出一张废图。而废图的迷惑性远高于报错——报错你会去查，废图你会以为“词云就长这样”。

3.1 不分词也能出图，但出的是“词的碎片”

直接拿一段中文丢给generate()，代码不会崩，图也能出来，只是里面全是“悟空道”“那长老”“行者道”这种两三个字的碎片，甚至单字。原因很直接：WordCloud的 tokenizer 靠空格切分，中文整段没有空格，它就会按自己的规则硬切，切出来的东西既不是词，也没有语义。

所以中文场景下jieba.cut(text)这一步绕不过去。它的输出是个生成器，需要用空格 join 回一个字符串，才能被WordCloud当成正常的 token 流：

import jieba with open('xyj.txt', 'r', encoding='utf-8') as f: raw = f.read() # jieba.cut 返回生成器；用空格连接，把“词序列”还原成 WordCloud 认识的 token 流 tokens = ' '.join(jieba.cut(raw)) # 抽查前 100 个字符，确认分词粒度是否符合预期 print(tokens[:100])

那句print不是摆设。分词结果必须人眼过一遍，因为jieba的默认词典对某些领域词是切不准的——专有名词会被拆成两半，人名地名会被当成普通词。看到离谱的切分，要么jieba.add_word()加词，要么换用jieba.analyse那条 TF-IDF 的路。这一步跳过，后面调多少参数都是在错误的输入上调。

jieba有三种分词模式：精确模式尽量把句子切得最合理，全模式把所有可能成词的都扫出来（快，但歧义多），搜索引擎模式在精确模式基础上对长词再切一刀以提高召回。词云场景默认用精确模式就够了，除非你的文本里全是复合专有名词。

3.2 font_path 为什么绕不过去：字形缺失与方框

font_path是中文词云里最不能省的一个参数。WordCloud内部用 PIL 的ImageFont.truetype()加载字体，找不到字形时不会报错，而是渲染成一个方框（或者干脆一片空白）。默认字体是给拉丁字母准备的，汉字在里面没有对应字形，于是你得到一张全是方框的图。

这里有个细节值得说清楚：方框不是“字体文件没找到”的表现，字体路径错了才会抛OSError；方框是“字体文件找到了，但这个码位没有字形”的表现。两种失败长得完全不一样，排查方向也不同。前者查路径，后者查字体覆盖范围。用系统自带的思源、文泉驿这类中文字体一般是安全的，用某些只覆盖拉丁字符的英文字体就必然翻车。

字体还间接影响布局。词的字号确定之后，WordCloud需要拿到这个字号下词的实际外接矩形，才能判断能不能放进画布、会不会和已放置的词重叠。不同字体的字宽差异不小，同一个字号下，窄字体能塞进更多词，宽字体更容易撞墙。所以换字体之后发现“图变挤了”或者“词变少了”，不是玄学，是度量结果变了。

3.3 RGBA、background_color=None 与 to_file 的真实行为

mode='RGBA'加background_color=None是教程里反复出现的组合，作用是让背景透明。这两个参数得成对理解：mode决定图像的颜色通道数，RGBA是红绿蓝加 alpha；background_color=None告诉内部在初始化画布时不要把背景填成某个颜色，而是留成透明。只设前者不设后者，背景会被填成默认的黑色；只设后者不设前者，alpha 通道根本没有，透明无从谈起。

透明背景最典型的翻车现场在“保存之后”。to_file('out.png')存出来的 PNG 确实带 alpha 通道，但在某些看图软件、某些即时通讯工具的预览里，透明区域会被显示成黑色或白色。这时候图像本身没问题，是预览工具在替你“补底色”。判断方法很简单：把图片拖进浏览器，或者用代码读回来检查 alpha 通道：

from PIL import Image img = Image.open('out.png') print(img.mode) # 期望是 RGBA print(img.getpixel((0, 0))) # 期望第四位 alpha 为 0

另一个容易被忽略的点是显示和保存的差异。plt.imshow(wc)拿到的是WordCloud对象，matplotlib 会按自己的方式渲染；wc.to_file()走的是 PIL 的保存路径。两者在透明背景、抗锯齿上的表现并不完全一致，所以“屏幕上看着是透明的，存下来变黑了”这种事是真实存在的。以保存后的文件为准，别信屏幕。

4. 掩膜与颜色：布局边界与取色规则

蒙版是词云从“能看”到“好看”的分水岭。它的作用不是给图加个花边，而是直接改写布局的可行区域——词只能落在蒙版的非空区域内，形状本身就是约束条件。理解这一点，才不会出现“换了蒙版图没变”或者“词铺满整张图”的困惑。颜色那一层则更微妙：ImageColorGenerator和自定义color_func看起来都是“给词上色”，但取色的时机、取色的位置完全不同。

4.1 mask 的判定规则：非零像素可放词

蒙版传进去的是一个 numpy 数组，内部会把它转成“哪里能放词、哪里不能”的布尔地图。判定规则是：像素非零（非纯黑）视为可放置区，像素为零（纯黑）视为禁区。所以标准的蒙版素材是“黑底 + 白色形状”，词会填满白色形状内部。

这个规则反过来的情况非常多：白底黑图。这时候整张图除了黑色形状之外全是可放区，词会铺满画面，只在形状处留一个空洞。看起来像是“蒙版没生效”，实际上是生效了，只是语义反了。排查时先看一眼蒙版图的主色，比看代码快。

还有一个连带的坑：传了mask之后，width和height就不起作用了，画布尺寸由蒙版的数组形状直接决定。有人同时写了mask和width=1600, height=1200，发现输出还是蒙版原始的分辨率，然后怀疑参数失效。不是失效，是mask优先级更高。想让图更大，得先把蒙版图本身放大，或者用Image.resize()处理完再转数组。

蒙版的第三个细节是通道数。彩色 PNG 读进来是三维数组（高、宽、3 或 4），内部通常只取一个通道做判定，这意味着彩色蒙版里的颜色信息在“能不能放词”这件事上不参与决策，只区分“黑”和“非黑”。真正拿颜色去上色，是下一个环节的事。

import numpy as np from PIL import Image from wordcloud import WordCloud # 彩色蒙版：形状由“非黑像素”决定，颜色留给后面的 ImageColorGenerator mask = np.array(Image.open('color_mask.png')) wc = WordCloud( mask=mask, # 传了 mask，width/height 会被忽略 font_path='你的中文字体.ttf', mode='RGBA', background_color=None, ).generate(tokens)

4.2 ImageColorGenerator 取的是哪个像素

ImageColorGenerator干的事比名字听起来简单：它把蒙版图转成 RGB 数组，然后在给每个词上色时，取出这个词中心位置对应的那个像素的颜色。词落在红色区域就是红的，落在蓝色区域就是蓝的。所以颜色的分布完全由“词被布局到哪儿”决定，而不是由词本身决定。

这解释了一个常见现象：同一份文本、同一张蒙版，换个随机种子跑两次，词的配色会变。因为词的位置变了，取到的像素自然变了。想让结果稳定，得固定random_state。

from wordcloud import ImageColorGenerator # 先生成布局，再按位置取色 image_colors = ImageColorGenerator(mask) wc.recolor(color_func=image_colors) # 二次着色，见 4.4

蒙版图里如果某个区域是纯黑，而词恰好被布局到那儿（理论上不会，因为黑色是禁区），取到的颜色就是黑的，在深色背景下等于隐形。所以做彩色蒙版时，用作取色的那张图应该整片都有颜色，不要留大片纯黑，否则会出现“有些词莫名其妙看不见”的情况。

4.3 color_func 的签名约定与 HSL 弦

自定义颜色函数是最后一个自由度。WordCloud调用它的时候是按关键字传参的，所以函数签名必须能接住这几个名字：word、font_size、position、orientation、random_state，再加上**kwargs兜底。签名不匹配会直接抛TypeError，这是这类代码最常见的失败方式。

返回值是一个颜色字符串，PIL 的ImageColor能解析的格式都行：#RRGGBB、rgb(r, g, b)、hsl(h, s%, l%)。教程里用的是 HSL，这个选择有实际考虑：HSL 把色相、饱和度、亮度拆成三个独立维度，你想让颜色“多变但又不脏”，只需固定饱和度和亮度的取值范围，让色相在 0~360 之间随机。

import random def random_color(word, font_size, position, orientation, random_state=None, **kwargs): # 色相整圈随机：颜色足够分散 h = random.randint(0, 360) # 饱和度和亮度收窄：避免出现发灰或过曝的颜色 s = random.randint(60, 80) l = random.randint(60, 80) # 返回 PIL 能解析的 hsl 字符串 return 'hsl(%d, %d%%, %d%%)' % (h, s, l) wc.recolor(color_func=random_color)

把饱和度和亮度卡在 60~80 这个区间，是这套写法里最有价值的部分。全随机的话，会随机出接近黑色（l 很低）或接近白色（l 很高）的颜色，在透明背景或深色背景上直接消失。收窄区间等于给颜色加了个安全边界，图的观感立刻稳定下来。这种“不追求最大随机性，追求可控随机性”的取舍，在可视化里到处都是。

4.4 recolor 为什么要在 layout 之后

recolor()的存在本身就说明了一件事：颜色和布局是两个可以分开的步骤。生成词云时，每个词的最终位置在布局阶段才确定；而基于位置的取色（ImageColorGenerator）必须等位置确定之后才能算。所以流程只能是“先 generate 出布局，再 recolor 上色”。

直接给WordCloud(color_func=...)传自定义函数也能工作，因为那个函数只依赖词本身和随机数，不依赖位置。但只要你的取色逻辑跟位置有关，就必须走recolor。理解了这一点，recolor就不再是一个“不知道为什么存在的 API”，而是“依赖顺序”的直接体现。

recolor还有一个副作用值得知道：它会重新绘制整张图。所以如果你在generate之后手动改过wc.layout_里的东西，recolor会基于当前 layout 重画，改动会保留但颜色会重算。这个行为在调试时挺方便，在“我想保留某几个词的手工颜色”时就是个坑。

5. 避坑与排查：五个最像“玄学”的现场

词云这个技术的特殊性在于，它的失败大多是静默的。代码跑完，图出来了，你甚至能保存成文件，只是图不对。下面这五个场景，基本覆盖了从环境到参数的绝大多数“这图怎么长这样”的时刻。每一条都按“看到什么 → 为什么 → 怎么改”来拆。

5.1 中文全是方框

现象：图正常生成，布局、大小、颜色都对，但每个“词”都是一模一样的空心方框，数量还对得上。

原因：加载的字体文件里没有汉字字形。ImageFont.truetype()成功打开了字体文件，所以不报错；但渲染时找不到对应码位的字形，PIL 用默认的方框代替。这是“字体找到了但覆盖不全”，不是“字体没找到”。

解决：把font_path指向一个确定包含中文的字体文件。验证方法不用跑词云，直接测字体覆盖：

from PIL import ImageFont font = ImageFont.truetype('你的中文字体.ttf', 24) # 取一个汉字，测它的外接矩形宽度；返回 0 或异常说明没这个字形 print(font.getbbox('数'))

顺带一提，路径用相对路径时要注意工作目录。脚本放在src/下、字体放在上一级、PyCharm 的运行配置里工作目录又设成了项目根目录——这三种情况下的相对路径指向完全不同。路径错会抛OSError，跟字形缺失是两种截然不同的失败。

5.2 词云里冒出“悟空 笑道”这类词组

现象：分词明明做过了，图里还是会出现两个词粘在一起的组合，而且在中文文本里出现得特别频繁。

原因：WordCloud的collocations机制默认开启。它会在 unigram 之外额外统计 bigram，把相邻的两个 token 组合成一个新词参与权重计算。这个设计本来是给英文准备的（New York、machine learning这类固定搭配有价值），但中文分词之后每个词都用空格隔开，相邻两词的组合被大量制造出来，而且组合的频次往往不低，于是挤进了词云。

解决：中文场景基本可以无脑关掉：

wc = WordCloud( font_path='你的中文字体.ttf', collocations=False, # 关闭二元组合，只保留单个 token )

关掉之后图里的词数会变少，这是正常的——原本有一部分名额被组合词占掉了。如果关掉之后觉得词太少，调大max_words补回来。

5.3 换了 mask 却没变化，或者词铺满整张图

现象：换了一张蒙版图，输出还是矩形；或者蒙版生效了，但词几乎铺满整个画布，只在某个位置留了个形状空洞。

原因：两种可能。一是同时传了mask和width/height，后者被忽略，你以为尺寸没变是蒙版没生效，其实生效了只是分辨率跟蒙版一致。二是蒙版的明暗关系反了——判定规则是“非零可放词”，白底黑图会导致整张画布除黑色形状外全是可放区。

解决：先看蒙版的底色。标准素材应该是黑底白形。如果手头只有白底黑形，取反再转数组：

import numpy as np from PIL import Image mask = np.array(Image.open('raw_mask.png').convert('L')) mask = 255 - mask # 反色：白底黑形 -> 黑底白形 mask[mask < 128] = 0 # 二值化，去掉抗锯齿造成的灰边 mask[mask >= 128] = 255

那行二值化不是可有可无。PNG 边缘的抗锯齿会产生大量灰色像素，它们都算“非零”，都会被当成可放置区，导致形状边缘毛糙、词溢出去一点点。二值化之后边界才干净。

5.4 高频虚词霸屏，关键词被挤到看不见

现象：图里最大的是“的”“了”“是”“我”，真正想看的词缩在角落，字号小到看不清。

原因：中文停用词没有被过滤。WordCloud自带stopwords参数，但默认的停用词表是英文的，对中文毫无作用。而中文文本里虚词的频次往往是实词的好几倍，在线性映射下它们必然占据字号上限。

解决：显式传入中文停用词集合：

STOPWORDS = set('的 了 是 在 我 有 和 就 不 人 都 一 一个 上 也 很 到 说 要 去 你 会 着 没有 看 好 自己'.split()) wc = WordCloud( font_path='你的中文字体.ttf', stopwords=STOPWORDS, max_words=150, )

停用词表不建议照抄网上的大而全版本。滤得太狠会误伤（“没有”在某些文本里是关键词），滤得太松又压不住虚词。比较稳的做法是先跑一遍看词频 top 50，人工扫一眼，把这批里明显无意义的挑出来加进去，迭代两三轮就够用了。

5.5 保存出来的 PNG 背景是黑的

现象：屏幕上显示是透明背景，to_file()存出来的图拖进某个软件一看，背景一片黑。

原因：大概率是预览工具在替你补底色。PNG 的透明区域在支持 alpha 的查看器里是透明的，在不支持的查看器里会显示成黑色或白色。图本身没问题。但也确实存在真·没设对的情况——mode='RGBA'和background_color=None必须同时给，只给一个不生效。

解决：先验文件，再怀疑代码。用 PIL 读回来检查 alpha：

from PIL import Image img = Image.open('out.png') print(img.mode) # 不是 RGBA 就说明 mode 没设对 print(img.getpixel((0, 0))) # 第四位是 0 才算真透明

如果mode是RGBA、角落像素 alpha 是 0，那就别再改代码了，换个查看器或者把它贴进 PPT 里看，问题不在你这儿。

6. 词云的边界：什么时候它不该出现在报告里

词云有一个很尴尬的属性：它看起来像分析，实际上更接近装饰。字号做了归一化、颜色和位置带随机性、词的取舍依赖分词器和停用词表——这三件事叠加起来，导致同一份数据换台机器跑，出来的图可能完全不一样。它擅长的是“一眼扫过去有个印象”，不擅长的是“精确比较两个词谁更重要”。把它当成 exploratory 阶段的快速预览，没问题；把它当成结论页的核心图表，就容易出事。

具体来说，取舍集中在这几个点上：

如果你确实要用它做正式输出，至少要固定三样东西：random_state（保证布局可复现）、明确的停用词表（保证词集合可复现）、max_words与topK对齐（保证词数可复现）。这三样不定，别人复现不出你的图，图的说服力就归零。

还有一个进阶方向值得提一句：generate_from_frequencies这个接口的真正价值，不在于省掉分词，而在于它让词云变成了一个“通用权重可视化器”。权重可以来自情感得分的绝对值、来自两个时间段的频次差值、来自某个模型给出的注意力权重。这时候词云画的不再是“词频”，而是“任意可解释的分数”，信息的密度立刻不一样了。这比调颜色、调蒙版有意思得多。

我自己踩过最狠的一次，是拿一张白底黑形的蒙版跑了半天，一直以为mask参数没生效，来回改代码改到怀疑库有 bug，最后把蒙版图单独打开看了一眼才发现明暗反了。从那以后我每次做词云，都强制先把蒙版转灰度、打一行print(mask.shape, mask.max(), mask.min())确认底色，再往下写。希望帮到你。

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