Vue 3 + Pinia + ECharts 构建实时舆情分析系统实践

简介：一套基于Vue框架设计的舆情分析系统前端源码，适合需要掌握组件化开发、快速构建数据可视化界面的前端初学者和中级开发者。资源共25个文件，主要包括11个Vue组件、5个JavaScript脚本、4个JSON配置，以及HTML、图标、图片和说明文档。Vue组件覆盖舆情热词云、情绪趋势、地区分布、热点区域等多个分析模块；JS脚本承担数据请求和交互逻辑；JSON配置用于工程设置，整体压缩包仅865KB，结构精炼便于研读。目前已有109人学习下载。源码还提供登录页、仪表盘等典型业务场景，配合readme说明和完整的Vue工程配置，能直观理解路由、状态管理和组件通信的配合方式，也为进一步接入后端舆情数据、构建完整分析平台提供了清晰可扩展的前端基座。

1. 舆情分析系统选 Vue 的理由：组件复用、状态管理与视图解耦

舆情分析看板有一个典型特征：同一份数据要在多个维度反复切片。事件总数按小时画趋势线、正负面情感占比画环形图、高频关键词堆成词云、地域分布铺散点地图，每多一个视图就多一种消费同一批数据的方式。用传统多页面开发，页面之间的筛选条件同步全靠 localStorage，数据量一大就失控。Vue 的响应式状态把这份数据集中管理起来，任何视图更新自动联动，组件化又让趋势图、词云这些重复出现的元素只写一次，这是选型最直接的理由。

这套方案面向准备从零搭建或重构舆情看板前端的开发者，核心组合是 Vue 3 组合式 API 加 TypeScript、Pinia 状态管理、ECharts 可视化和 WebSocket 实时通道。接下来从数据模型设计开始，逐步落到图表组件封装、实时推送接入和打包优化，把最容易踩坑的细节一并讲清楚。

2. 舆情数据先建模：看板字段设计、Pinia 状态分层与工程目录

2.1 从采集端反推前端字段模型

舆情系统的数据源是爬虫或第三方数据服务，前端拿到的是清洗后的结果，所以字段模型本质上是接口契约。我一般会先和后端确认核心字段，而不是等接口文档出来再改页面：

// types/opinion.ts export interface OpinionDocument { id: string title: string contentSnippet: string sourceType: 'weibo' | 'news' | 'forum' | 'wechat' sourceName: string publishedAt: number // 毫秒时间戳，统一时区基准 sentimentScore: number // -1 ~ 1，正负代表情感极性 heatIndex: number // 0 ~ 100，热度指数 keywords: string[] // 后端 NLP 抽取，前端不自行分词 region?: string // 地域属性，用于地图视图 url: string }

这个结构里有三个细节决定后续开发是否顺畅。第一，时间字段必须用时间戳而不是日期字符串，否则按小时聚合趋势图时会出现时区偏移，线上环境一换就多一小时或少一小时。第二，情感字段用数值而不是枚举字符串，后端评分模型输出的原始分往往落在 -1 到 1 之间，前端可以在统计时按阈值切成三档，也可以直接求平均画进趋势图，数值类型给展示层留了弹性。第三，keywords 数组由后端 NLP 模块产出，前端不要自己做分词，也不要对数组内容做二次筛选，关键词如何清洗属于采集端职责，前端直接消费词频统计结果即可。

数值型情感字段的取舍

interface 里如果写 sentiment: 'positive' | 'neutral' | 'negative'，后续做均值计算就得先映射一遍，而且后端阈值调整后前端无法感知。数值字段配合 getter 在统计层切割，阈值变化只改一处常量，这个设计在后端模型迭代频繁的舆情项目里能省掉大量联调成本。

2.2 Pinia 状态分层：拆成三个 store 而不是一个大对象

前端面试题里常问 Vue 状态管理该怎么拆，舆情这个场景的答案是按视图职责拆，不要把所有字段塞进一个全局对象。我一般拆成三个 store：文档流、筛选条件、图表聚合。

// stores/opinion.ts —— 文档流 store import { defineStore } from 'pinia' export const useOpinionStore = defineStore('opinion', { state: () => ({ documents: [] as OpinionDocument[], total: 0, wsConnected: false // WebSocket 连接状态 }), getters: { pagedDocuments: (state) => (page: number, size: number) => state.documents.slice((page - 1) * size, page * size) }, actions: { appendDocuments(docs: OpinionDocument[]) { this.documents.push(...docs) // 内存保护：超过上限丢弃最旧的数据 if (this.documents.length > 5000) { this.documents.splice(0, this.documents.length - 5000) } } } })

