正确。全屏布局需彻底禁用浏览器默认滚动与缩放，html, body { margin: 0; padding: 0; width: 100%; height: 100%; overflow: hidden; }缺一不可，且overflow: hidden必须作用于html根元素，仅设在body无效；同时须用100vh + position: fixed应对iOS Safari视口跳变，并以transform: scale()替代rem实现精准等比拉伸，配合WebSocket断连状态恢复机制保障大屏长期稳定运行。
全屏布局必须禁用浏览器默认滚动和缩放
数据大屏在电视或投屏设备上运行时，只要出现滚动条或意外缩放，整个驾驶舱就失效了。关键不是“撑满窗口”，而是让 html 和 body 彻底放弃控制权：
html, body { margin: 0; padding: 0; width: 100%; height: 100%; overflow: hidden; }缺一不可。尤其 overflow: hidden 要写在 html 上，只写 body 无效——浏览器会把滚动留给根元素。
常见错误：用 vh 单位做高度但没处理 iOS Safari 的地址栏隐藏导致的视口跳变；解决方案是统一用 100vh + position: fixed 容器包裹内容层，避免依赖动态视口计算。
Canvas 和 SVG 渲染性能卡在 DOM 重排上
大屏里高频刷新的折线图、实时热力图，如果用 div 模拟点或格子，每秒 30 帧都难维持。真正可行的路径只有两条：
- 用
canvas手动绘制，requestAnimationFrame控制帧率，所有坐标计算在 JS 中完成，不触发 DOM 更新 - 用
svg+transform平移/缩放图形，避免修改x/y属性（会强制重排） - 绝对不要用
innerHTML或append频繁插入/删除图表 DOM 节点
示例：移动一个圆点，用 circle.style.transform = 'translate(120px, 80px)'，而不是 circle.setAttribute('cx', '120')。
立即学习“前端免费学习笔记（深入）”；
rem 适配在大屏里反而制造误差
很多教程教用 rem + 媒体查询做响应式，但在 1920×1080 到 3840×2160 的屏幕跨度下，font-size 动态计算会导致字体、边框、间距全部错位——因为设计稿按某一分辨率切图，而大屏要求的是“等比拉伸”，不是“响应切换”。
更可靠的做法：
- 用
transform: scale()对整个#app容器做一次性缩放，比如scale(2)对应 4K 屏 - 所有尺寸单位统一用
px，靠 JS 计算缩放比：const scale = window.innerWidth / 1920 - 监听
resize仅更新transform，不重新渲染 DOM 结构
注意：scale 会影响 canvas 像素密度，需同步调整 canvas.width/canvas.height 和 style.width/style.height。
WebSocket 断连后图表状态无法自动恢复
大屏常驻运行数小时，WebSocket 因网络抖动断开是常态。单纯重连不够，关键要解决“断连期间的数据真空”：
- 服务端必须支持消息回溯，例如带上时间戳或序列号，客户端重连后请求缺失区间数据
- 前端图表不能清空重绘，要用
update模式：保留已有数据点，只追加新数据、平滑过渡旧终点 - 断连时显示半透明蒙层 + 文字提示，但不冻结交互（比如允许手动刷新）
容易被忽略的一点：setInterval 心跳检测若放在组件内部，组件销毁后未清除，会导致内存泄漏并干扰后续连接逻辑——务必在 onbeforeunload 或组件卸载时 clearInterval。
大屏不是“放大版网页”，它对渲染节奏、状态持久性和设备行为的预判要求极高。最常出问题的地方，往往不在图表库选型，而在全屏初始化那一刻的 CSS 重置是否彻底，以及第一次 scale 计算有没有被浏览器缩放因子干扰。
