企业官网建设流程全解析

接触过不少做数据可视化的朋友，也看过很多号称“可视化大屏”的项目。坦白说，大部分最后都沦为了“展厅装饰品”——开完一次发布会或领导参观后，就再也没人打开。真正能让人每天主动打开、愿意盯着看、甚至能直接影响业务决策的，反而是那些设计简洁、逻辑清晰的“智慧看板”。这个项目标题里提到的“可能是最直观的数据展示”，我觉得点到了一个特别本质的东西：可视化的核心不是把数据画得多漂亮，而是让数据在最短时间内被理解和吸收。换句话说，智慧看板要解决的，从来不是“怎么画图”，而是“怎么让人看懂”。

这篇博文，我想围绕“智慧看板”这个场景，把从设计思路、技术选型、实操落地到问题排查的完整链路整理一遍。这里面既有业务层面的思考，也有代码层面的实现，还有一些我踩过的坑。不管你是产品经理想要梳理数据页面结构，还是前端工程师要接一个可视化大屏项目，或者是数据分析师想把成果更好地呈现出来，这篇文章应该都能给你一些可参考的东西。

1. 内容整体设计与思路拆解：先想清楚看板给谁看

做智慧看板，最常见的失败原因不是技术不够硬，而是需求没想明白。很多人一拿到需求就开始画图、调颜色，结果做完发现业务方说“这不是我想要的”。所以拿到一个看板项目，头几天我基本不动手，先跟业务方反复确认三个问题：看板给谁看、看完要做什么决策、最不能忍多久不更新。

1.1 受众决定信息密度和视觉风格

很多参考案例里，可视化大屏会做成那种线条感很强的科技蓝，背景搞得很炫酷，然后塞满了各种图表。这种风格放在展厅或领导视察的场合没问题，但放在日常办公的智慧看板里就非常不合适。日常盯数据的人，要的是快速定位异常、对比趋势、发现问题，信息密度反而要克制。

我给看板分过三种受众类型，不同受众对设计和技术的要求完全不同：

• 决策层（老板/高管）：只看结果，看健康度，看趋势。对应的是总体概况、核心KPI、关键异常告警。视觉上要突出核心数字，最好一眼能看完一整页。
• 管理层（部门负责人/项目经理）：除了看结果，还要看比较、看目标完成率、看团队产出。需要带有分组对比、趋势走势、漏斗转化这类分析性图表。
• 执行层（运营/开发/一线人员）：看明细、看分派、看待办，需要和自己的工作流挂钩。这类看板往往不只是“看”，还要有筛选、跳转、详情下钻。

这三种受众对应到同一个智慧看板项目里，往往需要分成三种视图或三级页面。如果全部塞在一个页面上，一定会有人觉得“信息太多”或“信息不够”，两头不讨好。

1.2 业务指标体系是看板的灵魂

我见过一个工厂车间看板，一上来就做了二十几个指标：设备开机率、产能、良率、物料消耗、能耗、人员出勤、订单完成数……图表非常丰富，但现场经常开早会的班组长说他从来不看，因为找不到“今天到底有没有问题”。后来沟通才发现，他其实只关心三件事：产线今天有没有异常停机、良率有没有低于目标值、订单能不能按时完成。这二十几个指标里，只有五六个是他需要盯的。

这件事特别能说明看板设计的第一原则：指标不在多，在于能不能支撑行动。建立指标前，我一般会先和业务方一起列出每个指标对应的“行动”。如果你列不出这个指标背后对应的行动项，或者行动项和指标之间关系很勉强，这个指标就应该从看板上拿掉，至少不能放在主视图上。

指标体系建设有一个简单的方法，叫“三级拆解”：

• 一级指标：直接反映核心目标，通常是营收、订单量、活跃用户数、设备综合效率这类“一把手”指标。放最顶上，字体最大。
• 二级指标：支撑一级指标的过程性指标。比如营收拆成新客收入和老客复购收入，订单量拆成各渠道订单占比，设备综合效率拆成可用率、性能、良率。这些是分析异常时重点看的。
• 三级指标：更明细的运营数据和基础数据，比如具体某个渠道的转化率、某台设备的停机时长分布。这类适合放在下钻页面或明细表里，不适合铺在主页面。