数组长度上限 5000 是内存保护的底线。舆情事件流一天可能产生几十万条记录，浏览器不可能全量驻留，超过上限丢弃旧数据是最简单可靠的裁剪策略。total 字段维护服务端全量计数，列表翻页走服务端分页接口，documents 只作为实时滚动窗口，两个数据源职责分离，避免列表越翻越慢。

为什么这个场景不选 Vuex

Pinia 对比 Vuex 的优势在 TypeScript 推导和组合式 API 的适配度上。舆情看板组件里大量使用 setup 语法和 computed 派生状态，Pinia 的 storeToRefs 能直接保持响应式且类型不丢失，Vuex 4 的映射写法在组合式 API 下显得繁琐。新项目没有历史包袱的话，Pinia 是更顺手的选型。

2.3 按功能域切目录，图表组件单独下沉复用

工程目录不仅影响协作，还直接决定功能的可维护边界。按类型平铺的写法在功能迭代增加时，一个需求改动要横跨四五个目录，我建议按功能域划分：

src/ ├── api/opinion.ts # 舆情接口封装与归一化 ├── components/chart/ # 图表基础组件，跨页面复用 ├── components/common/ # 通用 UI 组件 ├── composables/useOpinionSocket.ts # WebSocket 组合函数 ├── stores/opinion.ts ├── stores/filter.ts ├── views/monitor/ # 实时监控页 ├── views/analyze/ # 事件分析页 └── types/opinion.ts

图表组件单独放一层的原因很直接：monitor 和 analyze 两个页面都会消费趋势图和词云，如果图表只在某页面内声明，跨页面复用就只能复制粘贴。把 chart 目录当作内部组件库维护，入参用 props 而不是依赖全局 store，组件内部不感知业务字段，这是保证多页面共用一个图表组件的关键约定。

2.4 API 层做归一化，组件不碰原始字段

后端接口返回的字段名和取值维度未必符合展示层需要，常见情况是热度给 0 到 10000 的计数、时间给 ISO 字符串、情感给百分比。我习惯在 api 层统一归一化：

// api/opinion.ts import dayjs from 'dayjs' export async function fetchTrend(params: TrendQuery) { const { data } = await http.get('/api/v1/opinion/trend', { params }) return data.map((item: TrendRaw) => ({ time: dayjs(item.ts).format('HH:mm'), heat: Number((item.heat / 100).toFixed(2)), // 归一化到 0~100 sentiment: Number(item.sentimentAvg.toFixed(2)) })) }

归一化逻辑集中在 api 层，组件拿到的是已经贴合图表数据结构的结果。这么做的好处有三个：后端字段调整只改 api 文件；图表组件的入参保持稳定；单元测试可以直接针对 api 层断言。团队里经常出现后端把字段改名导致前端到处改的情况，本质上就是缺少这一层映射。

3. 用 ECharts 封装趋势图、热词云与情感分布组件

3.1 趋势折线图的 setOption 更新策略与容器高度陷阱

热度随时间变化的趋势图是整个看板的主视觉。封装图表组件时最容易被忽略的是更新方式——不是每次数据变化都重新 init，而是复用实例并调用 setOption：

<template> <div ref="el" class="trend-chart"></div> </template> <script setup lang="ts"> import * as echarts from 'echarts' import { onMounted, onBeforeUnmount, ref, watch } from 'vue' const props = defineProps<{ data: { time: string; heat: number; sentiment: number }[] }>() const el = ref<HTMLDivElement>() let chart: echarts.ECharts | null = null function render() { if (!chart || !props.data.length) return chart.setOption({ tooltip: { trigger: 'axis' }, legend: { data: ['热度', '情感指数'] }, grid: { left: 48, right: 20, top: 32, bottom: 28 }, xAxis: { type: 'category', data: props.data.map(d => d.time) }, yAxis: [ { type: 'value', name: '热度' }, { type: 'value', name: '情感', min: -1, max: 1 } ], series: [ { name: '热度', type: 'line', smooth: true, areaStyle: { opacity: 0.15 }, data: props.data.map(d => d.heat) }, { name: '情感', type: 'line', yAxisIndex: 1, smooth: true, data: props.data.map(d => d.sentiment) } ] }, { notMerge: true }) } onMounted(() => { chart = echarts.init(el.value!) render() window.addEventListener('resize', () => chart?.resize()) }) watch(() => props.data, render, { deep: true }) onBeforeUnmount(() => { chart?.dispose() }) </script> <style scoped> .trend-chart { height: 320px; width: 100%; } </style>

