第一部分：数据实时更新怎么做
方式一：定时轮询
javascript
setInterval(() => {
fetchLatestData(); // 定时请求接口，拿最新数据
}, 5000); // 每5秒刷新一次简单直接，适合数据更新频率不需要特别高、允许几秒延迟的场景（大屏很多场景其实够用）。
方式二：WebSocket（更实时的场景）
如果要求数据变化后立刻反映到大屏上（比如安全事故实时告警这种场景，多等几秒可能都不行），用WebSocket让后端主动推送，比前端不停轮询更及时，也更省资源（不用无谓地一直发请求问"有没有新数据"）。
第二部分：长时间运行会出现的问题
1. 内存泄漏（最核心、最常被问到的坑）
页面挂几天不刷新，如果代码里有没清理的定时器、没解绑的事件监听、没销毁的图表实例 ，这些东西会在内存里越堆越多，最终导致页面卡顿、崩溃、甚至浏览器直接假死。
常见的内存泄漏来源：
setInterval定时器，如果组件销毁了但没有clearInterval（大屏这种页面通常不会真的销毁组件，但如果做了页面内的切换/路由跳转，这个问题就会暴露）- ECharts图表实例，如果数据更新时不断创建新的图表实例，没有销毁旧的 （正确做法应该是复用同一个实例，用
setOption去更新数据，而不是每次都echarts.init()创建一个新的） - 大量DOM节点持续增加、没有被清理（比如滚动的告警列表，如果只做"添加新消息"，没有限制列表长度、移除旧的，DOM节点会无限增长）
2. 网络请求累积/连接不稳定
长时间挂着，网络可能会有波动、短暂断开。如果用的是WebSocket，需要处理断线重连 逻辑；如果是轮询，某一次请求失败了，要保证不会因为一次失败就导致整个定时任务停掉，需要做好异常捕获，让下一次轮询能正常继续。
3. 页面本身长时间不刷新，可能会"卡在旧版本"
如果开发团队上线了新版本，但大屏页面没有重新打开/刷新，用户看到的可能一直是旧代码在跑。有的大屏项目会做定时自动刷新整个页面 （比如每隔几小时location.reload()一次），既能规避内存泄漏累积的风险，也能保证代码是最新的------这是个简单粗暴但很实用的方案，面试提到这个会显得有实战经验。
总结
"数据更新方面，一般场景用定时轮询就够用，如果要求更高的实时性（比如告警类数据），会考虑WebSocket让后端主动推送。大屏长时间运行最需要注意的是内存泄漏------比如定时器要记得清理、ECharts图表要复用实例用setOption更新数据而不是每次重新init、滚动列表类的数据要限制长度避免DOM节点无限增长。另外网络波动导致请求失败也要做好异常捕获，不能因为一次失败就导致后续更新全部停掉。一些大屏项目还会做定时整体刷新页面（比如每隔几小时reload一次），既能规避长时间运行的潜在内存问题，也能保证展示的是最新版本的代码。"