三级拆解做完之后，看板的信息架构基本就有了雏形：顶部是一级指标总览，中部是二级指标的对比和趋势，底部或抽屉里是三级明细数据。这个结构符合人的阅读习惯，也符合“先看结果、再看原因、最后追细节”的决策路径。

1.3 叙事逻辑：让看板自己会说话

一个优秀的智慧看板，它的布局结构其实是在讲一个故事。用户的视线需要被引导：首先看到最重要的数字，知道“现在怎么样”；然后看到趋势变化，知道“是变好了还是变坏了”；接着看到对比和分类，知道“问题出在哪个部分”；最后通过明细和下钻，知道“具体是哪个环节、哪条数据出了问题”。这就是看板的叙事逻辑。

很多刚做可视化的人容易犯一个毛病：把看板当成图表的堆砌，哪里有空位就放什么图。结果是信息之间没有关联，看完一遍大脑还得自己做二次拼接，理解成本非常高。我们在设计布局时，要刻意保持模块之间的逻辑关联，比如同比环比数字旁边一定要配趋势折线图，分类占比图旁边尽量配一个排名列表，这样看图的人不用来回找就能建立因果联系。

2. 核心细节解析与实操要点：常见可视化技术和方案选型怎么定

思路理清楚之后，接下来就是技术层面的选择。在可视化大屏和智慧看板领域，市面上的工具和框架非常多。我的建议是：不要在选型上花太多时间纠结，也不要盲目追随最新的框架，而是根据你的团队结构、数据规模、集成方式、可维护性来做判断。

2.1 可视化框架横向对比

如果把现阶段的常用方案拉出来看，大概可以分成这么几类：

如果是个人项目或小团队快速交付，我推荐Vue（或React）+ ECharts的组合。ECharts 生态成熟、案例丰富、配置项强大，并且支持按需引入，做出来的图表跨浏览器兼容性也不错。更重要的是，ECharts 对“时间序列、实时刷新、大数据量渲染”这几个看板核心场景支持很完善，文档和社区资料也足够多，遇到问题基本都能查到解决方案。

如果项目不是从零开始，而是需要一个开箱即用的数据可视化平台，DataEase 和 Superset 这种开源BI工具也值得考虑。特别是 DataEase，它有“可视化大屏模板”的概念，支持拖拽式布局和数据集接入，交付速度非常快。不过要注意，这类工具的强项是“快速出图”，一旦涉及复杂的自定义交互（比如点击地图区域联动其他图表、某个数据点需要跳转内部系统），实现起来就比较麻烦，需要额外开发插件或者干脆放弃一部分交互。

2.2 图表类型的选择逻辑：别让“好看”干扰“好懂”

图表类型的选择也是常见翻车点。一个很典型的场景：数据是“某一天各小时的下单量分布”，有人为了视觉效果用了面积图，还是带渐变色的那种。结果用户看不清楚波峰波谷，因为面积图的填充色干扰了数据线的判断。

图表类型的选择应该优先服从数据关系。我总结了一个特别简化的对应关系：

• 趋势变化：折线图、面积图
• 排名对比：条形图（横向）永远比柱状图（纵向）更好使，因为类别名称更长，横向排布阅读更自然
• 构成占比：饼图适合不超过5个类别的场景，超过5个建议改用横向条形图或者堆叠柱状图
• 目标进度：仪表盘、进度条，不要用环形图硬凹
• 多维分布：热力图、散点图
• 地理信息：地图，但地图只有当数据真的有地域洞察价值时才用，不要为了“炫”放一张全国地图上去

还有一个细节：同一张看板里，尽量减少相似图表的重复出现。如果整屏都是折线图，用户看久了会视觉疲劳；如果整屏都是柱状图，重点信息反而没办法凸显出来。合理的做法是用“1个大图（核心趋势或核心分布）+ 多个小图（辅助指标）”的方式做视觉层次，核心信息用大尺寸和高饱和色标突出，次要信息用统一的中性色降低存在感。

2.3 关于可视化大屏适配这件事

“可视化大屏适配”是很多前端朋友最头疼的地方。不同项目的显示器分辨率五花八门：有的用普通电脑显示器，有的是1920×1080，有的是3840×2160的4K大屏，还有的是拼接屏——每块屏之间甚至还有物理缝隙。如果适配方案选得不对，做完的看板在开会那天就会出现字体忽大忽小、错位、背景露白等尴尬情况。

我踩过的坑和最终沉淀下来的方案是：优先采用“固定尺寸设计稿 + 动态缩放适配”的方案。

