# 温度看板大屏渲染与性能优化方案

针对复杂温度看板（包含海量测点数据、多维度图表、高频实时刷新）的场景，结合当前技术栈（前端 `Vue 3.5.30 + Vite 7 + Element Plus`，后端 `Spring Boot 3.5.12 + MyBatis-Plus 3.5.16 + JDK 17~25`），特梳理以下浏览器渲染极致优化与性能降压方案。

## 一、 前端渲染降压与内存优化 (Vue 3.5 + Vite 7)

### 1. 响应式系统开销缩减
* **`shallowRef` 替代 `ref`**：图表原始数据、海量列表数据（如 `TempBoardRealtimeVo` 数组）完全不需要具备深层响应式。使用 `shallowRef` 存储后端返回的大数组，避免 Vue 递归遍历对象属性挂载 `Proxy`，极大降低初始化耗时和内存占用。
* **`v-memo` 按需渲染**：对于复杂的测点卡片列表，利用 Vue 3 的 `v-memo` 指令，仅当卡片关注的温度值或报警状态发生变化时才重新渲染 DOM，避免整个列表的无意义 Diff。
* **`markRaw` 脱绑**：ECharts 实例图表对象（echarts instance）必须使用 `markRaw` 脱离响应式，或者保存在普通的非响应式变量中。

### 2. 局部视图与长列表优化 (Element Plus)
* **虚拟滚动 (Virtual Scrolling)**：摒弃传统 `el-table`，全面倒向 Element Plus 提供的虚拟化表格 `el-table-v2`，或使用 `vueuse` 的 `useVirtualList`。对于超过百条的明细列表，只渲染可视区域的 DOM 节点，DOM 数量维持在两位数，彻底消除滚动卡顿。
* **可视区域才渲染 (Lazy Rendering)**：针对首屏底部的分布分析、同比图表等，配合 `@vueuse/core` 的 `useIntersectionObserver`，当组件滚动到视口时再触发接口请求与图表渲染。

### 3. ECharts 图表渲染极限优化
* **开启按需局部渲染（Canvas vs SVG）**：折线点超过 1000 个时，强制使用 `Canvas` 渲染器；少于 500 时考虑 `SVG`。
* **数据降采样 (Data Sampling)**：前端 ECharts 开启 `sampling: 'lttb'`（最大面积保持降采样算法），在不丢失趋势极值的情况下大幅减少渲染的点数量。
* **关闭不必要的动画与提示**：对高频刷新的实时折线图，关闭 `animation`，或将 `hoverAnimation` 置为 `false`，降低 GPU 绘制压力。开启 `appendData` 用于增量追加数据，而不是每次 `setOption` 塞入全量数据。

### 4. 线程分离与主线程释放
* **Web Worker 解析数据**：如果后端依然传输了庞大的 JSON（例如上万个点的原始数据），利用 Vite 自带的 `?worker` 方便地将耗时的数据结构转换（如 Array 转换为 ECharts 需要的 Category/Value 结构）放入 Web Worker 线程处理，避免阻塞浏览器主 UI 线程导致假死。

## 二、 后端接口与传输优化 (Spring Boot 3.5.12 + JDK 25/21/17)

### 1. 数据降维与聚合 (Downsampling)
* **不要把原始数据抛给前端**：在温度趋势分析中，跨度一天的分钟级数据存在 1440 个点，跨度一月的秒级数据量更是灾难。应当在数据库或代码层进行聚合。
  * *聚合策略*：使用 SQL Server 的随时间窗口分组聚合，或使用 Java 实现 **LTTB (Largest Triangle Three Buckets)** 下采样算法。把千万像素级的数据压缩到前端屏幕宽度能显示的像素点（如 500-1000 个点）再落接口。

### 2. JDK 新特性与并发压榨
* **虚拟线程 (Virtual Threads - JDK 21+)**：结合 Spring Boot 3，启用虚拟线程 `spring.threads.virtual.enabled=true`。由于看板报表往往需要并行请求多个测点、多个维表的统计数据，使用 `StructuredTaskScope` 或 `CompletableFuture` 配合虚拟线程并发查询 `TempBoardMapper` 的各项指标，极大降低请求响应时间（RT），且无惧高并发阻塞。
* **ZGC/G1 调优**：确保后端 JVM 启用低延迟垃圾回收器（JDK 21 默认 G1，强烈推荐开启分代 ZGC `-XX:+UseZGC -XX:+ZGenerational`），消除由于内存回收造成的接口响应“毛刺”波动。

### 3. 传输层与带宽优化
* **Brotli / Gzip 开启**：在 Nginx 或 Spring Boot 开启 Brotli 压缩机制，温度时序数据的高重复性使其拥有极高的压缩率，JSON 载荷体积可缩小 70%~85%。
* **SSE (Server-Sent Events) 增量推送**：对 "B. 实时监控" 模块，摒弃前端定时器轮询拉取（setInterval）。采用 Spring SseEmitter 推送增量温变数据。

## 三、 浏览器与渲染流水线优化

1. **CSS `contain` 属性**：在独立的图表容器和列表容器使用 `contain: strict;` 或 `contain: content;`，明确告诉浏览器这个 DOM 子树独立，避免局部的重排重绘扩散到整个大屏。
2. **GPU 硬件加速**：对滚动容器、动效组件开启 `transform: translateZ(0)`，将图层交由 GPU 合成。
3. **避免 Layout Thrashing（强制同步布局）**：检查项目中通过 `getBoundingClientRect`、`offsetWidth` 触发大小自适应的代码（如 ECharts `resize`），配合 `requestAnimationFrame` 防抖批量执行，切忌在循环中读写 DOM。

## 四、 总结：大屏降压黄金链路
1. **数据库层**：查询分区表 -> 时序下采样。
2. **后端层**：JDK 21 虚拟线程并行组装 -> Redis 毫秒级缓存 -> 分代 ZGC 防抖 -> Brotli 极度压缩。
3. **前端层**：流式/SSE 接收 -> Web Worker 组装格式 -> `shallowRef` 规避代理 -> ECharts Canvas LTTB渲染 / `el-table-v2` 虚拟DOM滚动 -> GPU 合成展示。
