做可视化数据大屏这几年，我最大的感受是：图表好写，动效难调。尤其是领导或客户走近大屏的那一刻，如果页面全是干巴巴的柱状图和折线图，哪怕数据再准确，观感上总觉得少了一口气。后来我在自己的大屏项目里沉淀了一个叫 FlowingLight 的流光动效插件，专门解决“大屏看起来不够活”的问题。它能给页面边框加上流动光带、给地图上的链路加上粒子流光，也能直接把 ECharts 的曲线坐标拿过来当路径，让数据真的“流”起来。
FlowingLight 的定位很明确：不替换 ECharts、不侵入业务代码，它只在一层独立的 Canvas 上做“光效叠加”。免费、开源、配置简单，体积也很小，适合正在做可视化数据大屏、运维监控大屏、展厅指挥大屏的前端开发和可视化工程师。这篇文章我打算把它的设计思路、接入方法和我在项目里踩过的坑一次说清楚，照着抄能省不少时间。
1. 先想明白：大屏上的流光到底在表达什么
1.1 大屏是“观看型”界面，不是“操作型”界面
做后台管理系统时，用户盯着一个表格半天不动，界面安静是对的，因为眼睛要长时间停留在数据上。数据大屏完全反过来。它的使用场景基本是：人在几米外扫一眼，几秒钟内要感受到“这个系统是活的、数据在跑、状态正常”。这种观看模式下，静态图表的信息传递效率其实是偏低的，人的视觉天然更容易被运动物体吸引。
所以好的数据大屏，都会在关键位置放一点动效。不是动画越多越好，而是要在边框、链路、流动方向这些地方做有引导性的运动。“流光”就是其中最常用的一种：一条光沿着边界或者路径不断流动，让人第一眼就知道“这段线路正在传输数据”或“这个模块正处于运行状态”。FlowingLight 要做的，就是把这类效果从“每次用手搓Canvas代码”变成“填配置就行”。
1.2 FlowingLight 要解决的三个具体问题
先说我为什么决定把流光效果单独抽成一个插件。在此之前我做过不少大屏，发现大家反复在问三件事：
- 页面层次感弱，所有版块都是矩形边框，看不出主次。
- 数据链路关系看不出来，比如两条飞线从 A 点到 B 点，静态线根本没法表达“正在传输”。
- 大屏上线后没有“运行感”，领导站着看了一分钟，觉得系统像截图。
这些问题用流光都能解决。给核心版块加一圈流动光边，视觉层级马上出来了；给链路加粒子光流，方向感和动态感也出来了。FlowingLight 把这些能力统一成一套 API，内部处理路径计算、粒子调度、性能优化，业务侧只需要告诉它“光往哪儿走”。
下面这张对比应该更直观：
| 表现手段 | 能表达的信息 | 维护成本 |
|---|---|---|
| 静态边框 | 区域划分 | 最低 |
| 静态飞线 | 连接关系 | 低 |
| 闪烁装饰 | “这里有东西” | 中 |
| ECharts 自带 effect | 数据流向 | 中 |
| FlowingLight 流光 | 流向、活跃度、层级感 | 低 |
2. FlowingLight 的核心设计：一条光，两种走法
2.1 整体架构：只做一个独立 Canvas 动效层
FlowingLight 的第一个设计原则是不污染业务代码。它不往 DOM 里塞一堆 div，也不去改 ECharts 的 option，而是在大屏容器上覆盖一个透明的 Canvas 层。所有流光都在这个 Canvas 上绘制，和底下已有的图表完全解耦。
这样有几个实际好处。一是上线和回滚都方便，出问题把 Canvas 层隐藏掉，业务不受任何影响。二是多个图表之间可以共享同一条流光路径，比如一个跨模块的链路关系，不需要分别写在两个图表的 option 里。Canvas 层本身是透明的，CSS 里设一行pointer-events: none，就不会挡住 ECharts 的 tooltip 和缩放操作。
我遇到过不少开发同学觉得“多一个 Canvas 层会不会太重”。其实不会。一个全屏 Canvas 2D 的绘制开销完全可控，流光的粒子数量又不是无上限增长，后面我会专门讲性能参数怎么调。
2.2 路径抽象：一段坐标数组就够用
FlowingLight 对路径的抽象非常简化，核心就一种数据结构：有序坐标点数组。矩形边框提供rect快捷生成，折线、曲线、飞线这些场景直接传points数组就行。
// 路径的本质就是这些点 const path = { type: 'polygon', points: [ { x: 100, y: 80 }, { x: 500, y: 80 }, { x: 500, y: 300 }, { x: 100, y: 300 } ] };你可能觉得这没什么技术含量，但正因为路径被简化为“点数组”，它才能和 ECharts 无缝衔接。ECharts 内部所有线、折线、地图边界，最终渲染时都会变成一个个的坐标点。拿到这些点交给 FlowingLight，就等于把手绘图表的路径原样复制到光效层上，两边天然对齐。
2.3 流光粒子的运动原理
流光效果看起来复杂，本质上是若干小光点在一条路径上连续移动。每个光点有一个参数 t，表示它走了整条路径的百分之多少。帧循环把 t 不断累加，再根据 t 在路径上插值出当前坐标，画出来就是一个移动的光点。
当多个光点按不同间隔分布在同一条路径上，并且每个光点尾部拖着渐变色拖尾时，人眼就会把它拼接成“一条流动的光带”。这个原理不神秘，很多游戏引擎里的轨迹效果也是这么做的。FlowingLight 只是把“路径插值”“光晕渐变”“拖尾长度”这些步骤打包好，用配置项暴露出来。
核心参数有三个：count控制光点数量，length控制拖尾长度，speed控制流动速度。调这三项，效果差异非常明显。比如监控大屏的链路要给人“数据正在稳定传输”的感觉，speed 取 1.2 左右比较合适；如果是告警高亮，可以临时把 speed 拉到 3 以上，人眼立刻会被吸引。
2.4 为什么选择 Canvas 2D，而不是 CSS 或 SVG
这个选择我纠结过一段时间。最开始做流光边框时用 CSS 动画也能实现，但 CSS 只能绕矩形或圆形走，遇到折线、地图边界、ECharts 任意曲线就无能为力了。SVG 可以用 stroke-dashoffset 做虚线流动，效果也不错，但复杂路径多的时候 DOM 节点暴增，性能风险大，还不好做粒子光晕。
最后选 Canvas 2D，是因为它在路径复杂度和性能之间最平衡。Canvas 没有节点数量压力，几十条路径几百个粒子一帧就能画完；光晕可以通过shadowBlur或渐变模拟，效果足够平滑。FlowingLight 内部还用了一个小技巧：把每条路径上的粒子位置预先算好，缓存到数组里，只有路径变化时才重新采样，这样运行时循环里只做增量和绘制，性能开销很小。
3. 最快速的接入姿势：把 FlowingLight 装进你的大屏
3.1 引入方式：npm 和 script 标签都能用
FlowingLight 的构建产物是单文件 JS，编译后大约 10KB 左右，没有运行时依赖。如果你的项目是 webpack、vite 这类工程化环境，可以直接作为模块引入。如果是一个老项目或者想快速做 Demo，直接下载dist/flowing-light.min.js，用 script 标签挂到页面上也有全局变量可用。
import FlowingLight from 'flowing-light';<script src="./dist/flowing-light.min.js"></script> <script> // 此时全局上会有 FlowingLight 构造函数 const light = new FlowingLight({ ... }); </script>我个人的习惯是刚开始做效果验证时用 script 标签，确认完效果再改成模块引入。这样不会把临时调试代码混进工程依赖里。
3.2 最简示例：给大屏套一个流光边框
最常见的需求就是给大屏页面加一个外边框流光。FlowingLight 里可以直接用type: 'rect'生成圆角矩形路径，几行代码就能跑起来。
const light = new FlowingLight({ container: document.getElementById('screen'), paths: [ { type: 'rect', x: 10, y: 10, width: 600, height: 400, radius: 8, color: '#00e5ff', count: 10, length: 60, speed: 1.2, width: 2, blur: 6, loop: true } ] }); light.start();这里container是承载大屏的容器，流光 Canvas 会自动铺满容器。radius: 8让边框四个角变成圆角，流光在拐角处会自动做平滑过渡。width是光带的线条宽度，blur是光晕强度。第一次跑通后建议只调这三个视觉参数，先别贪多，找到感觉再继续加内容。
3.3 进阶效果：把流光接到 ECharts 曲线和地图飞线上
如果说边框流光只是开胃菜，那和 ECharts 结合的部分才是正餐。ECharts 官方其实自带 lines 图系列的 effect 效果，很多地图飞线的流光就是用它实现的。但它的问题是：效果绑定在某个 series 上、参数不够细致、而且自带的拖尾效果在复杂线路上偶尔会出现渲染闪烁。
FlowingLight 的做法是从 ECharts 实例上把图形坐标读出来，再作为自定义路径交给流光层绘制。这样 ECharts 图表只管数据展示，光效层单独加工，互不干扰。我自己一般这样取 ECharts 的路径坐标：
const chart = echarts.init(document.getElementById('chart')); // 正常 setOption 渲染图表 chart.setOption(option); // 从 ECharts 内部取渲染后的折线坐标 const displayList = chart.getZr().storage.getDisplayList(); const rect = document.getElementById('chart').getBoundingClientRect(); const points = []; displayList.forEach((el) => { if (el.type === 'polyline' || el.type === 'line') { const shape = el.shape; if (shape && shape.points) { shape.points.forEach((p) => { points.push({ x: p[0] - rect.left, y: p[1] - rect.top }); }); } } }); const light = new FlowingLight({ container: document.getElementById('chart'), paths: [ { type: 'polygon', points, color: '#76ff03', count: 12, length: 40, speed: 1.5, width: 2, blur: 5, loop: true } ] }); light.start();这段代码里有个关键点：ECharts 的坐标是相对于 canvas 内部的，而 FlowingLight 的路径坐标是相对于 container 的，所以要做一次rect.left和rect.top的换算。大多数流光错位问题，最后查下来都是这一步漏了。
地图飞线的做法类似。用 ECharts 的 lines 系列先渲染飞线，再从显示列表里把线段的坐标点读出来。FlowingLight 会自动把不闭合的路径首尾相接，在两条端点之间循环流动。
3.4 配置项速查表
我把常用配置项整理成了表格，调试时对照着改会快很多。
| 配置项 | 类型 | 默认值 | 说明 |
|---|---|---|---|
| container | HTMLElement | 必填 | 承载光效的容器 |
| paths | Array | [] | 路径配置数组 |
| type | string | 'polygon' | rect 或 polygon |
| points | Array | [] | 多边形路径的坐标点 |
| x/y/width/height | number | - | rect 路径专用 |
| radius | number | 0 | 圆角大小 |
| color | string | '#00e5ff' | 流光颜色 |
| count | number | 10 | 同路径上的光点数量 |
| length | number | 40 | 拖尾长度，单位像素 |
| speed | number | 1 | 流动速度倍率 |
| width | number | 2 | 光带线条宽度 |
| blur | number | 4 | 光晕模糊半径 |
| loop | boolean | true | 是否循环流动 |
3.5 两种使用模式：装饰型 vs 数据联动型
用了一段时间之后，我习惯把 FlowingLight 的方案分成两种。一种是“装饰型”，光只在大屏固定位置流动，比如边框、标题分隔线、背景线路，纯视觉增强，和业务数据关系不大。另一种是“数据联动型”，光必须跟着数据状态变化，比如告警时某条光变红、数值异常时流光加速、链路切换时路径重绘。
装饰型接入很简单，初始化一次就行。数据联动型需要你额外注意状态变化时怎么更新插件。FlowingLight 提供了updatePath(pathIndex, newConfig)和removePath(pathIndex)方法，业务层只需要在数据变更时调用对应方法，不需要整个插件重建。这个设计帮我避了很多坑，尤其是大屏自动轮询数据时，频繁销毁重建 Canvas 会带来明显的卡顿。
4. 实操实录：我在监控大屏里接入 FlowingLight 的完整过程
4.1 需求梳理：哪些区域值得加流光
有一次做一个数据中心监控大屏，客户要求屏幕必须是“一眼就能看出系统在运行”。接到需求后我没有急着写代码，而是先在稿子上圈了四个位置：最外层整体边框、中间的网络链路图、两侧的实时指标牌、底部的滚动告警条。这四个位置分别承担“整体氛围”“数据流转”“重点展示”“告警提醒”四种角色。
圈完之后我给每个位置定了流光参数：外边框用蓝色，速度慢一点，只求氛围；网络链路用绿色，速度中等，表达数据流动；指标牌的边框用橙色，只在数值变化时短暂闪烁；告警条直接在出现告警时用红色流光高亮。需求定了，参数自然就清楚了。
4.2 落地步骤拆解
整个接入过程我分五步走，这也是我建议你复用的流程：
- 先搭一个独立测试页面，尺寸和真实大屏一致，用假数据调 FlowingLight 的参数。
- 把调好的配置写进一个独立的
lightConfig.js文件，和大屏业务代码分开。 - 在业务大屏初始化完成后，调用 FlowingLight 的初始化方法。
- 联调数据联动逻辑，比如告警流光的触发和复位。
- 切到低端显卡的机器上实测帧率，针对卡顿做参数降级。
这五步里最花时间的是第一步。因为大屏实际部署的屏幕经常是拼接屏，分辨率和开发机的比例不一样，流光坐标如果依赖硬编码，换一台机器很可能就歪了。所以我强烈建议所有坐标都基于 container 的宽高按比例计算，FlowingLight 内部虽然做了容器尺寸变化的重绘处理，但业务侧传进去的 points 最好是相对比例坐标，而不是绝对像素。
4.3 联调时最容易被忽略的细节
联调阶段我踩过一个很典型的坑：ECharts 图表在一次渲染后，内部显示列表的顺序，并不是按照 setOption 时 series 的书写顺序来的。所以最初读取坐标时，用forEach直接遍历显示列表会把多条折线的点混在一起，流光路径完全乱掉。
后面我改成按 seriesName 过滤图形元素，只读取目标 series 对应的点，路径才恢复正常。这里给你一个比较可靠的思路：取坐标前先console.log(displayList)看元素结构，确认好过滤条件再写代码，别凭直觉猜。
另一个细节是设备像素比。大屏开发机的 devicePixelRatio 经常是 1，但高清拼接屏可能是 2 甚至更高。FlowingLight 初始化时会读取window.devicePixelRatio做画布缩放，如果你是在 iframe 里嵌入的，最好手动传一下dpr参数，否则流光在某种屏幕上会发虚或者变粗。
4.4 效果验收：怎么判断流光“到位了”
我判断流光效果是否达标的办法比较朴素：把大屏切到静态截图，再切回动态页面，如果动态版能让人明显感觉“这些数据是活的”，就说明氛围到位了。如果切换前后差别不大，那就继续调速度或者增加粒子数。
还有一条验收标准容易被忽略——距离。如果大屏实际观看距离是三米以上，流光宽度和拖尾长度建议适当加大，因为站在远处看，2 像素的光带几乎等于没有。我在监控大屏项目里最终把外边框流光宽度提到了 3、拖尾长度拉到了 80，效果才明显。
5. 踩坑记录：流光效果常见问题与排查办法
5.1 常见问题速查表
先给一个速查表，你遇到对应现象可以直接在这里找答案。
| 现象 | 可能原因 | 处理办法 |
|---|---|---|
| 流光不动 | 没调用 start()，或容器不可见时初始化 | 确认调用 start()，容器可见后再初始化 |
| 光效非常模糊 | shadowBlur 太大 | 把 blur 控制在 2 到 8 之间 |
| 边框流光拐角断裂 | 路径点没有闭合 | polygon 模式自动闭合，rect 模式检查 radius |
| 流光错位 | 坐标系换算漏了 | 确认 points 是相对 container 的坐标 |
| tooltip 被挡住 | Canvas 拦截了鼠标事件 | 给光效 Canvas 设 pointer-events: none |
| 切回标签页掉帧 | 浏览器暂停了 rAF | 监听 visibilitychange 后重置时间戳 |
| 多条路径颜色错乱 | 全局变量被修改 | 每个 FlowingLight 实例使用独立状态 |
5.2 三个我印象最深的偏门问题
第一个是“标签页切回来之后流光突然快进”。原因是浏览器在后台会暂停requestAnimationFrame，切回来时积压的帧时间全被一次性执行，导致粒子瞬移一大段。FlowingLight 内部在处理帧率时用了增量时间限制，把单帧位移钳制在一个安全范围，切回来之后看起来会稍微平滑一些。这里也提醒大家：如果自己手写动画，一定不要用固定的+= step方式累加粒子位置，最好基于上一帧的实际时间差来计算。
第二个是“圆角矩形边框的流光在四个角出现叠影”。原因是我最初实现时把圆角路径分成了四段圆弧和四条直线，粒子在分段拼接处会短暂重复绘制。解决办法是路径采样时不按段独立计算，而是把整条路径展开成一个连续的采样表，粒子每次只按总进度去采样。这样不管路径是不是圆角、有多少折点，流动都是连续的。
第三个是“页面用 transform 缩放后流光错位”。很多大屏为了适配不同分辨率的屏幕，会对整个页面做 scale 缩放。Canvas 同时被缩放后，光效的坐标和宽度都会被拉伸，容易出现光带变形。FlowingLight 的对策是监听容器的尺寸变化，在检测到缩放后重新执行一次路径采样，你可以把这个事件周期性地连上页面 resize 流程。
5.3 性能敏感型大屏怎么进一步优化
如果你的大屏同时跑多个图表、数据轮询、还有视频流，那流光这层动效也要学会做减法。以下几个优化点是我实测有效的：
- 单条路径粒子数控制在 20 以内，通常 8 到 12 个就够了。
- 全屏区域只放一两个大面积流光，小模块之间不要互相抢视觉重心。
- 把
blur调小或关掉，shadowBlur 在低端设备上是最耗性能的绘制操作之一。 - 动态数据频繁更新时，增加一个手动控制开关：数据轮询期间暂停流光，轮询结束后再恢复。
- 大屏页面在同一个标签页里，切换路由或隐藏某些模块时，记得调用
light.destroy()释放 Canvas，避免内存持续上涨。
6. 不是所有大屏都适合加流光，怎么判断
6.1 适合用 FlowingLight 的典型场景
从我经历的项目看，有三类大屏非常适合：
- 监控运维大屏：系统状态本身是动态的，流光能强化“实时监测”的感觉。
- 指挥调度大屏：线路上流动的光点能清楚表达事件流向和处理进度。
- 展厅展示大屏：观众需要在短时间内被吸引，流光的大视觉张力很占优势。
这几种大屏的共同点是：页面结构稳定、信息层级分明、观众离屏较远且停留时间短。流光在这些场景起的是引导和氛围作用，而不是和详细数据抢注意力。
6.2 建议慎用的场景
有一类大屏我不建议加过多流光，就是“个人深度分析型”的数据工作台。用户需要长时间阅读表格、对比数值、查看明细，这时候屏幕上一堆光带只会制造干扰。还有一种是页面本身信息密度极高的情况，图表密密麻麻，再加流光很容易让画面显得脏。
如果项目判定真的需要，我的建议是把流光局限在页面边框和标题装饰上，不要动图表内部。总之，克制比炫技重要。
6.3 使用时的审美原则
最后分享几个我坚持的原则。第一，流光颜色不要超过三种，最好和大屏的主色调一致，常用的蓝绿系、青紫系都很安全。第二，速度不要拉满，默认的 1 倍速就够大部分场景用了，速度太快会让人焦虑。第三，流光数量宁少勿多，一个页面同时只要有一到两个“视觉活跃点”，整体节奏就是舒服的。
给了这么多配置参数和接入方法，最后还想提醒一句，千万别忘了流光本身是给大屏加分的配角，数据内容的准确性和清晰度才永远是第一位。动效做得再漂亮，数据逻辑讲不清楚，大屏照样没有灵魂。
我个人使用 FlowingLight 的习惯是：每个项目先花 30 分钟在独立页面把光效参数调熟，再花 10 分钟接入业务代码，这样后期返工最少。试试这个顺序，你会发现让大屏“活”起来没那么复杂。