具体做法：设计稿按 1920×1080 来做，页面根节点上所有尺寸都用 px。运行时检测当前浏览器窗口尺寸和设计稿尺寸的比例，然后动态给最外层的容器设置 transform: scale()，比如设计宽度1920，当前宽度是2560，就缩放 2560/1920 ≈ 1.333 倍。这样可以保证页面始终保持设计稿比例，不会因为分辨率不同而出现布局错乱。

缺点是如果你的屏幕比例不是16:9，上下或左右会出现留白。但实际项目中大多数指挥中心、会议室大屏都是16:9，小部分超宽比例的用背景渐变色填充也能掩盖过去。这个方案的实现成本最低、效果最可控，适合绝大多数“把代码写到浏览器并在大屏上全屏打开”的场景。

如果你用的是商业BI工具比如 DataV 或 DataEase，它们自带适配方案，一般做一次分辨率映射配置就行。但要注意：拼接屏的物理缝隙不会因为软件适配而消失，所以关键信息（数字、标题）要避免落在屏幕拼接处，设计时建议把核心内容放在中间位置，边缘留出安全区。

2.4 实时数据刷新的技术选型：轮询、WebSocket还是流处理

智慧看板区别于普通报表的一个重要特征就是实时性。最先需要考虑的就是数据更新机制。目前主流的有三种方式：

• 定时轮询：前端每隔几秒调一次后端接口，实现简单，适合数据量小、接口响应快的场景。缺点是会产生大量无效请求，数据更新频率高时服务端压力大。
• WebSocket 长连接：服务端主动推送数据变更到前端，适合实时性要求高、数据变化频繁的场景（比如实时订单、设备状态）。缺点是后端需要额外维护连接状态，复杂度高一些。
• SSE（Server-Sent Events）：服务端单向推送，比 WebSocket 更简单，适合“数据一直更新、但前端只需要被动接收”的场景。

对于大部分智慧看板，我建议第一步先做轮询，刷新频率控制在 5～10 秒。这是因为很多业务系统本身的数据库写入就有延迟（比如数据先从设备采集到消息队列，再做ETL写入报表库），轮询太快反而容易查出半截数据，导致前端出现“数值跳来跳去”的情况。如果后面真的需要秒级实时展示（比如监控系统、大促订单大屏），再升级到 WebSocket 方案不迟。

需要注意，实时刷新不只是“前端定时调接口”这么简单。图表在数据更新时不能整屏闪烁或重新加载，否则用户盯久了会累，而且会打断对连续趋势的观察。需要让图表的数据更新保持“无缝感”，比如折线图的 x 轴滑动、柱状图的高度过渡。ECharts 在 setOption 时默认会做 diff 和动画过渡，只要你传入的是同一系列的数据，它会自动执行平滑更新。这个细节如果忽略了，实时刷新的体验会差很多。

3. 实操过程与核心环节实现：从数据接入到看板落地

这一部分以一个“智慧工厂产线看板”为例，把从数据接入、数据加工、接口开发到前端渲染的完整链路走一遍。开篇提到的热词里好几次出现“智能工厂数据如何录入和展示”，其实这是智慧看板应用特别典型的场景，我们就按这个场景展开。

3.1 数据源接入：先解决“数据从哪来”的问题

智能工厂的数据来源通常非常分散：设备PLC会定时产出一个状态数据；MES系统记录了每个工单的产量和工时；质量检测系统每批次会生成良率数据；能耗系统则有自己的独立计量表。要把这些数据汇总到看板上，首先得有一个汇聚层。

最直接的方式是建一个独立的报表数据库，比如 MySQL 或 PostgreSQL。业务系统的数据通过定时任务（可以是 Python 脚本、可以是 Airflow，也可以是简单的 cron + SQL）同步到这个报表库，针对看板需求做轻度的预聚合。前端只需要连这个报表库写好的视图或接口，不直接连业务库，避免影响生产系统性能。

对于实时性要求更高的场景，数据链路一般是：设备/业务系统 -> Kafka -> Flink/Spark Streaming -> Redis/ClickHouse -> 查询接口/WebSocket推送。但这类实时流式架构对团队技术要求比较高，如果当前业务量不大，不必为了“实时”而实时。先把基础的数据同步做好，能覆盖大部分看板需求。