关键点有两个。一个是 init 只执行一次，后续数据变化走 setOption 并传 { notMerge: true } 强制整体覆盖，避免新旧数据残留；另一个是容器高度必须显式声明，ECharts init 时容器高度为 0 会导致图表空白，这是用 flex 布局包裹图表时最常见的「样式正常但图不出来」的原因，父容器 flex: 1 撑高的写法对 echarts 无效。

3.2 热词云组件的降采样与词频归一化

词云模块是舆情看板里性能瓶颈最明显的部分。echarts-wordcloud 插件对每个词做布局碰撞计算，几千个词一次性丢进去，浏览器直接卡死。实践里的做法是先降采样再归一化：

// components/chart/useWordCloud.ts export function buildWordCloudData(keywordCounts: { word: string; count: number }[]) { const sorted = [...keywordCounts].sort((a, b) => b.count - a.count) const top60 = sorted.slice(0, 60) const max = top60[0]?.count ?? 1 return top60.map(item => ({ name: item.word, value: Number((item.count / max * 100).toFixed(0)) // 归一化到 0~100 })) }

60 是实践里比较稳的数量阈值，视觉上足够密集，布局计算每帧不超过几十毫秒。归一化保证词云的字号差异始终明显，不会因为某天词频绝对量级飙升导致小词全部消失。如果产品需求必须展示 500 词以上，就不要用词云布局，改成表格加横向条形图更合适，渲染成本低且可排序。

提示：词云插件在数据量超过 200 时，建议把动画关闭。动画开启时每个词的布局都要重新计算过渡帧，更新频率一高就会出现明显的卡顿。

3.3 情感分布环形图的阈值切割与路由联动

情感分布通常用环形图呈现正、中、负三档占比，统计逻辑放在 store 的 getter 里，组件只消费结果：

// stores/opinion.ts getters: { sentimentStats(state) { const counter = { positive: 0, neutral: 0, negative: 0 } for (const doc of state.documents) { if (doc.sentimentScore > 0.2) counter.positive++ else if (doc.sentimentScore < -0.2) counter.negative++ else counter.neutral++ } return counter } }

阈值 0.2 和 -0.2 是常用切割点，绝对值小于该阈值的情感极性与中性区分度不高，大于该阈值的样本已经足够明确。三个档位在环形图里要配固定色值，保证运营人员形成肌肉记忆：

点击环形图扇区跳转到对应列表页，可以借助 vue-router 的 query 参数传递页面状态：

