大屏很容易让人先看见颜色。深色背景、不断跳动的数字和地图上的光点，会让页面看起来像一个正在运行的系统。但真正决定它有没有用的，往往是更安静的部分：每个数字从哪里来，多久更新一次，缺失时怎样显示，换一个人看能不能得到同样的解释。
bigdata-frontend 的公开提交从初始化到上传页面调整，留下的是一个前端项目的骨架。它没有告诉我某个数字代表真实业务结果，也没有给出一套可以替代数据字典的说明。因此这次回看不再写“点亮了城市”，只记录一个大屏项目应该先做哪些基础工作。
第一步是把指标写成句子，而不是只写变量名。所谓“活跃用户”是当天登录、最近七天有操作，还是当前在线？“完成率”是提交数量除以任务数量，还是去重后的人数？如果口径没有在接口和页面之间保持一致，组件越漂亮，误解越容易被放大。
第二步是确定时间。轮询、推送和缓存各自解决不同问题，不能为了让数字动起来而随意缩短刷新间隔。数据源五分钟才更新一次，页面每秒请求也不会产生更准确的结果，反而会增加服务压力。相反，真正需要实时提醒的指标应该有单独的事件入口，而不是和所有卡片共享一个定时器。
第三步是处理空值和异常。接口还没返回时，骨架屏只是视觉占位；接口返回空数组时，它应该说明“暂无数据”，不能显示一个像零一样的 0。网络失败时，保留上一次数据并标注时间，有时比整块区域消失更诚实。状态清楚以后，页面才有机会成为判断工具，而不是演示录像。
大屏的视觉仍然重要，但它应该服务于比较和定位。颜色需要有稳定的含义，动效不能抢走读数，图表要给出单位和时间范围。对一个人维护的小项目来说，少做几种组件，反而能把每一种状态都测试完整。
我现在更愿意把大屏看成一层“翻译”。它把数据库里的记录翻译成一个人可以快速理解的画面，但翻译不能删掉上下文。每次新增一张卡片，都要问这张卡会改变什么决定；如果没有决定，只是在增加热闹。
项目的初始化提交很短，正好提醒我不要把页面数量写成成果。真正值得留下的是数据字典、接口约定和异常状态。它们不如一束光点好看，却能让下一个维护者知道屏幕上的数字为什么在那里。
大屏项目还要给指标留下出处。接口文档记录字段含义，数据字典记录单位和时间范围，页面则显示最近更新时间与异常状态。三者缺一时，用户只能凭颜色猜测，维护者也无法判断是数据源变化还是组件计算出了问题。
当数据量变大，性能优化也应从测量开始。减少无意义的轮询、合并重复请求和限制图表点数，通常比先换一个更炫的可视化库更可靠。优化结果要和加载时间、请求数或渲染耗时对应起来，不能只写“感觉更流畅”。
大屏的数据链路可以先压缩成下面这张图。视觉组件只是最后一层，前面的口径、时间和异常状态才是数据能不能被相信的基础。