关于Redis，多说一句。相关热词里出现了很多“redis可视化工具”相关热搜，可见大家对Redis的操作和管理场景关注度很高。在智慧看板系统里，Redis 可以扮演两个角色：一是充当业务系统写给看板系统的实时数据缓存通道——业务方把最新指标写进Redis，看板后端定时读取再推给前端，比直接查数据库快得多；二是作为看板查询接口的结果缓存层——对热门查询结果做几十秒的缓存，降低数据库压力。如果你在管理Redis，建议不要再用命令行一个个敲key，直接用开源的可视化工具比如 Another Redis Desktop Manager 或 Redis Insight，效率提升非常明显，特别是排查“为什么缓存没生效”这类问题的时候，可视化客户端能直接看到key的过期时间和value内容，省掉一半抓瞎时间。

3.2 数据加工与接口开发：把原始数据加工成“看板想看的”

原始数据一般不能直接给看板用。比如设备PLC记录的状态是一个数字编码，0代表待机，1代表运行，2代表故障，3代表维护；而看板上要显示的是“设备运行率=运行时间/总时间”。这个加工逻辑不能放前端做，前端只做展示，加工必须在后端完成。

后端接口设计我比较推荐这种方式：前端把“看板想看到什么”定义为接口返回的JSON结构，后端围绕这个结构去组织数据。换句话说，接口返回的数据结构基本就是前端图表配置的结构，不额外绕弯。

举个例子，前端要展示一条“今日设备综合效率趋势”折线图，后端接口可以返回：

{ "code": 0, "data": { "categories": ["08:00", "09:00", "10:00", "11:00", ...], "series": [ { "name": "综合效率", "type": "line", "data": [85.2, 86.1, 87.3, 82.4, ...] } ] } }

前端拿到这个结构，几乎不用二次加工，直接 setOption 就能渲染。这种“后端做好数据结构、前端只管填图表”的方式在团队协作中非常重要，能省掉大量前后端联调时反复改字段、改格式的时间。

数据加工过程中要特别小心时区问题和聚合口径问题。比如“今日产量”到底是按自然日算，还是按班次算？工厂经常有跨日倒班，凌晨2点产出的数据应该算前一天还是当天？这些问题如果不和业务方对齐，做出来的数字就会和ERP系统对不上，看板一旦出现“数据对不上”，用户信任度会迅速崩塌，后面再怎么炫也很难拉回来。

3.3 前端页面实现：从 layout 到 ECharts 配置

前端开发这块，我直接给一个可以落地的简化方案。以 Vue 3 + ECharts 为例，整个页面结构可以拆成这么几个部分：

1. 顶部 KPI 总览区：一行三个大数字卡片，展示当日产量、实时良率、设备开机率。数字字体要大，颜色要突出，可以有简单图标辅助。
2. 中部核心趋势区：左右两个大图，左边是“产量/良率趋势折线图”，右边是“产线工单进度堆叠柱状图”。
3. 底部辅助信息区：一个排行表（比如“各产线停线时长Top5”），一个圆形进度图（比如“当日计划完成率”），一个滚动告警列表。

组件的写法上，不要把所有图表配置都堆在一个 .vue 文件里，建议封装一个通用的 BaseChart 组件：

<template> <div ref="chartRef" style="width:100%;height:100%"></div> </template> <script setup> import * as echarts from 'echarts' import { ref, onMounted, onBeforeUnmount, watch } from 'vue' const props = defineProps({ option: { type: Object, required: true } }) const chartRef = ref(null) let chartInstance = null onMounted(() => { chartInstance = echarts.init(chartRef.value) chartInstance.setOption(props.option) window.addEventListener('resize', handleResize) }) watch(() => props.option, (val) => { chartInstance.setOption(val) }, { deep: true }) function handleResize() { chartInstance && chartInstance.resize() } onBeforeUnmount(() => { window.removeEventListener('resize', handleResize) chartInstance && chartInstance.dispose() }) </script>

页面容器组件只负责“获取数据 -> 构建 option -> 传给 BaseChart”。这种结构最大的好处是：图表初始化和数据更新逻辑抽离了，后续做组件复用、单元测试都会轻松很多。

ECharts 配置项里的几个细节容易踩坑：