chart.on('click', (params) => { router.push({ path: '/analyze', query: { sentiment: params.name } // 筛选条件写入 URL }) })

用 query 传参而不是 Pinia 的原因是 query 会写进 URL，用户刷新页面后筛选条件仍然保留，把链接发给同事也能还原相同视图。如果只存在内部状态，刷新就回到默认条件，对舆情追踪场景是体验缺陷。

4. WebSocket 实时推送下，看板增量更新与断线重连

4.1 推送消息格式与服务端衔接

实时性是舆情系统区别于一般报表系统的核心差异。轮询也能做，但舆情事件爆发时接口被高频轮询容易打崩服务端，常见做法是 WebSocket 长连接由服务端按批推送增量。消息格式需要先和后端定好，我一般用统一消息信封，而不是在回调里堆一长串 if-else：

{ "type": "increment", "data": { "batchId": 10231, "documents": [] } }

type 字段用于区分增量事件、心跳和全量同步三种消息类型，前端按类型分发处理。batchId 是幂等判定的依据，前端记录最近消费的 batchId，网络重试导致的重复消息可以直接跳过，避免看板数据翻倍。

4.2 增量事件队列与防抖合并

高频推送下，每收到一条消息就调用一次 appendDocuments，会让 Vue 的响应式系统频繁触发更新，页面渲染帧率掉下来。我一般把增量先累积到队列，再定时统一 flush：

// composables/useOpinionSocket.ts const pendingBatch: OpinionDocument[] = [] let flushTimer: number | null = null function handleSocketMessage(raw: MessageEvent) { const msg = JSON.parse(raw.data) if (msg.type !== 'increment') return pendingBatch.push(...msg.data.documents) if (flushTimer) return flushTimer = window.setTimeout(() => { opinionStore.appendDocuments(pendingBatch.splice(0)) // 一次批量写入 flushTimer = null }, 1000) }

这个写法的核心价值是把每秒几百条消息压缩成每秒一次批量更新。队列在内存里累积 1 秒内的增量，到时间窗口后统一推给 store。splice(0) 取出所有元素同时清空数组，比新建数组更省内存。flushTimer 保证无论消息多密集，store 更新频率恒定，图表组件因此天然获得 1 秒级别的节流。

4.3 断线重连的指数退避与心跳保活

WebSocket 在弱网环境掉线是常态，重连逻辑写得太激进会被服务端限流。指数退避是标准解法：

let retryCount = 0 function connect() { const ws = new WebSocket(WS_URL) ws.onopen = () => { retryCount = 0 opinionStore.wsConnected = true } ws.onclose = () => { opinionStore.wsConnected = false const delay = Math.min(30000, 1000 * 2 ** retryCount) // 1s 起步，翻倍封顶 30s retryCount++ setTimeout(connect, delay) } ws.onerror = () => ws.close() }

延迟从 1 秒起步，每次失败翻倍，封顶 30 秒。同时在状态栏暴露 wsConnected 字段，让运营直观区分实时推送和断线补数据两种状态。服务端侧建议每 30 秒发一次心跳消息，前端收到后重置超时计数器，TCP 层对长时间空闲连接的检测不可靠，应用层心跳才有确定语义。

舆情分析通常需要前端向服务端下发订阅条件，比如只看某一来源类型，双向通道比 SSE 更合适，WebSocket 是更稳妥的默认选择。

全量同步与增量补偿

断线重连成功后，存量数据已经落后，增量消息无法补齐中间缺口。常见做法是重连后先发一条 sync 消息带上最后消费的 batchId，服务端返回缺口数据加上新增量。这个逻辑在 connect 的 onopen 里触发，补偿完成后才恢复实时渲染，避免出现时间轴断裂。

5. 打包体积控制、虚拟滚动与 vue 打包后布局异常的排查

5.1 路由级按需加载与 echarts 按需注册

舆情看板包含监控页、分析页、报告页三个主路由，首屏只需要监控页。vue-router 的动态导入能把其他页面拆成独立 chunk：

// router/index.ts const MonitorBoard = () => import('@/views/monitor/MonitorBoard.vue') const AnalyzeBoard = () => import('@/views/analyze/AnalyzeBoard.vue')

与路由拆分配合的是 echarts 按需注册。全量引入 echarts 的打包体积在 1MB 左右，按需注册后只保留趋势图和环形图所需的模块：

import { LineChart, PieChart } from 'echarts/charts' import { GridComponent, TooltipComponent, LegendComponent } from 'echarts/components' echarts.use([LineChart, PieChart, GridComponent, TooltipComponent, LegendComponent])

这两处叠加，首屏 JS 能压掉一半以上，对舆情这种数据密集型看板收益很直接。组件从echarts/core导入并显式 use，tree-shaking 才能生效。

5.2 虚拟滚动触发阈值与选型

文档列表超过 1000 条时直接 v-for 渲染会明显卡顿。虚拟滚动只渲染可视区域加缓冲区节点，数据量再大页面里也只有二十到四十个 DOM 节点。触发阈值参考：列表超过 500 条考虑轻量分页，超过 1000 条强制虚拟滚动。@tanstack/vue-virtual 是体积较小的选型，动态行高和自定义缓冲区都支持。

5.3 vue 打包后布局异常，优先排查路由模式与 base 路径

vue 打包后布局异常是高频线上问题，表现包括白屏、图片 404、CSS 错位。排查顺序固定：先看路由模式。history 模式部署在子目录时刷新非根路径会 404，因为服务端没有配置 fallback。切换 hash 模式让前端自己处理刷新，部署最省心：

import { createWebHashHistory } from 'vue-router' const router = createRouter({ history: createWebHashHistory(), routes })

其次是静态资源 base 路径。Vite 默认 base 为 '/'，部署在子目录时 JS/CSS 全部 404，表现为页面结构在但样式全丢。在 vite.config 里按环境区分：

export default defineConfig({ base: process.env.NODE_ENV === 'production' ? '/opinion/' : '/' })

base 配错时资源请求前缀缺一段导致加载失败，路由白屏是页面跳转后无法渲染，两者是不同层面的问题。排查时打开 Network 面板看资源请求是否 404，再看控制台有无路由匹配警告，按这个顺序两分钟就能定位根因。

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