猫拽智库
结论：低代码能做数据大屏，但边界很清楚。固定指标、低频刷新、内网展示这类需求，低代码直出最划算；高频动画、地图轨迹、几十万点实时渲染这类需求，应该把渲染交给专业图表库或大屏工具。先判断落在哪一侧，再谈技术选型，能省掉大量返工。
一、先看三个上限
低代码平台的图表能力通常基于成熟图表库封装，所以瓶颈不在「能不能画出来」，而在「多久刷一次、一屏放多少、一次喂多少数据」。
上限一：刷新频率
低代码页面最稳的是轮询（Polling），30 秒到 5 分钟一次属于舒适区（经验区间）。要求亚秒级更新时，必须引入 WebSocket 或消息队列做推送，页面本身不负责流式更新。
上限二：单页图表数量
一屏 6 到 12 个图表比较稳（经验区间）。超过 20 个，首屏渲染时间与定时刷新会互相拖累，切换筛选条件时尤其明显。
上限三：数据点规模
折线图单序列几千点、单页总量几万点，多数图表库还能跑；几十万点逐点渲染必须做抽样或聚合。这里的数字是经验区间，实际取决于浏览器、数据量与查询复杂度。
二、适合与不适合：一张对照表
判断标准不按行业，按六项特征：刷新频率、图形类型、数据规模、使用场景、交互深度、指标稳定性。
| 维度 | 适合低代码直出 | 不适合 |
|---|---|---|
| 刷新频率 | 30 秒至 5 分钟轮询（经验区间） | 亚秒级刷新、要求服务端推送 |
| 图形类型 | 柱状、折线、饼图、指标卡、简单漏斗 | 地图轨迹、3D 场景、粒子动画 |
| 数据规模 | 聚合后的千级到万级数据点 | 几十万点逐点渲染、逐帧过渡 |
| 使用场景 | 内网会议室、部门周会、领导看板 | 对外展厅、品牌级演示 |
| 交互深度 | 筛选、下钻、联动、导出 | 复杂联动、时间轴回放、多屏同步 |
| 指标稳定性 | 指标口径固定，长期复用 | 指标天天变，一次性临时需求 |
六行里只要有两行落在右侧，就别硬用低代码直出。看板选型的通用判断方法，可参考拖拽式数据看板工具怎么选。
三、三种架构，按上线速度与视觉要求权衡
架构一：低代码直出页面
用平台自带的图表组件加数据集配置，不写前端代码。上线最快，通常小时级到天级；代价是视觉上限受组件库约束，动效与版式自由度有限。适合内部固定指标的驾驶舱，具体图表选型参考管理驾驶舱图表选型教程。
架构二：低代码做数据服务，前端用专业图表库
低代码负责数据源接入、SQL 聚合、权限校验与定时任务，对外暴露统一 API；大屏前端单独做一个工程，用 ECharts、DataV 一类专业库渲染。
这种拆分把「取数」和「画图」解耦：指标口径与权限留在平台，视觉与动效交给前端。代价是要维护两个工程，接口契约必须提前定好。可视化编辑器如何组织画布与渲染，可参考可视化拖拽编辑器架构拆解。
架构三：大屏专用工具加低代码后台
大屏工具负责渲染与动效，低代码负责指标配置、数据维护、权限与审批。适合对外展厅或品牌级演示，视觉上限最高，但两套系统的数据口径最容易走偏。
| 架构 | 上线速度 | 视觉上限 | 维护成本 | 适用场景 |
|---|---|---|---|---|
| 低代码直出 | 最快 | 中等 | 低 | 内网固定指标看板 |
| 低代码加专业图表库 | 中等 | 高 | 中 | 需要权限体系与定制视觉 |
| 大屏工具加低代码后台 | 偏慢 | 最高 | 高 | 展厅、对外演示 |
四、性能优化的五个动作
大屏卡顿大多不是图表库的问题，而是取数与渲染方式的问题。
- 聚合查询前置。把求和、计数、去重放到 SQL 的 GROUP BY 或物化视图里，不要让前端拿十万行再算。
- 按时间窗口缓存。5 分钟刷新的指标没必要每次打库，缓存结果并标注数据时间，避免所有人同时穿透到数据库。
- 分页与抽样。趋势图超过一定点数就按时间桶聚合，保留峰值标记，否则细节全被压平。
- 控制推送频率。WebSocket 每来一条数据不立即渲染，合并 200 到 500 毫秒内的更新再刷新（经验区间）。
- 避免全量重绘。复用图表实例，只更新变化的数据集；离开页面时销毁定时器与连接。
还有两条容易忽略：首屏只初始化可见区域的图表，其余等切换后再加载，减少一次性渲染压力；同一屏里共享数据源的图表，共用一次查询结果，不要各查一遍。
五、落地步骤与验收清单
先定指标，再量数据，最后选架构。顺序颠倒，选型必然返工。
- 写指标字典：名称、口径、数据源、刷新频率、责任人，一屏不超过 12 个指标
- 量数据底数：最大表行数、单次查询耗时、同时看屏的人数
- 按第二节对照表判定，落在右侧两行以上就换架构
- 先做一屏验证版，只上最重要的 6 个图表，实测首屏与刷新表现
- 上线后监控查询耗时、失败率与刷新延迟，设置阈值告警
验收时按这七条打勾：
- 首屏在目标时间内出图（按内网环境实测设定，不用外部数字对齐）
- 上一次请求未返回时，不发起下一次刷新，避免请求堆积
- 接口失败时有兜底提示，不展示空图或伪造数据
- 1920×1080 与 4K 分辨率下版式不错位，缩放不留黑边
- 切换页面时定时器与 WebSocket 连接被销毁
- 抽取三个指标与业务系统人工核对，口径一致
- 不同部门看到的数据范围符合权限设计
实施建议：把取数、聚合与权限收在服务端，前端只负责渲染。猫拽低代码（CatPull）是 Apache-2.0 开源的自托管低代码平台，采用可视化设计器加 DSL Schema 路线，页面可在平台内迭代，也可导出 uniapp 工程接手，适合做数据服务与后台管理，图表渲染交给专业图表库，官网 https://www.catpull.com 可在线体验。
FAQs
Q1：低代码大屏能不能做到 1 秒刷新？
A：能画，但别指望轮询。1 秒级刷新要靠服务端推送，并且要控制渲染频率、只更新变化的数据集。如果指标本身不是秒级业务，把刷新降到分钟级，稳定性和成本都会好很多。
Q2：几十万点的地图轨迹，低代码能做吗？
A：直出方案做不了。正确做法是后端按时间段聚合轨迹点、前端只渲染抽样后的路径，或改用支持大规模数据渲染的专用可视化工具。数据量再大时，还要考虑分片加载与按缩放层级取数。
Q3：大屏工具和低代码要维护两套数据，怎么避免口径不一致？
A：把指标定义收在一处，由低代码侧统一对外提供接口，大屏工具只消费接口不直连数据库。同时在指标字典里登记口径与版本，改口径时同步通知两端负责人。