• y轴刻度：如果数据是百分比，确认 yAxis.max 是否设为 100。特别是实时刷新过程中，如果数据偶尔超过100%，图表会自动扩展坐标轴范围，导致图形比例突变，视觉上会很奇怪。
• 折线图平滑与断点：数据源中有 null 值时，默认会断线。如果希望断点处连续，需要设置 connectNulls: true。
• tooltip 的展示格式：默认tooltip格式化程度不够，建议用 formatter 做统一处理，比如数字千分位、百分比保留位数、时间格式化等。看板使用者最依赖的就是鼠标悬停时的具体数值，这一块值得花时间精调。
• 颜色风格统一：建议在一开始就定义一套调色板常量，比如主色、辅助色、告警色、成功色。不要在图表中散落写死色值，不然后期改主题会想哭。

3.4 数据刷新与已有系统的联动

轮询接口，更新图表，这个动作本身并不复杂，但有一个细节要处理好——在切换页面或最小化浏览器时停止轮询，回到页面时再恢复并立即拉一次最新数据。如果不做这个处理，浏览器标签页在后台跑着定时器，时间久了不仅浪费资源，还可能导致定时任务积压，返回页面时出现连续请求拥堵。

实现上，可以用 Vue 的 beforeDestroy/beforeUnmount 钩子里 clearInterval，配合 document.visibilitychange 事件做页面可见性检测。其实这个处理对移动端场景尤其有意义，移动端浏览器对后台标签页的定时器节流更狠，不问的话还会造成数据更新不同步。

如果看板系统需要和已有用户系统打通（比如登录后才允许看某些敏感指标），建议后端接口统一走鉴权中间件。不要把鉴权逻辑散落在各个接口里，更不建议把数据库密码写在前端配置文件中。看板涉及的数据往往包含企业核心经营数据，安全怎么强调都不为过。

4. 常见问题与排查技巧实录：看板上线后你会遇到的坑

这一部分整理了我在智慧看板类项目中实际遇到的高频问题，每个问题都附带排查思路和解决方案，建议收藏起来当速查表用。

4.1 图表数据长时间不更新

排查思路分四步走：先看浏览器 Network 面板，确认前端有没有发出轮询请求；再看请求返回状态码和响应内容，确认后端有没有正常返回最新数据；接着看后端日志，确认查询数据库的时间和数据是否更新；最后排查数据同步任务，确认源头表有没有新写入。

绝大多数情况下，问题出在数据同步任务没有执行成功，但看板本身没有报错，所以用户以为是刷新机制坏了。我们在设计时有一个关键建议：在页面上展示数据的“最后更新时间”。如果时间停留在几小时前，用户一眼就能发现异常，而不是反复问“你这个看板是不是卡了”。这个细节不复杂，但能省下大量沟通成本。

如果数据源来自 Redis 缓存，还要额外注意缓存穿透和缓存过期的问题。用可视化工具如 Another Redis Desktop Manager 可以直接查看 key 的 TTL 和 Value，比在代码里打印日志调试快得多。比如你发现接口一直返回的是旧数据，打开Redis客户端一看，发现某个 key 的过期时间被设置成了永不过期，那问题就是业务方更新完数据后没有主动刷新缓存，得在写入数据时同步做缓存更新。

4.2 图表标签重叠或文字截断

这在大屏场景中太常见了。有时候是因为屏幕分辨率不匹配，导致字体显示比例异常；有时候纯粹是ECharts默认的 label 展示位置不够聪明。比如柱状图顶部显示数值，柱高太短时数值会和上方柱子的label挤在一起。

处理办法：给 label 设置 rotate 或调整 formatter 策略；对于数值过小的柱子，可以配置为只在柱子内部显示或通过富文本自定义位置；对于折线图的坐标轴日期刻度，如果太密集，让 xAxis 开启 hideOverlap 自动避让，或者把刻度标签改为隔几个显示一个。

4.3 大屏在不同分辨率下有黑边或变形

这个问题在拼接屏、投影仪、会议室电视上特别突出。如果采用的是固定设计稿 + 动态缩放方案，核心是把全局缩放比例计算正确。推荐用“scale = Math.min(窗口宽/设计稿宽, 窗口高/设计稿高)”来算，这样可以保证整个页面完整呈现在可视区域内，不溢出也不裁剪。

部分浏览器对缩放后的 ECharts 点击事件坐标计算有偏移，需要在 transform 外层额外记录 scale 比例，并在事件处理时做反向换算。如果你不想处理这个复杂度，也可以考虑 rem 适配方案——把设计稿宽度分成若干等份，页面所有尺寸都用 rem 单位。但这个方案对“按比例绘制点和线”的场景没有 transform 方案友好，个人还是推荐 scale。

