在做驾驶舱、大屏可视化、数据看板这类项目时，屏幕适配基本是绕不开的一步。

设计稿通常是 1920 × 1080，在标准分辨率下表现正常，但实际部署之后，会遇到各种不同尺寸的屏幕，比如 1366 × 768、1600 × 900、2560 × 1440，甚至超宽屏、拼接屏或者竖屏设备。这种情况下，如果没有做适配处理，就比较容易出现留白、拉伸、图表错位或者内容被遮挡的问题。

下面这些方案，是我在实际项目中逐步使用和整理出来的几种常见做法。

一、固定设计稿 + transform 缩放

这个方案的思路是：开发阶段完全按照 1920 × 1080 来实现页面，不做响应式拆分，然后在运行时根据当前屏幕计算一个缩放比例，对整个页面进行等比缩放。

const scaleX = window.innerWidth / 1920
const scaleY = window.innerHeight / 1080
const scale = Math.min(scaleX, scaleY)

transform: scale(scale);
transform-origin: left top;

这里取最小值，是为了保证页面完整显示，不会被裁切。也正因为这样，当屏幕比例和 16:9 不一致时，会出现上下或左右留白，这属于预期行为。

这个方案的特点是实现成本低、还原度高，页面结构也比较稳定，尤其适合布局复杂的大屏项目。不过在非标准比例屏幕下利用率不高，缩小时文字可能会有一定模糊感。

二、vw / vh 视口单位适配

这种方式是直接使用视口单位来描述尺寸，比如用 vw 表示宽度的百分比、vh 表示高度的百分比。

例如：

width: 20vw;
height: 10vh;
font-size: 1vw;

它的优点是天然具备适配能力，不需要额外计算，也不依赖 JavaScript。但在实际使用中，会发现字体、间距随着屏幕变化波动比较明显，不同分辨率下视觉表现不太稳定，图表区域也比较难精确控制。

因此更适合一些对还原度要求没那么严格的场景。

三、Flex + Grid 自适应布局

这一类方案主要依赖现代 CSS 布局能力来完成适配。

比如用 Flex 做一维排列：

display: flex;

或者用 Grid 做二维结构：

grid-template-columns: 420px 1fr 420px;

这种方式更偏“结构自适应”，页面在不同尺寸下会自动调整布局，维护性比较好，也更符合常规前端开发习惯。

但它的问题在于，对设计稿的还原程度不太容易做到完全一致，特别是在大屏这种强调视觉统一性的场景中，可能会有一定偏差。

四、rem + 动态根字体

rem 的思路是把所有尺寸都转成相对单位，然后通过动态调整根节点字体大小，实现整体缩放。

function setRem() {
  const designWidth = 1920;
  const baseSize = 16;
  const scale = window.innerWidth / designWidth;

  document.documentElement.style.fontSize =
    baseSize * scale + 'px';
}

这样原本写死的 px，需要换算成 rem，比如：

width: 20rem;
height: 5rem;
font-size: 1.5rem;

这种方式在多端适配（尤其是移动端）中比较常见，体系也比较统一。但在大屏项目中，如果是从已有项目改造，成本会比较高，而且图表尺寸通常还需要单独处理。

五、图表 resize

无论页面用哪种方案，只要涉及图表（比如 ECharts），基本都需要在窗口变化时手动触发一次 resize：

window.onresize = () => {
  chart.resize()
}

否则在容器尺寸变化后，图表很容易出现错位或者显示不完整的问题。

这个不属于完整的适配方案，但在大屏项目里是一个必要补充。

六、组合使用的一些情况

从实际项目经验来看，很少只用单一方案，更多是组合使用。

比较常见的一种方式是：

整体用 transform 做等比缩放，保证视觉还原
内部布局用 Flex 或 Grid，保证结构清晰
图表统一做 resize，保证显示正常

这种组合在开发效率、还原度和稳定性之间比较平衡，也是目前项目里比较常见的一种做法。

最后建议

如果是偏展示类的大屏、驾驶舱项目，一般会优先考虑 transform 缩放这种方式；如果是后台管理系统，更偏向使用 Flex + Grid；如果是需要兼容多终端（尤其移动端），rem 或 vw 会更合适。