简介爬虫技术是数据采集的重要手段情感分析是自然语言处理中应用广泛的文本挖掘技术两者结合可对海量用户评论进行自动化情绪识别与统计。围绕网易云音乐评论区通过Python构造AES/RSA加密请求参数获取评论数据利用SnowNLP进行情感打分并结合pyecharts完成用户画像与情绪分布可视化。实践涵盖数据清洗、情感阈值划分、时间趋势分析等完整链路同时解析Cookie失效、请求频率控制等关键问题为数据分析类项目提供可直接复用的工程思路。 打开网易云音乐某首歌的评论区你会发现这里藏着大量真实用户的心声——有人把评论当树洞有人在歌词下面写故事还有人单纯为了吐槽。这个项目就是围绕“Python爬虫 网易云音乐 情感分析 可视化”这条链路展开的先把评论区里的用户信息和评论内容抓下来再用情感分析给每条评论的情绪打分最后把用户特征和分析结果落到图表上顺便把每一步的关键代码都写上注释。适合有一定Python基础、想完整跑一遍“爬虫到分析再到可视化”全流程的人参考也适合正在做数据分析类课程作业或研究的朋友直接抄作业。1. 为什么我盯上了网易云音乐的评论区1.1 评论数据的价值在哪网易云音乐的评论区可以说是中文互联网里最具情绪浓度的地方之一。同一首歌下面有人因为歌词戳中自己给前任留言有人单纯觉得旋律好听来打卡还有人把这里当成日记本每天过来写一句状态。这些评论文本不像微博那样碎片化也不像新闻评论区那样容易被带节奏它们通常围绕一首歌、一段旋律、一种情绪氛围展开文本质量相对集中非常适合用来做情感分析试验。从技术角度讲这个场景能把整条数据处理链路串起来爬虫负责取数解析层负责从接口响应里抽取用户字段和评论文本算法层负责给文本打情感分最后用图表把结果讲清楚。做一遍这个项目相当于把Python数据分析最常用的几个工具栈requests、json、pandas、snownlp、pyecharts全过了一遍而且每条数据都是真实的、有故事背景的跑出来的结果很容易让人产生继续优化的欲望。1.2 选歌和选接口的思路做这类项目第一个实际问题不是代码而是“爬哪首歌的评论”。我建议选那些评论数在几千到几万之间的歌比如周杰伦的《晴天》歌曲ID186016。评论数太少样本不足画出来的图表没有说服力评论数太多比如《起风了》这种几十万评论的接口翻页容易受限抓到一半被卡住反而浪费时间。几千到几万条评论既能保证统计意义上数据够用又不会让请求次数过于夸张。接口方面网易云音乐手机端和PC端的网页版都有一套歌单歌曲的评论接口。我实际用的是网页版的反向接口请求地址是https://music.163.com/weapi/comment/resource/comments/get?csrf_token这个接口是POST请求需要传一个rid资源ID来指定是歌曲还是歌单的评论。歌曲评论的rid格式是R_SO_4_歌曲ID比如《晴天》就是R_SO_4_186016。同时还需要threadId参数值跟rid基本一样也是R_SO_4_186016。2. 评论接口的加密参数与请求构造2.1 那对神秘的 params 和 encSecKey 是什么如果你之前爬过网易云的接口一定会发现一个奇怪的地方明明看起来是个POST表单但你要传的既不是rid也不是pageSize而是两个加密后的字段——params和encSecKey。这是网易云Web端对评论接口做的一层参数加密目的是防止别人直接看到明文请求参数、批量刷接口。很多新手在这里卡住以为要逆向什么高深的算法。其实这层加密逻辑早就被社区研究透了核心就两步第一步把你要传的业务参数rid、pageNo、pageSize这些用AES-CBC加密一次得到第一次加密的结果第二步把这个加密结果再用一个随机生成的16位密钥做AES加密得到params字段同时把这个随机密钥用RSA公钥加密得到encSecKey字段。服务端收到后用私钥解出随机密钥再用随机密钥解出真正的业务参数。所以我们要做的就是照着这个逻辑写一套同样的加密函数。下面这个是我实际在项目中用到的一个精简版crypto.py每一步都加了注释# crypto.py import base64 import random from Crypto.Cipher import AES from Crypto.PublicKey import RSA from Crypto.Cipher import PKCS1_v1_5 # 网易云固定的 AES 密钥字符串用于第一层加密 # 这个“非对称密码客户端验证”的固定 key 已经公开很多年了 first_key 0CoJUm6Qyw8W8jud # 模数和指数是 RSA 公钥的组成部分对应网易云服务端的公钥 modulus ( 00e0b509f6259df8642dbc35662901477df22677ec152b5ff68ace615bb7 b725152b3ab17a876aea8a5aa76d2e417629ec4ee341f56135fccf695280 104e0312ecbda92557c93870114af6c9d05c4f7f0c3685b7a46bee255932 575cce10b424d813cfe4875d3e82047b97ddef52741d546b8e289dc6935b 3ece0462db0a22b8e7 ) exponent 0x010001 def aes_encrypt(text, key): AES-CBC 加密 text: 待加密的字符串 key: 16 字节密钥 返回 base64 编码的字符串 # AES 块大小 16 字节CBC 模式需要补齐到 16 的整数倍 pad 16 - len(text) % 16 text text chr(pad) * pad cipher AES.new(key.encode(utf-8), AES.MODE_CBC, b0102030405060708) encrypted cipher.encrypt(text.encode(utf-8)) return base64.b64encode(encrypted).decode(utf-8) def rsa_encrypt(text): RSA 加密 对随机密钥进行公钥加密结果要求固定长度为 256 字符 # 把随机密钥按逆序拼接这是网易云 RSA 加密的一个细节 text text[::-1] # 将 16 进制模数转成整数构造公钥对象 rsakey RSA.construct((int(modulus, 16), exponent)) cipher PKCS1_v1_5.new(rsakey) encrypted cipher.encrypt(text.encode(utf-8)) # 转成 16 进制字符串去掉开头的 0x前面补0到 256 位 result hex(encrypted).replace(0x, ).replace(L, ) return result.zfill(256) def create_song_comment_params(rid, page_no1, page_size100, cursor-1): 构造评论接口的加密参数 返回一个字典{ params: ..., encSecKey: ... } # 明文业务参数orderType1 表示按热度排序 # cursor-1 配合 pageSize 可以翻页 text { rid: rid, threadId: rid, pageNo: page_no, pageSize: page_size, cursor: cursor, offset: (page_no - 1) * page_size, orderType: 1, csrf_token: , } text json.dumps(text) # 先生成一个 16 位随机密钥用于第二层加密和 RSA 加密 random_key .join(random.choice(abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789) for _ in range(16)) # 第一次加密业务参数 固定 key first_encrypted aes_encrypt(text, first_key) # 第二次加密第一次结果 随机 key params aes_encrypt(first_encrypted, random_key) # RSA 加密随机 key enc_sec_key rsa_encrypt(random_key) return {params: params, encSecKey: enc_sec_key}这段代码有两点值得注意。第一RSA加密的结果在转成16进制后必须用zfill(256)补足到256位这是网易云服务端校验的一部分少一位都会被拒绝。第二AES的IV向量是固定的0102030405060708这个值也是公开的固定值跟密钥一样写死即可。2.2 带 Cookie 的请求头与翻页细节加密参数拿到后还要带上请求头。评论接口有两个反爬门槛第一个是User-Agent和Referer第二个是Cookie。UA很好解决随便用一个Chrome的UA字符串就行Referer必须是https://music.163.com/否则可能返回不正常的响应。Cookie这里容易踩坑。网易云的评论接口需要登录状态才能正常访问虽然不强制要求登录但POST请求如果完全没有Cookie经常会出现返回错误提示的情况。我在实际测试中发现只需要从浏览器里复制一份登录后的Cookie放进请求头基本就够用了。具体操作是浏览器登录网易云音乐网页版按F12打开开发者工具切到Network标签找到任意一个weapi开头的请求把请求头里的Cookie字符串完整复制出来粘贴到headers变量里。我写的请求代码大致长这样同样是每一步都带注释# fetch_comments.py import time import json import requests import crypto # 上面定义的 crypto.py # 这是从浏览器里复制出来的 Cookie登录后会生成 # 注意Cookie 会过期失效后需要重新复制一份 cookie_str ( 你的浏览器Cookie字符串 ) headers { User-Agent: ( Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 ), Referer: https://music.163.com/, Cookie: cookie_str, Content-Type: application/x-www-form-urlencoded, } def fetch_comments(song_id, max_pages20, sleep_time1): 抓取指定歌曲的评论 song_id: 歌曲ID比如 186016 对应《晴天》 max_pages: 最多翻多少页 sleep_time: 每页请求之间的间隔单位秒 rid fR_SO_4_{song_id} session requests.Session() session.headers.update(headers) all_records [] for page_no in range(1, max_pages 1): try: payload crypto.create_song_comment_params(rid, page_nopage_no, page_size100) resp session.post( https://music.163.com/weapi/comment/resource/comments/get?csrf_token, datapayload, timeout10 ) data resp.json() comments data.get(data, {}).get(comments, []) if not comments: print(f第 {page_no} 页没有评论停止翻页) break for item in comments: user item.get(user, {}) ip_location item.get(ipLocation, {}) or {} record { 评论ID: item.get(commentId), 评论内容: item.get(content), 评论时间: item.get(time), 点赞数: item.get(likedCount), 用户ID: user.get(userId), 用户昵称: user.get(nickname), 用户性别: user.get(gender), 用户签名: user.get(signature), IP属地: ip_location.get(location, 未知), } all_records.append(record) # 展示当前进度 total data.get(data, {}).get(totalCount, 未知) print(f第 {page_no} 页完成累计 {len(all_records)} 条歌曲总评论数约 {total}) # 页与页之间要 sleep别把服务器当自己家 time.sleep(sleep_time) except Exception as e: print(f第 {page_no} 页出错了{e}) continue return all_records if __name__ __main__: records fetch_comments(186016, max_pages20) with open(comments.json, w, encodingutf-8) as f: json.dump(records, f, ensure_asciiFalse, indent2) print(f抓取完成共 {len(records)} 条评论)这里我设置默认翻20页每页100条理论上能拿2000条。实际抓取中经常出现的情况是前面几页很顺利到了后面接口返回的评论列表突然为空或者总评论数虽然显示几万条但实际能访问的评论永远只集中在前面部分。这是正常的网易云对不登录游客态的评论访问做了一定限制不要试图一次性把几十万条全拉下来抓几千条足够做分析实验了。翻页参数里面有个细节pageNo每页加1同时offset是(pageNo - 1) * pageSize这两个字段都要传。评论区接口的cursor字段虽然默认传-1就行但翻页的时候最好不要把它留空否则可能被服务端当成第一次请求。3. 评论清洗与情感分析从文本到情绪分数3.1 原始文本不能直接扔给情感模型用上面的代码抓完数据后你会得到一个包含多个字段的列表每条记录里有用户昵称、评论内容、点赞数、时间戳、性别、IP属地这些字段。原始文本不能直接进入情感分析流程因为评论里经常混着大量跟情绪无关的东西比如重复评论有些人刷屏发送同样一句话纯表情、纯标点比如一串“哈哈哈”或“……”没有实际语义空字符串或只有空格的文本其他用户的内容比如“张三 你给我过来”转义字符残留比如\n、br这些HTML标签清洗这一步我习惯用pandas来处理因为它处理结构化数据真的比纯循环舒服太多。清洗逻辑很直白先把时间戳转成可读日期再把内容字段去空、去重、去掉纯表情最后把经过清洗的评论单独存成一个数组用来做情感分析。# clean_data.py import re import json import pandas as pd # 读取抓取下来的原始JSON with open(comments.json, r, encodingutf-8) as f: records json.load(f) df pd.DataFrame(records) # 去掉完全没有内容的评论 df df[df[评论内容].str.strip().astype(bool)] # 去掉完全重复的内容 df df.drop_duplicates(subset[评论内容]) # 去掉所有非文字内容比如纯表情、纯符号 def is_only_symbols(text): # 过滤掉空白、标点、常见emoji后如果啥都不剩就认为是纯符号 cleaned re.sub(r[\s\W_], , text, flagsre.UNICODE) return len(cleaned) 0 df df[~df[评论内容].apply(is_only_symbols)] # 评论时间戳毫秒转成日期字符串 df[评论日期] pd.to_datetime(df[评论时间], unitms).dt.strftime(%Y-%m-%d) # 性别映射0 保密1 男2 女 df[性别] df[用户性别].map({0: 保密, 1: 男, 2: 女}) print(df.shape) print(df.head())清洗之后数据量通常会缩水一小部分这完全正常。你可能会觉得“我明明抓了2000条为什么只剩1800条”不用慌这恰恰说明剩下的数据都是可用的有效文本。3.2 SnowNLP 情感打分与阈值划分情感分析这块我选的是SnowNLP这个库。选它没别的复杂理由它是目前中文情感分析里开箱即用最简单的一个不需要自己训练模型不需要配复杂的深度学习环境直接pip install snownlp就能用。它对每条文本会输出一个0到1之间的分值越接近1表示情感越积极越接近0表示情感越消极0.5附近表示中性。代码部分很简洁# sentiment_analysis.py import json import pandas as pd from snownlp import SnowNLP # 读取清洗后的数据 df pd.read_csv(clean_comments.csv) # 前面清洗完可以存一个CSV # 对每条评论计算情感分 sentiments [] for text in df[评论内容]: try: s SnowNLP(text) sentiments.append(s.sentiments) except Exception: # 个别文本可能处理失败给默认值 0.5 sentiments.append(0.5) df[情感得分] sentiments # 情感倾向划分0.6 积极0.4 消极中间为中性 # 阈值不建议卡在0.5因为SnowNLP的输出很容易堆在中间区域 def get_sentiment_label(score): if score 0.6: return 积极 if score 0.4: return 消极 return 中性 df[情感倾向] df[情感得分].apply(get_sentiment_label) # 统计整体分布 print(df[情感倾向].value_counts()) print(df[情感得分].describe()) # 顺便把点赞数排名前10、回复最多的评论打出来看看 top_liked df.nlargest(10, 点赞数)[[评论内容, 点赞数, 情感得分, 情感倾向]] print(top_liked)这里有个实操细节值得说SnowNLP的分数分布很多时候是偏中间的大量短评论的分数会落在0.4到0.6之间。如果你把阈值卡死在0.5得到的中性样本会非常庞大最终做出来的饼图基本就是一个大灰块毫无区分度。所以我实际把积极和消极的阈值放宽到0.6和0.4中间区域留给那些确实没有明显情绪倾向的评论。你可以根据自己数据跑出来的分布情况微调这个阈值不必照搬。情感分析结果出来后先做一轮交叉验证。比如把点赞数最高的前几条评论拉出来手动读一遍看看SnowNLP给它们打的标签靠不靠谱。我在测试《晴天》的评论区时就发现“你是我最想留住的幸运”这类明显偏向积极怀旧的文案SnowNLP通常会给出0.7以上的分数而“错过你是我的遗憾”这类句子大约在0.3到0.4之间纯粹的中性打卡“签到”则会落在0.5附近。整体跟人的直观感受基本一致这就是一个能用的分析结果。4. 用户信息与情感结果的可视化落地4.1 用户画像类图表谁在评论、来自哪里数据和分析结果都有了接下来是可视化环节。可视化库我推荐用pyecharts它生成的图表是HTML文件用浏览器就能打开交互式效果好图表样式也比matplotlib更现代。先做用户画像这组图这组图回答的问题是“谁在这首歌的评论区里说话”。第一个图是“评论数TOP10用户”条形图。这里要注意网易云评论很多是重复用户留多条评论所以要先按用户昵称做聚合排序取评论次数最多的前10个人。# visualize_user.py from pyecharts.charts import Bar from pyecharts import options as opts import pandas as pd df pd.read_csv(clean_comments.csv) # 统计每个用户的评论数量 user_counts df.groupby(用户昵称).size().reset_index(name评论数) user_counts user_counts.sort_values(评论数, ascendingFalse).head(10) bar ( Bar() .add_xaxis(user_counts[用户昵称].tolist()) .add_yaxis(评论数, user_counts[评论数].tolist()) .set_global_opts( title_optsopts.TitleOpts(title网易云评论评论数TOP10用户), xaxis_optsopts.AxisOpts(axislabel_optsopts.LabelOpts(rotate15)) ) .set_series_opts(label_optsopts.LabelOpts(positiontop)) ) bar.render(top10_users.html)性别维度可以画一个饼图把用户性别映射后的结果做groupby统计用Pie组件渲染。地域分布会稍微棘手一点因为网易云新版接口返回的是ipLocation.location字段格式类似“江苏 南京”“广东 广州”需要先截取省份字段再统计如果字段里没有IP属地老版本评论或调试期间没有该字段就标成“未知”这一项在分析时不要强行解读。# 地域分布统计片段 df[省份] df[IP属地].str.split( ).str[0] province_counts df[省份].value_counts().reset_index() province_counts.columns [省份, 评论数] # 用 Bar 或 Map 渲染前10个省份 top10_provinces province_counts.head(10)地图类型在pyecharts里要用Map组件还需要单独注册地图数据如果没配好反而容易报错。稳妥起见我一般只展示评论数排名前10的省份用条形图一样能说明问题而且不会被地图数据文件折腾。4.2 情感分析类图表情绪分布与时间趋势第二组图表围绕情感分析结果展开。首先是一个情感倾向占比饼图用来直观看到积极、消极、中性的比例关系。这一步非常简单直接用前面算好的df[情感倾向].value_counts()把数据塞进Pie组件就行。更有意思的是把情感和时间结合起来看。评论时间戳转成日期后可以画两条时间序列曲线一条是每日评论数量另一条是每日平均情感得分。这两条线叠在一起看能发现不少故事。比如说如果某一天突然出现一个情感得分的高峰很可能是那天发生了一件跟歌曲相关的事发行纪念日、热门节目翻唱等等导致大量情绪偏向积极的评论涌入如果某一天评分骤降可能是负面新闻或讨论盖过了正常情绪。# visualize_sentiment.py from pyecharts.charts import Line, Pie from pyecharts import options as opts import pandas as pd df pd.read_csv(clean_comments.csv) df[评论日期] pd.to_datetime(df[评论时间], unitms).dt.strftime(%Y-%m-%d) # 每日评论数量与每日平均情感得分 daily_stats df.groupby(评论日期)[情感得分].agg([mean, count]).reset_index() daily_stats.columns [日期, 平均情感分, 评论数] line ( Line() .add_xaxis(daily_stats[日期].tolist()) .add_yaxis(每日平均情感分, daily_stats[平均情感分].round(3).tolist(), is_smoothTrue) .add_yaxis(每日评论数, daily_stats[评论数].tolist(), is_smoothTrue, yaxis_index1) .set_global_opts( title_optsopts.TitleOpts(title评论情感得分与评论数量时间趋势), datazoom_opts[opts.DataZoomOpts()] ) ) line.render(sentiment_trend.html) # 情感占比饼图 sentiment_counts df[情感倾向].value_counts() pie ( Pie() .add(, [list(z) for z in zip(sentiment_counts.index, sentiment_counts.values)]) .set_global_opts(title_optsopts.TitleOpts(title评论情感倾向分布)) .set_series_opts(label_optsopts.LabelOpts(formatter{b}: {c} ({d}%))) ) pie.render(sentiment_pie.html)关于“可视化注释”这个要求我在实际做的时候有两层理解。第一层是代码注释也就是上面所有代码里那种中文注释这个前面已经做到了第二层是把注释直接标到图表上让看图的人不用到处找对应关系。pyecharts里的set_series_opts和set_global_opts都可以做这个事比如在柱状图顶部放数据标签、在饼图图例上显示百分比、在线图的数据缩放里加说明。还可以在title_opts的副标题里写上你从数据里发现的关键结论比如“该歌曲评论区积极情绪占比约62%高于消极情绪”这种一句话注释。让图表自带结论比图和数据分开要好得多。5. 爬虫与分析中最容易踩的坑5.1 请求层面加密字符、Cookie 和请求频率这个项目我在开发和调试过程中踩的坑不算少挑几个最典型的说。第一个坑是RSA加密结果不为256位。如果你用别人的加密库经常会出现返回的16进制字符串长度不对的情况少一位服务端就会拒绝。前面代码里我特意加了zfill(256)就是为了避开这个坑。如果你自己封装RSA加密千万记得做长度校验。第二个坑是Cookie过期。网易云的Cookie有一次性的那种也有长期有效的。我复制Cookie后如果隔了几天再跑大概率会返回401或403。解决方式只有一个重新打开浏览器复制最新的Cookie别试图写代码自动登录因为登录接口还涉及验证码、二维码登录等更多逻辑性价比太低。第三个坑是请求频率。虽然我代码里默认只有1秒间隔但在实际跑几十页的时候如果间隔太短网易云会突然返回一些奇怪的错误码比如-460之类。这种错误码的意思是请求频率过高、被服务端风控了。遇到这种情况别硬刚停一两个小时再继续跑或者把抓取目标切到另一首歌再回来。我还遇到过被风控后请求返回一个HTML验证页而不是JSON的情况这种情况下resp.json()会直接抛异常所以代码里一定要包一层try-except把错误页当成异常处理别让它中断整个循环。5.2 分析层面情感模型的局限与补丁SnowNLP虽然好用但它有一个天然的短板它是在购物评论和短文本上训练的对互联网口语、网络新词、歌曲评论里常见的隐喻表达理解不够准确。比如“这歌太刀了”这句在网易云评论里其实是表达“太虐心、太扎心”的负面情绪但SnowNLP可能因为“太”和“了”这些词的组合把它判成中性甚至积极。再比如“家人们谁懂啊”这种纯情绪表达模型也可能给一个偏中间的分数。针对这个问题我常用的补救办法有两个。第一个是做一个简易的情感词覆盖表把评论区里高频出现的网络情绪词手动打标点跟SnowNLP的分数做加权融合。比如统计词频时发现“哭了”“破防”“爷青回”这些词出现频率很高就可以人为设置它们的正向或负向权重。第二个是不要过分依赖单条评论的分数转而关注群体倾向和趋势变化——单条评分可能不准但几百条积极/消极评论的总比例是有参考价值的。做情感分析项目一定要明白数学模型给的是一个相对倾向不是绝对真理结果的价值在于趋势而不是逐条解读。5.3 数据层面评论时间与 IP 属地的缺失问题我抓数据时发现部分评论的time字段是0或者IP属地字段是空的。这种情况在旧评论和一些特殊渠道发布的评论上很常见。处理方式很简单时间字段为0或者解析出来是1970年的直接丢弃或者打上“未知时间”标签IP属地为空统一归为“未知”。注意在画趋势图的时候如果未知时间的评论数量太多会对日维度统计产生干扰所以建议先把无法解析时间戳的评论单独剔除后再画时间趋势。另外网易云评论显示的时间戳是毫秒级的直接用pd.to_datetime(ts, unitms)转换才是对的。如果你只除以1000转成秒再转日期出来的时间会便宜约8个小时第一天和最后一天的数据分布看起来就会很怪。6. 可以继续往下做的延伸方向6.1 词云与主题挖掘这个项目跑通基础链路后还有一个很快能见效的扩展方向词云。把清洗后的评论文本用jieba分词去掉停用词统计高频词然后通过WordCloud渲染成一张词云图。这张图可以直观看到评论区的核心话题跟情感得分放在一起就是一个完整度相当高的“评论情绪报告”。# wordcloud_demo.py import wordcloud import jieba import pandas as pd df pd.read_csv(clean_comments.csv) text .join(df[评论内容].astype(str).tolist()) # 分词并用空格拼接 words .join(jieba.cut(text)) wc wordcloud.WordCloud( font_pathsimhei.ttf, # Windows 可用 simhei.ttf / 其他系统用中文字体路径 width800, height600, background_colorwhite ).generate(words) wc.to_file(comment_wordcloud.png)6.2 多歌曲对比与歌手维度分析如果你对某一首歌的评论情感结果不满意或觉得它不够代表整体可以扩展成多歌曲对比。比如选同一位歌手的5首歌分别抓评论、做情感分析然后把5首歌的平均情感得分画在同一张图上看看哪首歌最能引发积极情绪、哪首歌更让人“破防”。这种对比分析的说服力比单独看一首歌要强得多。还可以把用户画像里的性别维度跟情感得分做交叉分析看看男性和女性评论的情感倾向有没有明显差异。6.3 实时评论监听与增量更新再进一步可以写一个定时任务每隔一小时或一天增量抓取某首歌的最新评论只抓上次抓取之后新增的评论再更新统计图表。这样就能观察到一首歌发布后评论情感随时间变化的完整过程。技术上只需在每次抓取时记录最大评论时间下次请求时把游标推进到这个时间之后即可。不过这种增量爬取对请求频率和身份伪装的要求更高建议只在学习环境下短周期运行不要做长期高频抓取。整体跑下来我的体会是这个项目最大的价值不在于某个环节有多难而在于它把爬虫、清洗、情感分析、可视化这四件事串成了一个能讲故事的整体。你抓到的评论是真实的人写下的内容算出来的情感得分是模型对内容的判断画出来的图表则是判断的结构化表达——这三层信息叠在一起既有技术含量又有可解读性。如果你也想做一个能把数据链路完整跑通、又容易出成果的Python项目从网易云音乐评论入手是一个非常好的选择。本文还有配套的精品资源点击获取 网易云音乐评论爬取与情感分析实战：从加密接口到数据可视化
简介爬虫技术是数据采集的重要手段情感分析是自然语言处理中应用广泛的文本挖掘技术两者结合可对海量用户评论进行自动化情绪识别与统计。围绕网易云音乐评论区通过Python构造AES/RSA加密请求参数获取评论数据利用SnowNLP进行情感打分并结合pyecharts完成用户画像与情绪分布可视化。实践涵盖数据清洗、情感阈值划分、时间趋势分析等完整链路同时解析Cookie失效、请求频率控制等关键问题为数据分析类项目提供可直接复用的工程思路。 打开网易云音乐某首歌的评论区你会发现这里藏着大量真实用户的心声——有人把评论当树洞有人在歌词下面写故事还有人单纯为了吐槽。这个项目就是围绕“Python爬虫 网易云音乐 情感分析 可视化”这条链路展开的先把评论区里的用户信息和评论内容抓下来再用情感分析给每条评论的情绪打分最后把用户特征和分析结果落到图表上顺便把每一步的关键代码都写上注释。适合有一定Python基础、想完整跑一遍“爬虫到分析再到可视化”全流程的人参考也适合正在做数据分析类课程作业或研究的朋友直接抄作业。1. 为什么我盯上了网易云音乐的评论区1.1 评论数据的价值在哪网易云音乐的评论区可以说是中文互联网里最具情绪浓度的地方之一。同一首歌下面有人因为歌词戳中自己给前任留言有人单纯觉得旋律好听来打卡还有人把这里当成日记本每天过来写一句状态。这些评论文本不像微博那样碎片化也不像新闻评论区那样容易被带节奏它们通常围绕一首歌、一段旋律、一种情绪氛围展开文本质量相对集中非常适合用来做情感分析试验。从技术角度讲这个场景能把整条数据处理链路串起来爬虫负责取数解析层负责从接口响应里抽取用户字段和评论文本算法层负责给文本打情感分最后用图表把结果讲清楚。做一遍这个项目相当于把Python数据分析最常用的几个工具栈requests、json、pandas、snownlp、pyecharts全过了一遍而且每条数据都是真实的、有故事背景的跑出来的结果很容易让人产生继续优化的欲望。1.2 选歌和选接口的思路做这类项目第一个实际问题不是代码而是“爬哪首歌的评论”。我建议选那些评论数在几千到几万之间的歌比如周杰伦的《晴天》歌曲ID186016。评论数太少样本不足画出来的图表没有说服力评论数太多比如《起风了》这种几十万评论的接口翻页容易受限抓到一半被卡住反而浪费时间。几千到几万条评论既能保证统计意义上数据够用又不会让请求次数过于夸张。接口方面网易云音乐手机端和PC端的网页版都有一套歌单歌曲的评论接口。我实际用的是网页版的反向接口请求地址是https://music.163.com/weapi/comment/resource/comments/get?csrf_token这个接口是POST请求需要传一个rid资源ID来指定是歌曲还是歌单的评论。歌曲评论的rid格式是R_SO_4_歌曲ID比如《晴天》就是R_SO_4_186016。同时还需要threadId参数值跟rid基本一样也是R_SO_4_186016。2. 评论接口的加密参数与请求构造2.1 那对神秘的 params 和 encSecKey 是什么如果你之前爬过网易云的接口一定会发现一个奇怪的地方明明看起来是个POST表单但你要传的既不是rid也不是pageSize而是两个加密后的字段——params和encSecKey。这是网易云Web端对评论接口做的一层参数加密目的是防止别人直接看到明文请求参数、批量刷接口。很多新手在这里卡住以为要逆向什么高深的算法。其实这层加密逻辑早就被社区研究透了核心就两步第一步把你要传的业务参数rid、pageNo、pageSize这些用AES-CBC加密一次得到第一次加密的结果第二步把这个加密结果再用一个随机生成的16位密钥做AES加密得到params字段同时把这个随机密钥用RSA公钥加密得到encSecKey字段。服务端收到后用私钥解出随机密钥再用随机密钥解出真正的业务参数。所以我们要做的就是照着这个逻辑写一套同样的加密函数。下面这个是我实际在项目中用到的一个精简版crypto.py每一步都加了注释# crypto.py import base64 import random from Crypto.Cipher import AES from Crypto.PublicKey import RSA from Crypto.Cipher import PKCS1_v1_5 # 网易云固定的 AES 密钥字符串用于第一层加密 # 这个“非对称密码客户端验证”的固定 key 已经公开很多年了 first_key 0CoJUm6Qyw8W8jud # 模数和指数是 RSA 公钥的组成部分对应网易云服务端的公钥 modulus ( 00e0b509f6259df8642dbc35662901477df22677ec152b5ff68ace615bb7 b725152b3ab17a876aea8a5aa76d2e417629ec4ee341f56135fccf695280 104e0312ecbda92557c93870114af6c9d05c4f7f0c3685b7a46bee255932 575cce10b424d813cfe4875d3e82047b97ddef52741d546b8e289dc6935b 3ece0462db0a22b8e7 ) exponent 0x010001 def aes_encrypt(text, key): AES-CBC 加密 text: 待加密的字符串 key: 16 字节密钥 返回 base64 编码的字符串 # AES 块大小 16 字节CBC 模式需要补齐到 16 的整数倍 pad 16 - len(text) % 16 text text chr(pad) * pad cipher AES.new(key.encode(utf-8), AES.MODE_CBC, b0102030405060708) encrypted cipher.encrypt(text.encode(utf-8)) return base64.b64encode(encrypted).decode(utf-8) def rsa_encrypt(text): RSA 加密 对随机密钥进行公钥加密结果要求固定长度为 256 字符 # 把随机密钥按逆序拼接这是网易云 RSA 加密的一个细节 text text[::-1] # 将 16 进制模数转成整数构造公钥对象 rsakey RSA.construct((int(modulus, 16), exponent)) cipher PKCS1_v1_5.new(rsakey) encrypted cipher.encrypt(text.encode(utf-8)) # 转成 16 进制字符串去掉开头的 0x前面补0到 256 位 result hex(encrypted).replace(0x, ).replace(L, ) return result.zfill(256) def create_song_comment_params(rid, page_no1, page_size100, cursor-1): 构造评论接口的加密参数 返回一个字典{ params: ..., encSecKey: ... } # 明文业务参数orderType1 表示按热度排序 # cursor-1 配合 pageSize 可以翻页 text { rid: rid, threadId: rid, pageNo: page_no, pageSize: page_size, cursor: cursor, offset: (page_no - 1) * page_size, orderType: 1, csrf_token: , } text json.dumps(text) # 先生成一个 16 位随机密钥用于第二层加密和 RSA 加密 random_key .join(random.choice(abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789) for _ in range(16)) # 第一次加密业务参数 固定 key first_encrypted aes_encrypt(text, first_key) # 第二次加密第一次结果 随机 key params aes_encrypt(first_encrypted, random_key) # RSA 加密随机 key enc_sec_key rsa_encrypt(random_key) return {params: params, encSecKey: enc_sec_key}这段代码有两点值得注意。第一RSA加密的结果在转成16进制后必须用zfill(256)补足到256位这是网易云服务端校验的一部分少一位都会被拒绝。第二AES的IV向量是固定的0102030405060708这个值也是公开的固定值跟密钥一样写死即可。2.2 带 Cookie 的请求头与翻页细节加密参数拿到后还要带上请求头。评论接口有两个反爬门槛第一个是User-Agent和Referer第二个是Cookie。UA很好解决随便用一个Chrome的UA字符串就行Referer必须是https://music.163.com/否则可能返回不正常的响应。Cookie这里容易踩坑。网易云的评论接口需要登录状态才能正常访问虽然不强制要求登录但POST请求如果完全没有Cookie经常会出现返回错误提示的情况。我在实际测试中发现只需要从浏览器里复制一份登录后的Cookie放进请求头基本就够用了。具体操作是浏览器登录网易云音乐网页版按F12打开开发者工具切到Network标签找到任意一个weapi开头的请求把请求头里的Cookie字符串完整复制出来粘贴到headers变量里。我写的请求代码大致长这样同样是每一步都带注释# fetch_comments.py import time import json import requests import crypto # 上面定义的 crypto.py # 这是从浏览器里复制出来的 Cookie登录后会生成 # 注意Cookie 会过期失效后需要重新复制一份 cookie_str ( 你的浏览器Cookie字符串 ) headers { User-Agent: ( Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 ), Referer: https://music.163.com/, Cookie: cookie_str, Content-Type: application/x-www-form-urlencoded, } def fetch_comments(song_id, max_pages20, sleep_time1): 抓取指定歌曲的评论 song_id: 歌曲ID比如 186016 对应《晴天》 max_pages: 最多翻多少页 sleep_time: 每页请求之间的间隔单位秒 rid fR_SO_4_{song_id} session requests.Session() session.headers.update(headers) all_records [] for page_no in range(1, max_pages 1): try: payload crypto.create_song_comment_params(rid, page_nopage_no, page_size100) resp session.post( https://music.163.com/weapi/comment/resource/comments/get?csrf_token, datapayload, timeout10 ) data resp.json() comments data.get(data, {}).get(comments, []) if not comments: print(f第 {page_no} 页没有评论停止翻页) break for item in comments: user item.get(user, {}) ip_location item.get(ipLocation, {}) or {} record { 评论ID: item.get(commentId), 评论内容: item.get(content), 评论时间: item.get(time), 点赞数: item.get(likedCount), 用户ID: user.get(userId), 用户昵称: user.get(nickname), 用户性别: user.get(gender), 用户签名: user.get(signature), IP属地: ip_location.get(location, 未知), } all_records.append(record) # 展示当前进度 total data.get(data, {}).get(totalCount, 未知) print(f第 {page_no} 页完成累计 {len(all_records)} 条歌曲总评论数约 {total}) # 页与页之间要 sleep别把服务器当自己家 time.sleep(sleep_time) except Exception as e: print(f第 {page_no} 页出错了{e}) continue return all_records if __name__ __main__: records fetch_comments(186016, max_pages20) with open(comments.json, w, encodingutf-8) as f: json.dump(records, f, ensure_asciiFalse, indent2) print(f抓取完成共 {len(records)} 条评论)这里我设置默认翻20页每页100条理论上能拿2000条。实际抓取中经常出现的情况是前面几页很顺利到了后面接口返回的评论列表突然为空或者总评论数虽然显示几万条但实际能访问的评论永远只集中在前面部分。这是正常的网易云对不登录游客态的评论访问做了一定限制不要试图一次性把几十万条全拉下来抓几千条足够做分析实验了。翻页参数里面有个细节pageNo每页加1同时offset是(pageNo - 1) * pageSize这两个字段都要传。评论区接口的cursor字段虽然默认传-1就行但翻页的时候最好不要把它留空否则可能被服务端当成第一次请求。3. 评论清洗与情感分析从文本到情绪分数3.1 原始文本不能直接扔给情感模型用上面的代码抓完数据后你会得到一个包含多个字段的列表每条记录里有用户昵称、评论内容、点赞数、时间戳、性别、IP属地这些字段。原始文本不能直接进入情感分析流程因为评论里经常混着大量跟情绪无关的东西比如重复评论有些人刷屏发送同样一句话纯表情、纯标点比如一串“哈哈哈”或“……”没有实际语义空字符串或只有空格的文本其他用户的内容比如“张三 你给我过来”转义字符残留比如\n、br这些HTML标签清洗这一步我习惯用pandas来处理因为它处理结构化数据真的比纯循环舒服太多。清洗逻辑很直白先把时间戳转成可读日期再把内容字段去空、去重、去掉纯表情最后把经过清洗的评论单独存成一个数组用来做情感分析。# clean_data.py import re import json import pandas as pd # 读取抓取下来的原始JSON with open(comments.json, r, encodingutf-8) as f: records json.load(f) df pd.DataFrame(records) # 去掉完全没有内容的评论 df df[df[评论内容].str.strip().astype(bool)] # 去掉完全重复的内容 df df.drop_duplicates(subset[评论内容]) # 去掉所有非文字内容比如纯表情、纯符号 def is_only_symbols(text): # 过滤掉空白、标点、常见emoji后如果啥都不剩就认为是纯符号 cleaned re.sub(r[\s\W_], , text, flagsre.UNICODE) return len(cleaned) 0 df df[~df[评论内容].apply(is_only_symbols)] # 评论时间戳毫秒转成日期字符串 df[评论日期] pd.to_datetime(df[评论时间], unitms).dt.strftime(%Y-%m-%d) # 性别映射0 保密1 男2 女 df[性别] df[用户性别].map({0: 保密, 1: 男, 2: 女}) print(df.shape) print(df.head())清洗之后数据量通常会缩水一小部分这完全正常。你可能会觉得“我明明抓了2000条为什么只剩1800条”不用慌这恰恰说明剩下的数据都是可用的有效文本。3.2 SnowNLP 情感打分与阈值划分情感分析这块我选的是SnowNLP这个库。选它没别的复杂理由它是目前中文情感分析里开箱即用最简单的一个不需要自己训练模型不需要配复杂的深度学习环境直接pip install snownlp就能用。它对每条文本会输出一个0到1之间的分值越接近1表示情感越积极越接近0表示情感越消极0.5附近表示中性。代码部分很简洁# sentiment_analysis.py import json import pandas as pd from snownlp import SnowNLP # 读取清洗后的数据 df pd.read_csv(clean_comments.csv) # 前面清洗完可以存一个CSV # 对每条评论计算情感分 sentiments [] for text in df[评论内容]: try: s SnowNLP(text) sentiments.append(s.sentiments) except Exception: # 个别文本可能处理失败给默认值 0.5 sentiments.append(0.5) df[情感得分] sentiments # 情感倾向划分0.6 积极0.4 消极中间为中性 # 阈值不建议卡在0.5因为SnowNLP的输出很容易堆在中间区域 def get_sentiment_label(score): if score 0.6: return 积极 if score 0.4: return 消极 return 中性 df[情感倾向] df[情感得分].apply(get_sentiment_label) # 统计整体分布 print(df[情感倾向].value_counts()) print(df[情感得分].describe()) # 顺便把点赞数排名前10、回复最多的评论打出来看看 top_liked df.nlargest(10, 点赞数)[[评论内容, 点赞数, 情感得分, 情感倾向]] print(top_liked)这里有个实操细节值得说SnowNLP的分数分布很多时候是偏中间的大量短评论的分数会落在0.4到0.6之间。如果你把阈值卡死在0.5得到的中性样本会非常庞大最终做出来的饼图基本就是一个大灰块毫无区分度。所以我实际把积极和消极的阈值放宽到0.6和0.4中间区域留给那些确实没有明显情绪倾向的评论。你可以根据自己数据跑出来的分布情况微调这个阈值不必照搬。情感分析结果出来后先做一轮交叉验证。比如把点赞数最高的前几条评论拉出来手动读一遍看看SnowNLP给它们打的标签靠不靠谱。我在测试《晴天》的评论区时就发现“你是我最想留住的幸运”这类明显偏向积极怀旧的文案SnowNLP通常会给出0.7以上的分数而“错过你是我的遗憾”这类句子大约在0.3到0.4之间纯粹的中性打卡“签到”则会落在0.5附近。整体跟人的直观感受基本一致这就是一个能用的分析结果。4. 用户信息与情感结果的可视化落地4.1 用户画像类图表谁在评论、来自哪里数据和分析结果都有了接下来是可视化环节。可视化库我推荐用pyecharts它生成的图表是HTML文件用浏览器就能打开交互式效果好图表样式也比matplotlib更现代。先做用户画像这组图这组图回答的问题是“谁在这首歌的评论区里说话”。第一个图是“评论数TOP10用户”条形图。这里要注意网易云评论很多是重复用户留多条评论所以要先按用户昵称做聚合排序取评论次数最多的前10个人。# visualize_user.py from pyecharts.charts import Bar from pyecharts import options as opts import pandas as pd df pd.read_csv(clean_comments.csv) # 统计每个用户的评论数量 user_counts df.groupby(用户昵称).size().reset_index(name评论数) user_counts user_counts.sort_values(评论数, ascendingFalse).head(10) bar ( Bar() .add_xaxis(user_counts[用户昵称].tolist()) .add_yaxis(评论数, user_counts[评论数].tolist()) .set_global_opts( title_optsopts.TitleOpts(title网易云评论评论数TOP10用户), xaxis_optsopts.AxisOpts(axislabel_optsopts.LabelOpts(rotate15)) ) .set_series_opts(label_optsopts.LabelOpts(positiontop)) ) bar.render(top10_users.html)性别维度可以画一个饼图把用户性别映射后的结果做groupby统计用Pie组件渲染。地域分布会稍微棘手一点因为网易云新版接口返回的是ipLocation.location字段格式类似“江苏 南京”“广东 广州”需要先截取省份字段再统计如果字段里没有IP属地老版本评论或调试期间没有该字段就标成“未知”这一项在分析时不要强行解读。# 地域分布统计片段 df[省份] df[IP属地].str.split( ).str[0] province_counts df[省份].value_counts().reset_index() province_counts.columns [省份, 评论数] # 用 Bar 或 Map 渲染前10个省份 top10_provinces province_counts.head(10)地图类型在pyecharts里要用Map组件还需要单独注册地图数据如果没配好反而容易报错。稳妥起见我一般只展示评论数排名前10的省份用条形图一样能说明问题而且不会被地图数据文件折腾。4.2 情感分析类图表情绪分布与时间趋势第二组图表围绕情感分析结果展开。首先是一个情感倾向占比饼图用来直观看到积极、消极、中性的比例关系。这一步非常简单直接用前面算好的df[情感倾向].value_counts()把数据塞进Pie组件就行。更有意思的是把情感和时间结合起来看。评论时间戳转成日期后可以画两条时间序列曲线一条是每日评论数量另一条是每日平均情感得分。这两条线叠在一起看能发现不少故事。比如说如果某一天突然出现一个情感得分的高峰很可能是那天发生了一件跟歌曲相关的事发行纪念日、热门节目翻唱等等导致大量情绪偏向积极的评论涌入如果某一天评分骤降可能是负面新闻或讨论盖过了正常情绪。# visualize_sentiment.py from pyecharts.charts import Line, Pie from pyecharts import options as opts import pandas as pd df pd.read_csv(clean_comments.csv) df[评论日期] pd.to_datetime(df[评论时间], unitms).dt.strftime(%Y-%m-%d) # 每日评论数量与每日平均情感得分 daily_stats df.groupby(评论日期)[情感得分].agg([mean, count]).reset_index() daily_stats.columns [日期, 平均情感分, 评论数] line ( Line() .add_xaxis(daily_stats[日期].tolist()) .add_yaxis(每日平均情感分, daily_stats[平均情感分].round(3).tolist(), is_smoothTrue) .add_yaxis(每日评论数, daily_stats[评论数].tolist(), is_smoothTrue, yaxis_index1) .set_global_opts( title_optsopts.TitleOpts(title评论情感得分与评论数量时间趋势), datazoom_opts[opts.DataZoomOpts()] ) ) line.render(sentiment_trend.html) # 情感占比饼图 sentiment_counts df[情感倾向].value_counts() pie ( Pie() .add(, [list(z) for z in zip(sentiment_counts.index, sentiment_counts.values)]) .set_global_opts(title_optsopts.TitleOpts(title评论情感倾向分布)) .set_series_opts(label_optsopts.LabelOpts(formatter{b}: {c} ({d}%))) ) pie.render(sentiment_pie.html)关于“可视化注释”这个要求我在实际做的时候有两层理解。第一层是代码注释也就是上面所有代码里那种中文注释这个前面已经做到了第二层是把注释直接标到图表上让看图的人不用到处找对应关系。pyecharts里的set_series_opts和set_global_opts都可以做这个事比如在柱状图顶部放数据标签、在饼图图例上显示百分比、在线图的数据缩放里加说明。还可以在title_opts的副标题里写上你从数据里发现的关键结论比如“该歌曲评论区积极情绪占比约62%高于消极情绪”这种一句话注释。让图表自带结论比图和数据分开要好得多。5. 爬虫与分析中最容易踩的坑5.1 请求层面加密字符、Cookie 和请求频率这个项目我在开发和调试过程中踩的坑不算少挑几个最典型的说。第一个坑是RSA加密结果不为256位。如果你用别人的加密库经常会出现返回的16进制字符串长度不对的情况少一位服务端就会拒绝。前面代码里我特意加了zfill(256)就是为了避开这个坑。如果你自己封装RSA加密千万记得做长度校验。第二个坑是Cookie过期。网易云的Cookie有一次性的那种也有长期有效的。我复制Cookie后如果隔了几天再跑大概率会返回401或403。解决方式只有一个重新打开浏览器复制最新的Cookie别试图写代码自动登录因为登录接口还涉及验证码、二维码登录等更多逻辑性价比太低。第三个坑是请求频率。虽然我代码里默认只有1秒间隔但在实际跑几十页的时候如果间隔太短网易云会突然返回一些奇怪的错误码比如-460之类。这种错误码的意思是请求频率过高、被服务端风控了。遇到这种情况别硬刚停一两个小时再继续跑或者把抓取目标切到另一首歌再回来。我还遇到过被风控后请求返回一个HTML验证页而不是JSON的情况这种情况下resp.json()会直接抛异常所以代码里一定要包一层try-except把错误页当成异常处理别让它中断整个循环。5.2 分析层面情感模型的局限与补丁SnowNLP虽然好用但它有一个天然的短板它是在购物评论和短文本上训练的对互联网口语、网络新词、歌曲评论里常见的隐喻表达理解不够准确。比如“这歌太刀了”这句在网易云评论里其实是表达“太虐心、太扎心”的负面情绪但SnowNLP可能因为“太”和“了”这些词的组合把它判成中性甚至积极。再比如“家人们谁懂啊”这种纯情绪表达模型也可能给一个偏中间的分数。针对这个问题我常用的补救办法有两个。第一个是做一个简易的情感词覆盖表把评论区里高频出现的网络情绪词手动打标点跟SnowNLP的分数做加权融合。比如统计词频时发现“哭了”“破防”“爷青回”这些词出现频率很高就可以人为设置它们的正向或负向权重。第二个是不要过分依赖单条评论的分数转而关注群体倾向和趋势变化——单条评分可能不准但几百条积极/消极评论的总比例是有参考价值的。做情感分析项目一定要明白数学模型给的是一个相对倾向不是绝对真理结果的价值在于趋势而不是逐条解读。5.3 数据层面评论时间与 IP 属地的缺失问题我抓数据时发现部分评论的time字段是0或者IP属地字段是空的。这种情况在旧评论和一些特殊渠道发布的评论上很常见。处理方式很简单时间字段为0或者解析出来是1970年的直接丢弃或者打上“未知时间”标签IP属地为空统一归为“未知”。注意在画趋势图的时候如果未知时间的评论数量太多会对日维度统计产生干扰所以建议先把无法解析时间戳的评论单独剔除后再画时间趋势。另外网易云评论显示的时间戳是毫秒级的直接用pd.to_datetime(ts, unitms)转换才是对的。如果你只除以1000转成秒再转日期出来的时间会便宜约8个小时第一天和最后一天的数据分布看起来就会很怪。6. 可以继续往下做的延伸方向6.1 词云与主题挖掘这个项目跑通基础链路后还有一个很快能见效的扩展方向词云。把清洗后的评论文本用jieba分词去掉停用词统计高频词然后通过WordCloud渲染成一张词云图。这张图可以直观看到评论区的核心话题跟情感得分放在一起就是一个完整度相当高的“评论情绪报告”。# wordcloud_demo.py import wordcloud import jieba import pandas as pd df pd.read_csv(clean_comments.csv) text .join(df[评论内容].astype(str).tolist()) # 分词并用空格拼接 words .join(jieba.cut(text)) wc wordcloud.WordCloud( font_pathsimhei.ttf, # Windows 可用 simhei.ttf / 其他系统用中文字体路径 width800, height600, background_colorwhite ).generate(words) wc.to_file(comment_wordcloud.png)6.2 多歌曲对比与歌手维度分析如果你对某一首歌的评论情感结果不满意或觉得它不够代表整体可以扩展成多歌曲对比。比如选同一位歌手的5首歌分别抓评论、做情感分析然后把5首歌的平均情感得分画在同一张图上看看哪首歌最能引发积极情绪、哪首歌更让人“破防”。这种对比分析的说服力比单独看一首歌要强得多。还可以把用户画像里的性别维度跟情感得分做交叉分析看看男性和女性评论的情感倾向有没有明显差异。6.3 实时评论监听与增量更新再进一步可以写一个定时任务每隔一小时或一天增量抓取某首歌的最新评论只抓上次抓取之后新增的评论再更新统计图表。这样就能观察到一首歌发布后评论情感随时间变化的完整过程。技术上只需在每次抓取时记录最大评论时间下次请求时把游标推进到这个时间之后即可。不过这种增量爬取对请求频率和身份伪装的要求更高建议只在学习环境下短周期运行不要做长期高频抓取。整体跑下来我的体会是这个项目最大的价值不在于某个环节有多难而在于它把爬虫、清洗、情感分析、可视化这四件事串成了一个能讲故事的整体。你抓到的评论是真实的人写下的内容算出来的情感得分是模型对内容的判断画出来的图表则是判断的结构化表达——这三层信息叠在一起既有技术含量又有可解读性。如果你也想做一个能把数据链路完整跑通、又容易出成果的Python项目从网易云音乐评论入手是一个非常好的选择。本文还有配套的精品资源点击获取