1. 项目缘起与整体设计思路拆解1.1 为什么想到做一套太阳能发电监控系统光伏电站这行有个很现实的问题板子铺出去容易管起来难。一个中小型分布式电站屋顶上几十上百块组件逆变器藏在角落运维人员不可能天天爬上去拿万用表量。发电量掉了、某一路组串电流异常、逆变器报故障这些信息如果靠人工巡检去发现往往滞后好几天损失的都是真金白银。我接触过几个做分布式光伏运维的团队早期基本靠逆变器厂商自带的云平台看数据但那些平台要么功能阉割要么数据不开放想做个自定义的告警规则、想按自己的业务逻辑做统计分析处处受限。这套基于 Vue.js 的太阳能发电监控系统核心目标就一个把发电侧的数据采上来、看清楚、能告警、可追溯。它解决的是中小型光伏电站“数据黑箱”的问题——让运维人员在一个浏览器页面里就能看到每台逆变器的实时功率、每路组串的电流电压、当天的发电量曲线、历史发电趋势以及设备离线、功率骤降这类异常状态的即时提醒。适合谁来参考一是做物联网/工业监控方向的前端开发者想找一个完整的“实时数据图表告警”的实战项目二是光伏行业里懂点技术、想自己搭一套轻量监控工具的运维负责人三是计算机相关专业做毕业设计或课程项目的同学这个题目涉及前端框架、实时通信、时序数据可视化、后端接口设计技术栈完整且场景真实。我选择 Vue.js 作为前端主体不是跟风。监控类系统的页面特点是“组件复用率高、状态变化频繁、图表交互多”Vue 的响应式机制和组件化能力刚好对路。一个逆变器卡片组件传不同的设备 ID 进去就能复用实时数据推过来数据变了视图自动更新不用手动操作 DOM。再加上 ECharts 做图表、WebSocket 做实时推送整套技术组合在中小型监控场景里性价比很高开发周期可控后期维护也简单。1.2 系统整体架构与技术选型考量先把架构说清楚不然后面讲细节容易散。整套系统分四层数据采集层、服务端层、前端展示层、告警通知层。采集层负责从逆变器和环境传感器辐照度、温度拿数据常见做法是通过 Modbus RTU/TCP 协议读取逆变器寄存器再由采集网关比如树莓派或工业 DTU打包成 JSON 通过 MQTT 或 HTTP 上报。服务端层接收数据、落库时序数据用 InfluxDB 或 TDengine业务数据用 MySQL、对外提供 REST 接口和 WebSocket 推送。前端展示层就是 Vue 应用负责实时看板、历史查询、设备管理、告警列表。告警通知层在服务端做规则判断触发后走站内消息或第三方通知渠道。前端技术栈我最终定的是Vue 3 Vite Pinia Vue Router ECharts Element Plus。为什么用 Vue 3 而不是 Vue 2Composition API 在处理“多个实时数据源汇聚到一个页面”这种场景时逻辑组织比 Options API 清晰得多可以把“订阅 WebSocket、处理数据、更新图表”这套逻辑抽成一个 composable 复用。Vite 的冷启动和热更新速度在开发监控大屏这种频繁调样式的场景下体验差距明显。Pinia 替代 Vuex状态管理更轻TypeScript 支持也更顺。ECharts 不用多说时序折线图、仪表盘、热力图它都能扛而且大数据量下开了large模式和dataZoom之后性能可以接受。Element Plus 提供表格、表单、弹窗这些基础组件省掉大量重复劳动。这里有个选型上的取舍值得说实时数据到底用 WebSocket 还是轮询。我一开始图省事用了setInterval每 5 秒拉一次接口结果页面开着十几个图表请求堆积、数据抖动、时间轴对不齐体验很差。后来换成 WebSocket服务端主动推前端收到就更新数据时序一致服务端压力也小。代价是要处理断线重连、心跳保活这些细节但这是值得的。监控系统的“实时感”是核心体验轮询做不到。注意技术选型没有绝对优劣如果电站规模很小、数据更新频率要求不高比如 1 分钟一次轮询反而更简单可靠。WebSocket 适合秒级更新、多客户端同时在线的场景。1.3 页面结构与数据流设计页面结构上我把它拆成五个主视图实时监控大屏、设备管理、历史数据分析、告警中心、系统设置。实时监控大屏是核心顶部是电站总览指标卡当前总功率、今日发电量、累计发电量、系统效率中间是功率曲线和辐照度对比图下方是逆变器状态卡片网格每张卡片显示设备名、实时功率、今日发电量、状态灯。设备管理页做增删改查和组串配置。历史分析页支持按时间范围、按设备维度查询发电量并导出。告警中心展示告警记录、支持确认和筛选。系统设置放告警阈值、通知方式这些配置。数据流是这样的采集网关上报 → 服务端解析入库 → 同时通过 WebSocket 广播给在线前端 → 前端 Pinia store 接收并分发到各组件 → 组件内 ECharts 实例更新。历史查询走 REST 接口前端拿到数据后渲染表格和图表。这个单向数据流设计的好处是职责清晰组件不直接碰 WebSocket只从 store 读数据测试和调试都方便。我在 store 里对实时数据做了环形缓冲只保留最近 N 个点避免长时间运行后内存无限增长这个细节后面会展开讲。2. 核心功能模块的细节解析与实操要点2.1 实时数据看板的组件拆分与更新策略实时看板最容易写成一坨所有逻辑塞在一个页面组件里几百行代码改一处牵动全身。我的做法是按“数据粒度”拆组件。总览指标卡是一个纯展示组件接收 props 渲染数字带一个数字滚动动画用requestAnimationFrame做插值比 CSS transition 更可控。功率曲线图是独立组件内部持有 ECharts 实例通过 watch 监听 store 里的曲线数据变化变化时调用setOption增量更新而不是重建实例。逆变器卡片网格用v-for渲染每张卡片是子组件只关心自己那台设备的数据。更新策略上有个坑我踩过不要每次数据推送都全量setOption。ECharts 的setOption默认是合并模式但如果每次都传完整配置内部还是会做大量 diff。正确做法是初始化时setOption一次完整配置后续更新只传变化的部分比如chart.setOption({ series: [{ data: newData }] })。另外曲线数据点多了之后要开sampling: lttb降采样否则几千个点渲染会卡。实测下来单条曲线 2000 个点以内流畅超过就开降采样视觉上几乎无损。数字滚动动画这里补充一个细节指标卡的数字从旧值跳到新值时如果直接赋值会显得生硬。我用一个小的插值函数在 300ms 内从旧值过渡到新值requestAnimationFrame驱动结束时清理。这个动画不能太长监控场景下数字频繁变化动画超过 500ms 会让人感觉数据“迟钝”。// 数字滚动插值示例Composition API 写法 import { ref, watch } from vue export function useAnimatedNumber(target, duration 300) { const display ref(target.value) let rafId null watch(target, (newVal, oldVal) { const start performance.now() const from oldVal ?? 0 const diff newVal - from cancelAnimationFrame(rafId) const step (now) { const progress Math.min((now - start) / duration, 1) display.value from diff * progress if (progress 1) rafId requestAnimationFrame(step) } rafId requestAnimationFrame(step) }) return display }提示动画函数里一定要cancelAnimationFrame否则快速连续更新时会叠加多个动画循环数字会乱跳。2.2 WebSocket 连接的封装与断线重连实时监控系统最怕的就是“连接悄悄断了页面还显示着旧数据”。WebSocket 封装我做了三件事心跳保活、断线重连、状态暴露。心跳是客户端每 30 秒发一个 ping 消息服务端回 pong超过 60 秒没收到 pong 就判定连接异常主动关闭并触发重连。重连用指数退避第一次 1 秒后重连失败则 2 秒、4 秒、8 秒上限 30 秒避免服务端刚重启时被大量客户端瞬间打爆。封装成一个 composableuseWebSocket内部维护readyState的响应式状态页面顶部根据这个状态显示“实时连接正常/重连中/已断开”的提示条。这个提示条很重要运维人员看到“重连中”就知道数据可能不是最新的不会误判。消息处理上我约定了一个简单的消息协议{ type: realtime | alarm | heartbeat, payload: {...} }前端按 type 分发到不同的处理函数而不是把所有消息都往一个回调里塞。// WebSocket 封装核心逻辑简化版 import { ref, onUnmounted } from vue export function useWebSocket(url) { const status ref(connecting) const handlers new Map() let ws null let retryCount 0 let heartbeatTimer null let pongTimer null const connect () { ws new WebSocket(url) ws.onopen () { status.value connected retryCount 0 startHeartbeat() } ws.onmessage (e) { const msg JSON.parse(e.data) if (msg.type pong) { clearTimeout(pongTimer); return } handlers.get(msg.type)?.(msg.payload) } ws.onclose () { status.value disconnected stopHeartbeat() scheduleReconnect() } } const scheduleReconnect () { const delay Math.min(1000 * 2 ** retryCount, 30000) retryCount setTimeout(connect, delay) } const startHeartbeat () { heartbeatTimer setInterval(() { ws?.send(JSON.stringify({ type: ping })) pongTimer setTimeout(() ws?.close(), 60000) }, 30000) } const stopHeartbeat () { clearInterval(heartbeatTimer) clearTimeout(pongTimer) } const on (type, fn) handlers.set(type, fn) connect() onUnmounted(() { stopHeartbeat(); ws?.close() }) return { status, on } }这段代码里onUnmounted的清理不能省否则组件销毁后定时器和连接还在切换路由几次就会积累一堆僵尸连接。我在测试时就遇到过这个问题页面来回切了十几次控制台里 WebSocket 连接数一直涨。2.3 时序数据的图表呈现与性能调优发电监控的图表主要是两类功率/辐照度时序折线图和发电量柱状对比图。折线图用双 Y 轴左轴功率kW右轴辐照度W/m²两条线放一起能直观看出“辐照度上去了功率有没有跟上”这是判断组件是否异常的重要依据。如果辐照度正常但功率明显偏低大概率是组串遮挡、积灰或者某路 MPPT 异常。ECharts 配置上有几个关键点。时间轴用type: time而不是类目轴这样数据点按真实时间戳分布间隔不均匀也不会失真。dataZoom开内置型支持鼠标滚轮缩放和拖动运维人员查某个时间段的细节很方便。tooltip用trigger: axis并开启axisPointer的十字准星鼠标移动时两条线的值同时显示对比直观。大数据量场景下series里加large: true和largeThreshold: 2000ECharts 会切换到更高效的渲染模式。性能调优方面除了前面说的降采样还有一个容易忽略的点图表容器尺寸变化时的 resize。监控大屏经常要适配不同分辨率或者用户拖动浏览器窗口。我用ResizeObserver监听容器尺寸变化防抖 200ms 后调用chart.resize()。不用window.resize是因为容器可能因为侧边栏折叠等原因变化而窗口尺寸没变ResizeObserver更准确。// 图表自适应封装 import { onMounted, onUnmounted, ref } from vue import * as echarts from echarts export function useChart(containerRef) { const chart ref(null) let observer null let resizeTimer null onMounted(() { chart.value echarts.init(containerRef.value) observer new ResizeObserver(() { clearTimeout(resizeTimer) resizeTimer setTimeout(() chart.value?.resize(), 200) }) observer.observe(containerRef.value) }) onUnmounted(() { observer?.disconnect() clearTimeout(resizeTimer) chart.value?.dispose() }) return chart }dispose()同样不能省ECharts 实例不销毁会泄漏 canvas 和事件监听。我在一个页面里放了六个图表切换路由不销毁的话来回几次内存占用肉眼可见地涨。2.4 告警规则的判断逻辑与前端呈现告警是监控系统的价值落点。规则判断放在服务端做前端只负责展示和交互。常见的告警规则有几类设备离线超过 N 分钟没收到数据、功率骤降当前功率比前 10 分钟均值低 50% 以上且辐照度正常、发电量偏低当日发电量低于同辐照度下的预期值、设备故障码逆变器上报了故障寄存器。阈值做成可配置的存在系统设置里不同电站可以调。前端告警中心用表格展示字段包括告警时间、设备、告警类型、级别严重/警告/提示、状态未确认/已确认/已恢复。级别用不同颜色的标签区分严重用红色、警告用橙色、提示用蓝色。支持按时间范围和设备筛选支持批量确认。实时告警通过 WebSocket 的alarm类型消息推过来前端收到后在页面右上角弹一个通知用 Element Plus 的ElNotification同时告警列表顶部插入新记录并高亮几秒。这里有个体验细节告警去重和聚合。同一台设备如果持续离线服务端不能每分钟都推一条新告警否则告警列表会被刷屏。我的做法是服务端维护告警状态机同一设备同一类型告警在“未恢复”期间只产生一条记录恢复时更新状态为“已恢复”并记录恢复时间。前端展示时未恢复的告警排在前面已恢复的可以折叠。这个逻辑看似简单但不做的话告警中心很快就没法看了。注意告警阈值不要设得太敏感。功率骤降阈值设 10% 的话一朵云飘过就触发一次运维人员会被烦到直接忽略所有告警。我一般建议骤降阈值不低于 30%且要求持续 5 分钟以上才触发过滤掉瞬时波动。3. 完整实操流程与关键环节实现3.1 项目初始化与目录结构规划从零搭项目第一步是初始化。用 Vite 创建 Vue 3 TypeScript 模板然后按功能域组织目录而不是按文件类型平铺。我的目录结构是这样的src/ ├── api/ # REST 接口封装 ├── assets/ # 静态资源 ├── components/ # 通用组件指标卡、图表容器等 ├── composables/ # 组合式函数useWebSocket、useChart 等 ├── layouts/ # 布局组件 ├── router/ # 路由配置 ├── stores/ # Pinia store ├── views/ # 页面级组件 │ ├── dashboard/ # 实时监控 │ ├── devices/ # 设备管理 │ ├── history/ # 历史分析 │ ├── alarms/ # 告警中心 │ └── settings/ # 系统设置 ├── utils/ # 工具函数 └── types/ # TypeScript 类型定义按功能域组织的好处是找一个页面的相关代码时不用在多个类型目录之间跳。views/dashboard/下面放这个页面专属的子组件通用的才提到components/。类型定义集中放types/设备、告警、数据点这些核心实体都定义 interface接口返回值全部有类型改字段时编译器会帮你找出所有受影响的地方。依赖安装上核心就几个vue、vue-router、pinia、echarts、element-plus、axios、dayjs时间处理比原生 Date 好用太多。开发依赖加typescript、vitejs/plugin-vue、unplugin-auto-import和unplugin-vue-components自动导入 Element Plus 组件省掉大量 import 语句。npm create vitelatest solar-monitor -- --template vue-ts cd solar-monitor npm install vue-router pinia echarts element-plus axios dayjs npm install -D unplugin-auto-import unplugin-vue-componentsVite 配置里加上自动导入插件Element Plus 的组件和 API 就不用每个文件手动 import 了。这个配置一次配好后面开发效率提升明显。3.2 数据模型定义与接口层封装数据模型是整个系统的骨架定义清楚后面写起来才顺。核心实体有四个电站Station、设备Device、数据点DataPoint、告警Alarm。设备里区分逆变器和环境传感器用type字段标识。数据点包含时间戳、设备 ID、功率、电压、电流、辐照度、温度这些指标。告警包含触发时间、设备、类型、级别、状态、恢复时间。// types/index.ts 核心类型定义 export interface Device { id: string name: string type: inverter | sensor stationId: string status: online | offline | fault capacity?: number // 额定功率 kW逆变器才有 } export interface DataPoint { timestamp: number deviceId: string power: number // kW voltage: number // V current: number // A irradiance?: number // W/m²传感器才有 temperature?: number // ℃ } export interface Alarm { id: string deviceId: string deviceName: string type: offline | power_drop | low_yield | fault_code level: critical | warning | info status: unconfirmed | confirmed | recovered triggeredAt: number recoveredAt?: number }接口层用 axios 封装一个实例统一处理 baseURL、超时、错误提示。请求拦截器里加 token如果有鉴权响应拦截器里统一处理业务错误码。每个业务模块的接口单独一个文件比如api/device.ts里放getDevices、getDeviceDetail、updateDevice这些函数返回值类型标注清楚。这样组件里调用接口时IDE 能直接提示返回数据的结构不用来回翻文档。3.3 Pinia store 的状态设计与实时数据缓冲store 的设计直接决定了组件之间的数据流转是否顺畅。我分了三个 storeuseDeviceStore管设备列表和当前选中设备useRealtimeStore管实时数据useAlarmStore管告警。实时数据 store 是重点它要处理 WebSocket 推送的数据并维护一个有限长度的历史缓冲。缓冲用数组实现每次新数据 push 进去超过上限比如 300 个点就 shift 掉最老的。300 个点按 5 秒一个点算覆盖 25 分钟足够看实时曲线了。更长的历史走 REST 接口查。这里用shallowRef而不是ref存数据数组因为数据点对象内部不需要深层响应式用shallowRef减少响应式开销大数据量下性能差别明显。// stores/realtime.ts import { defineStore } from pinia import { shallowRef, ref } from vue import type { DataPoint } from /types const MAX_POINTS 300 export const useRealtimeStore defineStore(realtime, () { const powerSeries shallowRefDataPoint[]([]) const latestByDevice refRecordstring, DataPoint({}) function pushPoint(point: DataPoint) { const next [...powerSeries.value, point] if (next.length MAX_POINTS) next.splice(0, next.length - MAX_POINTS) powerSeries.value next latestByDevice.value[point.deviceId] point } return { powerSeries, latestByDevice, pushPoint } })注意pushPoint里是创建新数组再赋值而不是直接powerSeries.value.push()。shallowRef的.value引用变了才会触发更新直接 push 不会触发。这是用shallowRef时容易踩的坑我第一次写的时候就忘了图表一直不更新排查了半天。3.4 路由与页面骨架搭建路由用createRoutercreateWebHistory五个主页面配好路径和组件布局用嵌套路由外层是带侧边栏和顶栏的MainLayout内层是各页面。侧边栏菜单根据路由配置自动生成图标用 Element Plus 的图标组件。路由懒加载用动态 import首屏只加载 dashboard其他页面按需加载打包体积能小不少。页面骨架先搭出来每个页面放个标题和占位内容跑通路由跳转和布局再逐个填充功能。这个顺序很重要先把“壳”跑起来后面填内容时随时能看到效果比闷头写完一个页面再集成要稳。布局上侧边栏可折叠折叠状态存 localStorage刷新后保持。顶栏放电站选择器多电站场景、连接状态提示、用户信息。这些看似是边角料但实际使用中运维人员每天都要碰做顺手了体验差别很大。3.5 实时监控页面的完整实现流程实时监控页是重头戏实现顺序我建议这样先做静态布局指标卡、图表容器、设备网格的位置和样式再接 store 数据让指标卡和图表动起来最后接 WebSocket 让数据实时更新。分三步走每步都能看到进展出问题也容易定位是哪一层的问题。指标卡的数据来自latestByDevice的聚合总功率是所有逆变器功率之和今日发电量从 REST 接口拿服务端按日聚合好的系统效率用“实际发电量/理论发电量”算理论值根据装机容量和辐照度积分估算。这个效率指标很有用低于 80% 就该查查是不是有组件异常了。设备网格里每张卡片显示设备名、实时功率、状态灯。状态灯颜色跟设备 status 走在线绿色、离线灰色、故障红色。卡片点击跳转到设备详情可以做成弹窗也可以做成独立页面我选的弹窗因为运维场景下频繁切换页面会丢失看板上下文。弹窗里展示该设备的详细参数和近 1 小时曲线。功率曲线图的数据源是powerSerieswatch 它变化时增量更新 ECharts。这里要注意powerSeries是shallowRefwatch 时要监听.value的引用变化用watch(() store.powerSeries, ...)或者直接watch(store.powerSeries, ...)都行但别用deep: true没必要且费性能。3.6 历史数据查询与导出功能落地历史分析页解决的是“事后追溯”需求。用户选时间范围快捷选项今日、昨日、近 7 天、近 30 天、自定义和设备点查询前端调 REST 接口拿聚合数据服务端按小时或按天聚合避免返回海量原始点渲染成柱状图或折线图下方配一个明细表格。表格支持分页导出按钮把当前查询结果导成 CSV。导出功能前端实现就行不用服务端参与。把表格数据转成 CSV 字符串加 BOM 头\uFEFF防止 Excel 打开中文乱码然后用BlobURL.createObjectURL触发下载。这个 BOM 头的坑很经典不加的话 Excel 打开中文全是乱码用户第一反应就是“你这系统有 bug”。function exportCsv(rows, filename) { const header 时间,设备,发电量(kWh),峰值功率(kW)\n const body rows.map(r ${r.time},${r.deviceName},${r.energy},${r.peakPower} ).join(\n) const blob new Blob([\uFEFF header body], { type: text/csv;charsetutf-8 }) const url URL.createObjectURL(blob) const a document.createElement(a) a.href url a.download filename a.click() URL.revokeObjectURL(url) }revokeObjectURL记得调否则 blob 占用的内存不会释放。导出大量数据时这个细节有实际影响。4. 常见问题排查与实操避坑实录4.1 实时数据相关的高频问题问题一图表数据更新了但曲线不动。排查顺序先看 store 里数据有没有变Vue DevTools 看再看 watch 有没有触发加 console.log最后看setOption传的参数对不对。我遇到最多的是shallowRef直接 push 不触发更新以及setOption时 series 的name对不上导致新数据被当成新系列。ECharts 更新 series 时是按name或id匹配的初始化时给每个 series 设了id更新时带上同样的id最稳妥。问题二WebSocket 频繁断连。先看网络环境代理或负载均衡可能对空闲连接有超时限制心跳间隔要小于这个超时。再看服务端有没有对消息大小做限制数据包太大被拒也会断。还有一种情况是前端页面在后台标签页时浏览器会节流定时器心跳发不出去导致服务端判定超时。解决办法是监听visibilitychange页面隐藏时降低心跳频率或暂停回到前台时立即发一次心跳并检查连接状态。问题三时间轴对不齐。前端展示的时间和设备上报的时间差了几个时区或者服务端存的是 UTC 前端没转。统一约定服务端存 UTC 时间戳毫秒前端展示时用 dayjs 转本地时区。ECharts 的 time 轴默认按本地时区渲染传时间戳进去就行别传格式化好的字符串字符串解析容易出时区问题。4.2 性能与内存问题的排查思路监控大屏长时间开着是常态内存泄漏必须重视。常见的泄漏点ECharts 实例没 dispose、WebSocket 没 close、定时器没 clear、事件监听没移除。排查方法是用 Chrome DevTools 的 Memory 面板隔一段时间拍一次堆快照对比对象数量增长。如果 detached DOM 节点持续增长基本就是组件销毁时没清理干净。另一个性能问题是大量设备时的渲染卡顿。如果一个电站有上百台逆变器卡片网格全量渲染会卡。解决办法是虚拟滚动用vue-virtual-scroller之类的库只渲染视口内的卡片。或者做分页/分组按区域或按状态筛选后再渲染。我实测过200 张卡片全量渲染首次渲染要 1 秒多滚动也掉帧用虚拟滚动后首屏 100ms 内完成滚动流畅。问题现象可能原因排查方法解决方式曲线不更新shallowRef 未触发 / series id 不匹配DevTools 看 store、watch 加日志创建新数组赋值、统一 series id连接频繁断开心跳超时 / 后台节流看断连时间间隔规律调小心跳间隔、监听 visibilitychange时间显示错乱时区未统一对比服务端与前端时间戳统一 UTC 存储、前端本地化展示页面越用越卡实例/监听未清理Memory 面板堆快照对比组件卸载时 dispose/close/clear设备多时卡顿全量渲染Performance 面板看渲染耗时虚拟滚动或分页4.3 数据准确性与边界情况处理监控系统的数据准确性是底线几个边界情况必须处理。设备刚上线还没有数据时指标卡不能显示 0 或 NaN要显示“--”并标注“等待数据”。除零问题计算系统效率时理论发电量可能为 0夜间辐照度为 0要做判断夜间直接显示“--”而不是除零得到 Infinity。时间范围查询为空时图表要显示“暂无数据”的空状态而不是一片空白让人以为页面坏了。还有一个容易忽略的数据乱序。网络传输不保证顺序WebSocket 推送的数据时间戳可能比上一条还早。前端 push 到缓冲时要做一次判断如果新数据时间戳小于最后一条就插入到正确位置或者直接丢弃实时曲线场景下丢弃更简单历史查询走接口不受影响。不做这个处理的话曲线会出现“往回折”的锯齿看起来像数据异常。提示所有涉及数值计算的地方都加一层Number.isFinite判断非有限值统一转成 nullECharts 遇到 null 会断线而不是画到 0视觉上更符合“数据缺失”的语义。4.4 部署与长期运行的注意事项部署上前端打包成静态文件Nginx 托管配置 history 模式的路由回退try_files $uri $uri/ /index.html否则刷新非首页会 404。WebSocket 需要 Nginx 配置 upgrade 头转发这个不配的话生产环境连接直接失败本地开发却正常很容易漏。长期运行方面前端本身是无状态的重启无影响。但要注意浏览器缓存策略静态资源带 hash 文件名可以长缓存index.html必须不缓存或短缓存否则发版后用户拿不到新版本。我在 Nginx 里对index.html设了Cache-Control: no-cache其他资源一年缓存发版体验很顺。最后分享一个实操心得监控类系统的“空状态”和“异常状态”设计比正常状态更重要。正常有数据时页面都好看但设备离线、查询无结果、连接断开这些状态如果处理得粗糙用户会以为系统坏了。我在这套系统里给每种异常状态都做了明确的文案和视觉提示上线后运维人员的反馈是“至少知道是没数据还是系统挂了”这个体验提升比多加几个图表实在得多。