4.4 数据实时性引起的“数值跳动”

这个问题经常出现在数据还在写入的过程中前端就把半截数据拉了出来。比如一条订单状态一开始是“待支付”，几秒后变成“已支付”，看板上如果按状态实时聚合，就会看到数字来回跳。造成用户强烈不信任感。

解决方案有两种：一是后端做快照服务，统一在时间窗口结束后生成统计结果放到缓存里，前端只读快照；二是前端做平滑过渡和防跳变，比如对变化幅度设置更新阈值，微小的数值波动不触发动画。我建议优先做第一种，因为第二种本质上是在掩盖数据质量问题，久了会积累更大的信任风险。

4.5 接口响应太慢导致首屏白屏

看板页面往往包含十几个图表，如果每个图表各自调用接口且串行执行，首屏速度会非常慢。优化思路：

• 把首屏必需的数据聚合到一个接口，减少HTTP连接次数；
• 后端对高频查询加缓存，查询时间可以从几百毫秒降到几十毫秒；
• 前端做按需加载：核心KPI和趋势图优先渲染，底部次要图表可以等主流程加载完后再拉取；
• 如果图表数量特别多，考虑开启 ECharts 的图表懒加载，滚动到可视区域才初始化。

4.6 实时更新时浏览器内存持续上涨

经常是轮询接口的数据没有释放造成的。ECharts 每次 setOption 都会重新合并配置和数据，如果传入的是一个不断增长的数组（比如把实时点一直 push 到 categories 和 series.data），内存会持续上涨。

正确的做法是限定窗口长度：最多只保留最近 N 个点，数据满后每次从头部 shift 掉最早的点。如果 N 比较大（比如上千），还可以考虑用 setInterval 做批量更新而不是每来一条数据就 render 一次，减少ECharts的渲染压力。

5. 总结与个人经验：做完一个看板之后，我更关注的几件事

关于智慧看板这个场景，我还有几点从实际项目中沉淀下来的体会，不是套话，是踩了坑、推倒重来之后总结出来的。

第一，看板永远不是“做完”的，它是运营出来的。业务在变，指标在变，组织架构在变，看板作为业务数据入口，也需要持续迭代。上线那天数据是怎么定义的，三个月后很可能已经过时了。所以项目交付后，最重要的是培养业务人员“提需求”的习惯，让他们敢于说“这个指标不对”“这个图看不懂”，然后把它迭代成大家真正会用的工具。

第二，数据质量比数据展示重要得多。一个颜值在线但数据偶尔出错的看板，比一个颜值普通但数据永远正确的看板更容易被弃用。宁可先花时间把口径、时区、延迟、缓存、异常值处理这些“吃力不讨好”的环节搞定，也不要一开始就陷在配色、动画和3D特效里。

第三，如果可能，给看板留一个“钻取”的出口。也就是让用户在看板上点击某个异常指标后，能够跳转到对应的高峰报表、原始工单或告警系统。这样看板就不仅仅是一个展示工具，而是一个具备工作流入口的“业务操作台”，它的价值会提升一个层级。

第四，所有看似细腻的体验细节，都值得在design阶段就要考虑到，而不是等测试提出时才补。比如打点字段的时间精度、系统时区和用户时区的差异、单位换算、千分位展示、null值的语义。这些东西不会让页面看起来更炫，但决定了一个看板能不能真正“被信任”。

最后分享一个实际教训：有一个看板项目上线之后老有人反馈“不对”，排查了很久，最后发现根本原因是某个设备的数据采集程序在午夜12点左右会重启，重启期间数据不上报，导致每天0点的那条记录始终缺数据，前端所有图表在跨天位置都出现了一个小凹陷。后来在前端做了“缺失标记”并在tooltip里明确显示“该时段暂无数据”，质疑声立刻就消失了。所以，不要试图让前端假装所有数据都正常，直面数据缺口，并把缺口可视化出来，本身就是一种关于真实的专业度。

做智慧看板这件事，说到底比拼的并不是谁家的图更炫、谁家的屏更大，而是谁能把一整柜的原始数据，提炼成几条让人一看就懂、该动手就动手的可视化信息。这条路没有终点，项目上线只是另一个迭代周期的开始。